In @ryan’s post asking for feedback on dapps people might want to actually use, @nguyenlocmentioned dating apps as one of the possibilities. This got me thinking about user privacy. While some users might be completely comfortable with the world knowing they’re using a dating app (or any other app), but not everyone would be.
Currently, the lookupProfile method returns a list of apps the user has signed into. I could see how this would be a privacy concern issue. At the same time, this is useful for when apps want to share data. So, I wonder if there might be a mechanism in the future for users to opt into the apps they use being publicly displayed.
This is a great topic for discussion @jehunter5811 — I think we should definitely have a plan for supporting “hidden” logins, but this leads to a question about what a hidden login even looks like for a multiplayer application.
Imagine if I’d “hidden” my login to the app — what should the above call do? Should it return data if I’ve logged into the app or only if I’ve “unhidden” myself to that user?
In the case of explicit “unhiding” of data, there are definite strategies that we could pursue: however, you would be giving the user you unhide yourself from the ability to expose your app usage to others.
The app is single-reader. In this case, the Browser would need to encrypt the app name and URL with the user’s public key before storing it in the user’s profile, and only share it with the app. Then, no one could tell which single-reader app the user was signed up for.
The app is multi-reader, but with small enumerable groups of users. In this case, the Browser would need to encrypt the app name and URL with the set of users’ public keys before storing it to the user’s profile, so only the chosen other users can discover and read it. The user could manage permissions of other users if the Bockstack Browser implemented a cross-app social graph (something we intend to develop at some point). For example, my hypothetical social graph settings might say that Aaron is allowed to access my shared Graphite documents, but Patrick is not (in which case, Patrick would be unable to tell that I was using Graphite at all).
The app is multi-reader, but a large, non-enumerable group of users (like a dating app). I think the best way to handle this case is simply to use a different Blockstack ID for these apps (recall that in the Blockstack Browser wallet, your name owner addresses are derived from BIP32 hardened child private keys, so they can’t be correlated). Only you would be able to tell that you were the owner of both your “public” persona and your “app-specific” persona, much like how today on the Web only you would be able to tell that you were both the owner of a particular Gmail account and a particular OKCupid account. Subdomains are going to make this a lot easier, since they can be registered basically for free and the user doesn’t have to spend Bitcoin.
Does this apply for a multi-player app? Or does it only apply for sharing data across apps? I don’t specify the app to read the file from when I’m loading files, but that might just be the difference in how I’m handling reading encrypted files shared by users in the app.
Yes – this applies to multi-player applications even if you read from the same app. This is because the client code needs a way to figure out where to read a given user’s files from (you can’t derive a user’s app URL just from their normal identity address).
The way that a multi-player lookup works is roughly:
Lookup the given user’s profile
Find the correct application entry in that profile (defaults to current application)
Read data from that URL prefix.
In the single-reader case, this is somewhat easier — we don’t need to (and indeed, we don’t) store any information at all in the profile, because the app URL information is passed in during authentication.
I agree with this assessment. For apps where you only want to interact with a few other users, an encrypt-to-hide approach could be made to work. For apps where there’s a large number of users you would interact with, then yes, using multiple personas is probably the best strategy.
This post brought me to scan the whole .id namespace for profiles, zone files and app URLs. I found some really interesting app URLs from apps that aren’t announced publicly yet.
Although these are only multi-reader URLs, I think it’s not necessary that these URLs are public.
Could we simply hash these URLs? I guess users who want to access these already know which app they’re using. This would keep private (not-yet announced) apps from being on a public list that’s readable for all.
This would keep private (not-yet announced) apps from being on a public list that’s readable for all.
Just pointing out that this could also be achieved by using an obfuscated URL for unannounced apps (which is probably what the app developer would want to do anyway, in order to help prevent it from being discovered too early).
