Shared grains associate with apps by name, not ID

[ocdtrekkie]

So this one really confused me: I installed @orblivion's experimental Etherpad package, which I knew had a different appId than the official one, and is not an upgrade. You can see this because I now have two Etherpad installs:

I was really vexed to already have a grain made with it, considering it's a new app I haven't played with before, from 2017 no less!

Interestingly enough, the same grain also appears in the official Etherpad app's grain list:

But the official one has grains I created in addition to ones shared with me. Which suggests to me that the grains shared with me are being matched to the app by name, not ID.

It doesn't offer to upgrade the grain or anything since it's not my grain, and it loads it in the correct version for whoever owns that grain, but it doesn't seem like it should appear here.

[ocdtrekkie]

It does occur to me that this may be because Sandstorm servers generally aim to obscure appIds and packageIds that other users have installed because they may not be publicly available. So that is something we probably need to bear in mind when addressing this: It's possible the solution would be worse than the problem from a security standpoint, and the likelihood normal users would have two apps with the exact same name is probably slim.

[orblivion]

So I'm getting something a little weirder. I have two current-etherpad grains. When I look at current-etherpad app page, they show up as mine. When I look at the experimental-etherpad app age, they show up as shared. I don't think I have other users making grains on my server. I'm fairly sure I'm the human that made these two documents, at any rate.

…

On Fri, Jan 7, 2022 at 5:08 PM Jacob Weisz ***@***.***> wrote: It does occur to me that this may be because Sandstorm servers generally aim to obscure appIds and packageIds that other users have installed because they may not be publicly available. So that is something we probably need to bear in mind when addressing this: It's possible the solution would be worse than the problem from a security standpoint, and the likelihood normal users would have two apps with the exact same name is probably slim. — Reply to this email directly, view it on GitHub <#3598 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAKH6FPU5AOL525RNGN3KDUU5P4BANCNFSM5LPXKHMQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[zenhack]

Another data point that may be related (that I've been meaning to report as a separate bug, but I'm always on my phone when I notice it): I have a separate account that I log into on my phone, since I don't trust my phone as far as my computer. On that account, I have sandcal & prioritize grains I shared from the main account before I'd actually made icons for those apps -- and on the phone account the icons for those grains show up as the auto-generated thing for apps with no icons still. So it definitely seems like we have some problems with getting app info for shared grains.

[orblivion]

I had a hypothesis - these two Etherpad grains that show up as "shared" for me were created on Oasis and mass-transferred to my current server. Perhaps this puts it in a state that this list considers it "shared"? BTW one of them has a "was: " in this view. Per my hypothesis it would have been the name on the original server.

I just tried duplicating it by creating a new sandstorm server and mass-transferring an etherpad grain. However, the mass transfer feature doesn't seem to be working. Filed #3599

[orblivion]

(I did an inspect-element to change the file names)

[kentonv]

I think this is intentional. The idea is that we want to encourage people to hack on their apps and run modified versions. We don't want it to be the case that if one person happens to use a modified Etherpad, then no one else can find the documents that person shared because they don't show up under their own Etherpad install.

To that end, I think we group shared documents by app title.

[ocdtrekkie]

I can see that logic. Any idea what could cause Dan's example, where the grains show he owns them under one view, and that they're shared under another view?

[ocdtrekkie]

I'm removing the bug label since Kenton thinks the functionality we opened the issue for is by design.

[kentonv]

Any idea what could cause Dan's example, where the grains show he owns them under one view, and that they're shared under another view?

Ah, that part seems like a bug. Probably what's happening here is that sometimes a grain you own also appears in the list of grains shared with you, because somehow you shared it with yourself (or maybe owned grains are always shared with oneself, I'm not sure). But on the client side, when we construct the list of grains for an app, we merged the list of grains you own created with that app (filtered by app ID) with the list of grains shared with you that were created by any app with the same title. We then de-dupe, so a grain that is both owned by you and shared with you will only appear as owned by you. But if the grain is owned by you but created with a different app with the same title, then it only appears in the "shared with me" list and doesn't get de-duped with anything, I suppose.

[ocdtrekkie]

That is such a niche bug case I am having a hard time wrapping my head around how to rename this issue to reflect it.

[ocdtrekkie]

I think we should just leave this issue here as an informational testament to both the intended behavior and the weird edge case that is probably way too niche to spend time and effort fixing.