Proposal: Per-app Gaia hubs in the profile

TL;DR

Make it so the user’s profile object points to both read and write URLs for Gaia hubs on a per-app basis, and pass the write URL as hubUrl in the authResponse token.

Background

Blockstack’s promise to users it that they own their own data. Part of that promise means that a user’s data gets hosted wherever the user wants. Arguably, this also means the user can do so at the granularity of specific applications, since the nature of the data determines how it is stored. This entails making it so users have the ability to select which Gaia hub an application will use to store its data.

Design and Implementation

I think the shortest-path-to-success is somewhat straightforward: Extend the apps object in the user’s profile to contain both Gaia read and write URLs. Right now, it only contains the read URL (and even then, it’s not honored—see https://github.com/blockstack/blockstack-browser/issues/1488).

When the user completes the sign in (in app/js/auth/index.js, at completeAuthResponse()), the authResponse JWT returned to the application should contain a hubUrl value that corresponds to the user’s chosen Gaia hub for that application.

• If the user is signing in for the first time, then this URL is the Gaia URL from the settings page (i.e. this.props.api.gaiaHubConfig.server)
• If the user is signing in for the second or later time (i.e. an entry in the apps object exists for this application), then the hubUrl should be the write URL that corresponds to the read URL in the application’s entry in the apps object in the profile.

What is still needed is a way to store the write URL in the profile in a backwards compatible way. I recommend the following scheme. Instead of this:

"apps": {
   "https://app.origin": "https://user.gaia.hub/hub/1APPADDRESSxxxxxx/"
}

We have this instead:

"apps": {
   "https://app.origin": "https://user.gaia.hub/hub/1APPADDRESSxxxxxxx/"
}
"hubUrls": {
   "https://app.origin": "XXXXXEncryptedWriteURLXXXXXX"
}

The hubUrls object encodes the encrypted write URL for an application. It should be encrypted with the app public key because knowledge of the write endpoint is only pertinent to the writer. We can use the usual encryptECIES method to generate this ciphertext, and decryptECIES to decrypt it.

If the hubUrls object exists in the profile and has an entry for the application, the completeAuthResponse() method should use that instead of the default this.props.api.gaiaHubConfig.server URL). Otherwise, it uses the default this.props.api.gaiaHubConfig.server URL.

Backwards Compatibility

When the user signs into an app for the first time, then an entry is added to the hubUrls in addition to the apps objects.

If the user signs in and they don’t have a hubUrls entry, they use the this.props.api.gaiaHubConfig.server value as before.

EDIT: For single-player apps, we do not want to expose either the read or write URLs. To achieve this, when a user signs into a single-player app for the first time, the Browser would insert the following:

"hubUrls": {
   "XXXXXEncryptedAppOriginXXXXX": "XXXXXEncryptedGaiaHubUrlXXXXX"
}

Both the origin and the write URL will be encrypted. No read URL will be inserted into the apps object (since this information can be obtained from the write URL).

Execution

I’m happy to take the lead on all of the above. However, I think someone more versed in non-CLI user experiences should take the lead on adding a GUI for managing your hubUrls.

Thoughts? @kantai @yknl @larrysalibra

[yknl]

I like this proposal. Does this mean that single player apps will now also be published in the user profile? Maybe we should encrypt the app origin as well for single player apps.

[markmhx]

@jcnelson it seems this issue should be closed in favor of https://github.com/blockstack/blockstack.js/issues/540?