Canonical location for app public keys

[kantai]

There's a number of features that require communicating user's app-specific public keys-- e.g., end-to-end encryption and signing. We could support these features much more easily by having a canonical location for storing app-specific public keys for multi-player applications

Imagine, being able to encrypt a file to another specific user by calling:

putFile('foo.json', 'hello world', { encrypt: True, encryptToUser: 'blankstein.id' })

And that would encrypt the file to blankstein.id in a way that blankstein.id's appPrivateKey would know how to decrypt. Would be pretty cool, right?

Anyways, I talked about this in #381 -- and proposed turning the apps key in the profile object into a mapping from appDomain to an object { hubUrl, publicKey } instead of just a string as it is today. Unfortunately, this wouldn't be a backwards compatible change, and for changes to the profile object, it would be nice to have backwards compatible changes.

Instead, we could add a key to profile object appsMeta which would be a mapping from appDomain to objects, and store the public key there.

{ 
...
apps: {
   'localhost:3030' : 'https://gaia.blockstack.org/hub/1937Jf5qW2mPCY74RtCiH2f46vfWsjBXGa/'
}
appsMeta: {
   'localhost:3030' : 
     { 'publicKey': '0299f2962e593ead69f3354f3db556ff499cb8aba82e586530eff1f8801b62bd4e' }
  }
...
}

[hstove]

Does this require any changes from Gaia?

[kantai]

I don't think it would, @hstove -- I think it would only require changes in blockstack.js and blockstack-browser (roughly here: https://github.com/blockstack/blockstack-browser/blob/master/app/js/auth/components/AuthModal.js#L195) to add the entry to the profile when the multi-player storage scope is requested.

[hstove]

Awesome, yeah that makes sense. This would be really cool (especially in combination with your inbox proposal, which would open up a ton of possibilities).

[odinho]

If also "storage: gaiaurl" is added to appsMeta (duplicated), we'd have a way of deprecating and later removing "apps" in total to get away from the cruft of having apps and appsMeta separated.

The platform is still so young that we're not likely to have a lot of apps/code that exists now actually be usable in a years time anyway. So it might be nice planning for deprecation/nice formats.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed. Please reopen if needed.