Stacks.js: Create api for lightweight multi-reader storage

[larrysalibra]

Parameters: username, app origin
Return value: index file URL for given app

[yknl]

A few key points from the conversation I had with @larrysalibra regarding how this will work. Let me know if I missed something.

• Apps will need to request the appIndex scope when authorizing
• App index files will be added to the user's profile under the apps key, indexed by the app origin
• We should be verifying the app origin
• The browser will handle writing the app index file url to the users's profile
• App index file updates will be done using getFile/putFile

[yknl]

We now have a functional API for multi-reader storage via app index files which looks like this
function getUserAppIndex(name: string, appOrigin: string, profileLookupURL: string = 'https://core.blockstack.org/v2/users/')

Returns the app index file for a given user and app by looking up the user profile on Blockstack Core and then fetching the appropriate app index file.

We're using Blockstack ID to look up user profiles here. We could potentially allow look ups via owner address, but how people are going to find other people's address is a problem.

Effectively, a Blockstack ID is required for multi-reader storage. When free subdomains are enabled, this shouldn't be a big issue.

There are also 2 new methods to write/get the current user's app index file: getAppIndexFile and putAppIndexFile, which essentially wraps the putFile and getFile methods.

[larrysalibra]

From the engineering meeting notes:

My proposal

blockstack.user(‘user.id’).apps(‘https://use.coinsapp.co’).files() → returns an array of files

@kantai 's

getFile(‘foo’, {user: ‘username’, app: ‘https://use.coinsapp.co’})
putFile(‘foo’, {public: true})

[larrysalibra]

I like @kantai 's proposal because it more closely follows the api methods we're using now which will make it easier for app developers to get up and running.

[yknl]

blockstack.user(‘user.id’).apps(‘https://use.coinsapp.co’).files() → returns an array of files

I think this would require more engineering work than modifying the getfile and putFile methods. But could be something we move to in the long term.

[shea256]

Question:

Why is it necessary to specify "https://use.coinsapp.co"?

Isn't the origin already determined? Shouldn't that restrict the domain bucket that the library can call out to?

[larrysalibra]

Why is it necessary to specify "https://use.coinsapp.co"?

We could have it default to using the origin of the current app - developers could specify another app origin if they wanted to read files from a different app.

[yknl]

We could have it default to using the origin of the current app - developers could specify another app origin if they wanted to read files from a different app.

Yea that sounds good. Letting developers specify the origin allows different apps to operate together through a standardized protocol.

[kantai]

We could have it default to using the origin of the current app - developers could specify another app origin if they wanted to read files from a different app.

Yep -- I like defaulting to the current app, and providing the option for more.

[kantai]

As part of this API change, we should probably move the encrypt/decrypt options to the options dictionary.

[yknl]

Also, since @shea256 mentioned that we're optimizing for support of decentralized messaging apps first, the ability to encrypt files using a different public key might be high priority.

[yknl]

Ok, looks like we've agreed on this

getFile(‘foo’, {user: ‘username’, app: ‘https://use.coinsapp.co’})
putFile(‘foo’, {public: true})

[larrysalibra]

Also, since @shea256 mentioned that we're optimizing for support of decentralized messaging apps, the ability to encrypt files using a different public key might be high priority.

I think we should avoid increasing the scope of this particular issue. Encryption of files for other people is a potentially complicated issue: as an example: you might want to have a symmetric key that encrypts the file and then encrypt that key with the public key of the readers so that the file doesn't have to be re-encrypted when you add an additional reader.

Focusing on discovering data written by other users of the app enables something that wasn't possible on our platform before. Given the discovery mechanism this feature provides, apps can address the encryption problem on their own until a point in the future when our platform provides that functionality.

[dhealy05]

+1 for @larrysalibra's comment from someone doing the chat bounty--was having this exact conversation with my partner last night. think it's best if it's simple on the Blockstack side (at least for now)

[larrysalibra]

This shipped in blockstack.js v0.15.0 and will work with browser v0.22.0 or higher.