Identity provider integration

[parkan]

• Dummy endpoint? -- edit: unnecessary (vyzo).
• [X] Blockstack/onename
• [X] Keybase

[vyzo]

cc @yusefnapora

[yusefnapora]

I'm leaning towards implementing keybase first, since it's easier to work with and has nice client libs and documentation. But we should be aiming for a modular wrapper api that can use either, or our dummy implementation for testing, etc.

[parkan]

Yeah this should def be super modular and start with an impl that reads from a text file or something like that

[parkan]

What's our latest thinking here?

[vyzo]

I think we should punt on this (and general directory work), as the datastore and secondary indexes are higher priority.

[parkan]

Agreed, moving to V4

[parkan]

Prioritizing blockstack, let's see if we can get this into 1.2?

[vyzo]

I think this is a complex issue that shouldn't be rushed, so v1.2 is probably unreasonable.

[vyzo]

I think a practical first step is to integrate with Blockstack identities through application specific keys. This also extends to any provider which supports application specific keys.

In order to use applicaiton specific keys, we will have to generate them. Thus, the user acquires a mediachain identity, which is a node-independent Ed25519 key. The key is stored encrypted (as it is more valuable cryptographic material than node keys), and the marshalled public key is the application specific key registered in blockstack (eg through the onename app key interface)

For each node (concat or aleph) the user controls, we use the mediachain id to sign a node manifest, which includes the peer id together with the publisher id (and perhaps an associated signature for the publisher id, as in contrast to the peer id it can't be validated by virture of net connectivity). This manifest associates the peer/publisher with an entity, specified as a blockstac id (we can use a prefix for specifying the provider).

The manifest is then provided by the node through the id protocol (#99), and is also published to the directory when the node goes public. This allows the directory to answer queries by entity id, and take the first step towards moderated directory domains; cf #71

[parkan]

Overall onboard with this, though role of publisher id becomes a bit confusing. +1 for manifests.

Do we want any kind of BIP 32 style key derivation? Will def add complexity so we don't have to build it out right away but should earmark it at least if we think we'll want it.

[parkan]

Do we want to allow multiple manifests per node? What about the case of e.g. soundcloud running a node that represents hundreds of thousands of users?

[vyzo]

There is no reason not to have multiple manifests, although I think we may want to separate in node and hosted publisher manifests for such use cases.

[parkan]

What remains here? Probably need some nicer tooling for the end user

[vyzo]

Support manifests in mcnode/mcdir and mcclient. For nicer tooling, we'll have to add support in aleph.

[denisnazarov]

What are the expected CLI commands?

Will there be commands for interacting with/querying by blockstack ID?