API Subsets Permissions

[jbenet]

we should come up with a good permissions model for the api-- i.e. be able to grant permissions to other peers, or HTTP API consumers, or to specific apps to strict subsets of the API. (say RO, or on subset of commands, or forcing a given option to be set, etc).

[jbenet]

This would be a good way to eventually do away with the 8080 and 5001 distinction-- IF we can be certain it works well, or rather, make it so that you can add arbitrary endpoints (at more ports if desired) with different permissions. so doing away with the hard-coded distinction and make it more a config.

[jbenet]

since our API is a command tree, and options can be expressed as query strings, we could create policies that effectively do this:

deny *
allow ipfs/object/get
allow ipfs/cat
allow ipfs/bitswap/stat
allow ipfs/logs?filter=bitswap

not sure this is the best language at all, but it is a language that doesn't seem cumbersome now.

[RichardLitt]

How do you want to do this, @jbenet? The best way would be to talk about this in specs, I think, and then mention the permissions in each method description, I think.

[ianopolous]

You may be interested in how we've achieved this in Peergos, as we expose the calls we use in ipfs to the world over p2p streams.

Essentially we require any modifying call, like "block put" to include a signature of the input from the user, and the server has a list of allowed users/public keys that allowed to call these methods. The extra signatures are included as extra url query parameters, so we can use the same client to talk directly to an ipfs instance, or to a peergos server.