Public listing of multiplayer apps in user profile


#1

Edit: this is a continuation of a discussion about the fact that what multiplayer apps are used from a discussion that occurred in this open engineering meeting.

Sorry I couldn’t make this meeting.

An aside, i really like the zoom recording - the transcript on the side made it really easy for me to skim through to get a general id of the discussion.

Having said that, it would be cool to put a couple bullet points in the meeting notes regarding any decisions/conclusions that came from the meeting. I skimmed the transcript but couldn’t easily figure out what the conclusion was re publicly sharing the apps you’re using.

Few comments:

  • Users aren’t terribly interested in the technical reasons for something not behaving according to their expectations.

  • If Facebook published in their Facebook profile that people used a bunch of dating apps, people would be pretty pissed, there’d be a ton of negative PR and it would probably destroy a bunch of peoples’ relationships.

  • If the user choice is between a big public company like Facebook or Apple knowing what apps they’re using an app and the whole world knowing, my guess is most people would choose the first option.

  • This seems like we’re moving the privacy ball in the wrong direction - on the “whole world knowing which apps I use” metric, objectively worse than the status quo.

  • People haven’t complained over the past year+ because up until recently there weren’t really any apps. Developers on Blockstack have a perverse incentive to support this public discovery of apps mechanism because it gives them growing public usage metrics (ie. graphs on https://theblockstats.com). We’ve seen this as single player apps complain that their apps don’t show up in stats.

Those are my thoughts based on the discussion that occurred.

Seems like there are two paths forward:

  1. If the apps are going to be publicly listed in the profile file like they are today, I’d be hesitant to solve the problem by obscuring it by hiding in in the explorer. Instead, let’s own it and leverage it as an advantage.

It enables cool stuff like finding your friends using the same apps. We can also improve copy and education so that people who want to hide their identity know that they should use separate blockstack ids for sensitive apps.

  1. Do a bunch of R&D to come up with a multiplayer storage discovery mechanism that’s more privacy friendly

Look forward to seeing what you decide!


2019-03-13 Engineering Meeting (Open to Public)
#2

True! Nobody care about any technical reason of anything. People only care about their expectations.

E.g. If Tesla car crash >>> nobody care about how hard to coding AI and engineering stuffs.

Agree!

True! But Why?

Muneed used to PR that People only need 1 Blockstack ID…


#3

Thanks for the notes here, @larry. I agree with your general assessment of expectations and potential reactions to this vis a vis Facebook, etc. I’m just not sure when this might arise as a practical concern for more than a few users (it’s a bit of a ticking time bomb).

I think I’m personally in the camp of “let’s own [the public knowledge of app usage for multiplayer apps] and leverage it as an advantage” since it’s one aspect of decentralization that seems unavoidably public, so any attempt to paper over the public nature will be half-satisfactory at best – and even more deeply surprising / disappointing to users who uncover it, at worst.

That’s why I’m thinking this new issue to add better guidance during app authorization around its public nature seems like the first best step to take:

That said, I’m not against reducing its visibility in the Explorer per se, especially since we don’t currently have a strong counter need to show apps there prominently (I believe @aulneau.id added them during the redesign simply because the data was available in profiles and it seemed like fun information to show, assuming users liked it displayed). But I don’t believe we decided to show them then for any deeper reason, so if we wanted to make them less prominent, I’d have no objections:

As for your point that we could “do a bunch of R&D to come up with a multiplayer storage discovery mechanism that’s more privacy friendly”, that’s intriguing (and to me clearly the best theoretical solution to balancing functionality with privacy and personal preferences), though I’m not sure how feasible on the face of it?

Perhaps someone here already has some promising ideas, though, on how to enable multi-player without revealing app authorizations. If so, I’d encourage them to create an issue about that in the most relevant repo.


Search and Discovery of User-Owned Data (EU funding)
#4

These are very good points and I agree with @larry Many people don’t realize their list of apps is public.

There are a couple of points I want to mention:

  1. If apps are completely private - there’s no way to discover user. You can’t have both - full discovery and complete privacy.
  2. Web of trust can be a good balance between the two. You list your apps only to trusted contacts. But not the whole world.
  3. With Facebook you trust the third party to protect the info about what apps you have (you trust Facebook). In Blockstack world, you could choose a sort of centralized provider that you trust that would manage your apps list and who can access it. Similarly to how you trust your gaia provider not to disclose your apps and your file names.

I like option 2. This would require a sort of a social protocol built into Blockstack infrastructure. In fact, Blockstack Token Whitepaper mentions web of trust for a slightly different use case:

In the second part, after the network goes live,we will introduce mechanisms for how the initial trusted-set can be expanded to include more users similar to how the traditional web of trust protocols [31] work. This part of the web-of-trust mining mechanism is under active development and we will release more details on it in a future version of this paper. We plan to fall back to a process with gatekeepers, similar to how the initial trusted-set is curated, if the algorithmic approach does not lead to a reliable mechanism. We discuss our ongoing work on algorithmic expansion of the trusted-set in Section 6


#5

I think we can do a better job of communicating to the user that the apps they use are publicly visible. But the solution of using a separate ID for sensitive apps is effective for now. If you didn’t choose a username that can be tied to you, then there is no way to connect the app usage to you. And it’s not very difficult to create a new ID from the browser. I also agree that in the long term we should find a better solution for the multiplayer storage protocol that provides more privacy. Perhaps apps can explicitly choose to be “incognito” and not be listed in the profile. We could then have users exchange storage bucket info directly through the use of an inbox-like feature.


#6

But they already can - they just don’t request the ‘publish_data’ scope.

There are apps, like Graphite, that absolutely require you to publish your gaia address in your profile. When you share a public Graphite doc, the code looks at the username and document ID in the URL, and then fetches that file from the user’s published Gaia address. How could you do something like this without making it publicly known that you use Graphite? Other apps like Debut require the same mechanism (and not just to get your list of apps).

I think part of this is apps being a little overzealous about requesting the publish_data scope, because users don’t push back on this permission. If we have a stronger notice that “granting access will make it publicly known that you’ve used this app”, which we should, then there will likely be more pushback from users. It is totally possible to build your app so that it doesn’t require the publish_data scope, and if it did end up needing that permission, it could make a second auth request for that scope, with the reasoning of why the app needs it.

With radiks, there is a level of obscuration that prevents the server or anyone else from knowing which models are created by which users. This is done for privacy purposes. Thus, it doesn’t necessarily need the publish_data scope, but that’s because it has an indexer. With proper p2p syncing between radiks servers, you mostly eliminate the need for the publish_data scope, while still maintaining a high level of decentralization.