List app resources isn't going to work

[jcnelson]

The /users/:userID/app/:appid/resources API endpoint isn't going to work, since application resources can live outside of Blockstack to be backwards-compatible with existing Web services. For example, I would expect that something like /users/judecn.id/app/blockstack_maps/resources/maps.google.com?... to be a valid GET request (which happens to pull data from maps.google.com through the client daemon).

[shea256]

OK what alternatives do we have?

[jcnelson]

The API is meant to allow the application code to fetch external data on-the-fly while verifying that it was signed by the application author (or triggering a warning if not). This is so the developer can keep using data stored in their preferred hosting service. To make it compatible with Blockstack, they'd either re-encode their data as a signed JWT, or they'd include a .sig file alongside each path that contains the signature over the data (which the daemon would fetch and use to verify the data's authenticity).

This API isn't really part of the user accounts or names APIs. I'd imagine that it should go under /resources/:appID/:resourceName/ or the like.

[shea256]

Good call on the separation. I'll make that change.

[shea256]

Also, since we're providing a path, I'm thinking it be more like this for resources where the signature is checked:

/resources?app=chord.app&path=https://s3.amazonaws.com/onename/avatar-placeholder.png

...and it should be something like this where the hash is checked:

/resources?hash=sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u&path=https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css

[shea256]

Here's the code for integrating bootstrap into HTML in a way that the browser automatically checks the hash:

<link
href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css"
rel="stylesheet"
integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u"
crossorigin="anonymous">

[jcnelson]

That works as long as:

• the HTML file is verified (how is this done if the HTML file is a resource too?)
• you're using HTML (how is this done if you're using e.g. curl?)

What if we did this instead?

• route: /resources/:appName/:appID
• required query fields:
  • path=: the URL to the resource
• optional query fields:
  • sig=: the URL to the signature over the resource (to be checked against the app-specific public key pointed to by :appID, which in turn is vouched for by the key pointed to by :appName). Defaults to $path.sig

Examples:

• /resources/chord.app/chord.app?path=https://s3.amazonaws.com/onename/avatar-placeholder.png
• /resources/judecn.id/helloworld?path=https://www.cs.princeton.edu/~jcnelson/avatar.png&sig=https://github.com/jcnelson/helloworld/avatar.png.sig