We’re starting to research approaches to collections. “Collections” is our current term for a user-oriented data set that multiple apps read/write to, for example: Contacts, Photos, Notes, etc.
We also recognize that as a security-oriented, self-sovereign identity platform many users don’t want to tie their email to the their Blockstack ID. But, email is really helpful for building successful apps. All the major consumer platforms became successful by retained engagement through email or mobile push. You simply need to communicate with your users (through some channel) to build a successful relationship over time. Full stop.
A similar situation relates to other user profile metadata like: First/last name, bio, photo/avatar. We don’t want to burden users with entering all this info at ID creation, and users don’t want to enter that info either. But, it is also very helpful to have this data on hand when trying to build a successful app experience.
A solution that address all of it: Create a ID metadata collection and allow apps to read/write. Email is pretty easy for an example, but the following could extend to any ID metadata:
Alice wants to use Kanstack app.
Kanstack requests access to Alice’s ID metadata collection.
Kanstack needs to send Alice email updates, and checks to see if Alice’s collection contains her email.
Email is missing, so Kanstack prompts Alice to enter her email.
Alice enters her email and continues on to use the app.
Alice then signs in to the Coins app, which requests the same collection, and can access the email written by the Kanstack app.
This is interesting as though I would prefer it to be handled completely by the browser (i.e. through popups/how auth works now), this also provides the opportunity to give social proofs to completely over to apps.
Say Kanstack wants to know your Twitter account (for some reason), and you are okay with this. The Browser doesn’t have to implement the OAuth binding, but Kanstack can and add a Social Proof (according to the schema!) into your ID Metdata collection, which can then be used by Graphite Publishing later.
The browser could then delete metadata when asked, or even add it if asked, but it doesn’t have to support everything a particular app would need, thus apps aren’t limited by the browser in this area, which is a huge plus.
I think it’s a good idea but I have a feeling this could be abused somehow… though I don’t know how yet.
On first glance a metadata collection seemed like a good solution. But it is a wholesale, all-or-nothing solution.
Consider the situation from another angle. Why does an application need to contact a user?
Send me my username password.
Notify me of security breaches that harvested my data
Notify me of changes in their application
Notify me they are going out of business
Send me promotional material about their products
Notify me of things I bought through them
Notify me of a communication from someone i interact with through their app
Then, of those basic actions which ones exist in our new blockchain world:
Send me my username password.
Notify me of security breaches that harvested my data
Notify me of changes in their application
Notify me they are going out of business
Send me promotional material about their products
Notify me of things I bought through them
Notify me of a communication from someone i interact with through their app
Then, of those that remain, which ones do I typically want:
Notify me of changes in their application
Notify me they are going out of business
Send me promotional material about their products
Notify me of things I buy/bought/sold through them
Notify me of a communication from someone i interact with through their app
Notice, not all of the things left apply to all the sites I might use. Now, it seems like a collection based solution is just carrying over the same out-of-control spam world we have now. I give an app, service, company my email and they spam me.
A subscription based model might be more suitable. I subscribe to this thing on your app not that. And you can relay that message through my id not necessarily read the actual email.
As far as requiring an Email for notifying - I have always disagreed with requiring it because, more or less, for those reasons and because it forces a decentralized user to be tied down to a centralized service.
I do think that using a Matrix or ActivityPub service would be better for the things you described, but I would argue this doesn’t put @jeffd’s proposal off the table, as what he is proposing is something radical in terms of allowing apps to mess around with the user ID metadata, or user profile itself. If we can look beyond the email example and into the meat of what he is proposing it looks rather freeing for both the browser and the app developers.
@MichaelFedora I actually think it is an intriguing proposal. I just think it is a bit too based on an application-centric, old world view of application interaction. If we step back from “applications need user emails” to “when do users want applications to contact them” we might come up with a different design. A design that works for a spectrum of users from “never contact me” to “gee, tell me everything, every day about your WizBang app.”
I agree with @MichaelFedora that the browser should be in control and that the user should have the choice to give a piece of data to an app or not (even if the data is stored in the meta/user collection), or maybe even edit the data before giving it to the app, e.g. use different emails for different apps. Furthermore, I very much like the idea of the mobile run-time permissions, also have different permissions for read and for write.
Having a collection where all apps can read and write does not sound very convincing. If we want that then there should be a history and deleted data should be recoverable like git or matrix and apps can be made accountable for their actions.
From the apps that I developed, I would like to know from the user
which theme color they like most, so that the user likes my app more
which calendar app (domain) they use, so that I can propose to add an event to the user’s calendar
which profile lookup service (debutapp social, human names, spring role) they prefer, so that I can provide them with the appropriate link where needed.
which payment providers (from my a list they I support) they use, so that we can exchange values.
which communication provider they use, which matrix home server they use (or which matrix id) if any at all, so that I can invite them to communication
For OI Calendar, I am experimenting with communications. The app can invite users into different communications (matrix rooms):
one for messages only to the user, e.g. reminders for my events
one for messages to other users in the name of the user, e.g. events organized by friedger.id
one for messages with a group of users, e.g. conference room of an events
The calendar app invites the users to these channels/rooms and the user is free to accept the invitation or not, or leave whenever the user has enough or block the user.
I’m not against the idea of getting User’s email. But many of us know about CRM - Customer Relationship Management and salesman think email is a contact’s property (i.e. lead, customer, etc)
I think worrying about how emails are used is a bit beside the point. Even if we invest a huge effort in some other scheme, or lock down the email in a granular way, app teams that want to communicate with their users will just bypass us and ask for emails in their onboarding flows. I know because I believe both Zinc and Springrole do this today and I get their emails. But right now I need to give each app my email separately and I assume they store it in their own DB. I’m proposing we store it in my Gaia and I only enter it once.
Long term, I think creating a wholly separate decentralized email-like system is great and I’m sure we’ll do that. For today, I’m not really pro-email, I’m pro communicate with your users (through some channel) and support getting that done in whatever way makes pragmatic sense.
Couple other thoughts:
I think this makes sense conceptually. Assume your app requests access to 10 different bits of info and your UX and even app value is based on that access. The user “subscribes” to the app itself with the auth request but denies access to the data that is needed to make that app work. Seems correct from a digital rights perspective but a mess for dev teams and also the user’s themselves. I can see this one both ways. Wondering if that change is actually a net positive?
I agree. This proposal is the opposite of requiring it. The browser won’t ask for it, specific apps will and you can always just not comply or click skip for that request. You could also maintain different IDs. For example, an ID for apps you want zero contact with.
Should it? My assumption is that critical profile info would remain in the profile.json. So what we are making “editable by apps” is first/last name, photo, description, email (at least to start with). If you can’t trust an app with write access for this info, would you use the app at all?
Thanks for all the input so far. Would love to hear more.
I still believe that apps build a profile of me and I would like to control what email and name each app uses for my profile. Maybe different blockstack names is a solution, but then I need to remember which name I used for which app.
Re email, that is by far the best most used decentralized service we have so far, IMHO.
This is a good point – I see it quite a bit on /r/privacy that people are using emails similar to onne-time passwords so it is harder for apps to track them across sites. It honestly might be more important to let the app handle it and store it in your Gaia Hub – or have it run without knowing the email at all (entering [email protected] is what I tend to do).
I think the collection is still a good idea, as it goes with the “one account” idea that Blockstack has, but granular permissions should definitely be a thing.
Thinking about this a little more. There is some profile-type data you probably always want public/readable because it is useful for finding your ID inside an app…
Public ID metadata (read always, write upon auth request)
Name, avatar
Private ID metadata (encrypted, read or write upon request)
Email
I like Jeff’s proposal to move this data into a collection.
There are already a standard for this: VCard which most of the major platforms (apple, google, windows). Your own contact info is simply a specific instance of a contact card.
I don’t see why granular access to files in “your contact card” couldn’t be offered.