You are reading content from Scuttlebutt
@cel-desktop %k70jWA9EbJj4BRHq8NpfjU/xTr5HxBaaEh0Hl6LKbso=.sha256

SSB DID Methods


In %xfBoK+g... I mentioned the idea of a SSB DID method. @kas previously explored this in %i2COg3Z....

@alanz and @Mix Android discussed multi-device/author DIDs around %F9ZnCGp.... I wrote about ways that can work: %65eRuSM....

I also started exploring using SSB ids with did:key: %vl6H2nZ....

There is room for more than one SSB DID method. e.g. one could be ssb, another could be scuttlebutt. Or butt.

Just one SSB method would be good for interoperability, but it could also be good to keep one simple and easy to implement, while another could support greater complexity.

There could also be other DID methods coming out of this and/or adjacent communities/networks, e.g. Earthstar, Bamboo, Pigeon.


Would anyone like to help make a did:ssb implementation and specification? It would be great if there were multiple interoperable implementations, especially using different SSB stacks. I will probably start a ssb-server/JS-based one, since that is the stack I am most familar with, but I could also help with a Rust-based one.

For hosting a specification and implemention(s) source, I plan to use git-ssb. Repo (empty currently): %/DFLuc2...

Syntax Draft

Here is what I am thinking for it now. Syntax rules follow, borrowing some from DID Core's ABNF.

ssb-did          = "did:ssb:" feed-id (":" feed-specific-id)
feed-id          = feed-type ":" 1*idchar
feed-type        = "ed25519"
feed-specific-id = *( *idchar ":" ) 1*idchar
idchar           = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded
pct-encoded      = "%" HEXDIG HEXDIG

The DID would be based on the SSB feed ID, with an optional additional part (feed-specific-id). I propose that the feed id public key be encoded as base64url without padding (omit trailing "="). Using base64url allows for easier interop with existing SSB applications and SSB URI formats, but the "=" is not allowed in the DID method-specific-id (it would need to be percent-encoded).
e.g.: did:ssb:ed25519:lOUVT-Phkvai9a_cCS_RKo+S9hnPAQdVixms_7ldpPA

Creation, Updates, and Resolution

An SSB feed may create a DID document by publishing a message of some type. The message contains the DID Document representation type (e.g. JSON or JSON-LD), and the DID Document in that representation. Depending on the representation type, the DID document would be encoded as JSON in the message, or a string in the message, or possibly in a SSB blob which would be included by reference. To get the latest state of the DID document for a DID, one would query the most recent message of this type from the corresponding SSB feed.

Patch updates?

It might be useful to allow updating the DID document with a patch, e.g. using JSON Patch, rather than requiring it to be published in full each time an update is made. I am not sure if the space savings would be worth the extra complexity required for this. Space limitations due to message size can be worked around by storing the document in a blob instead, and/or by moving parts of the document into separate resources (i.e. a verification method object could be stored separately and referenced with a DID URLs.

A SSB feed could also create DIDs other than their main DID, by appending ":" and some feed-specific-id after their DID. This means each SSB feed controls a namespace for additional DIDs.

Additionally, the SSB DID method could support DID URLs with paths. A SSB feed could publish resources to paths under its DID by publishing a message similar to that of updating their DID document. Dereferencing these DID URLs would be similar to resolving DIDs. Resources at DID URLs with paths could be useful for referencing from the DID document(s), and/or other purposes.

Key rotation?

DID Core encourages key rotation. SSB itself does not have this for feeds, although there have been discussions of it. I would like to largely defer to the underlying SSB mechanism for the relationship between an SSB DID and a SSB feed ID. If a mechanism of key rotation for SSB feeds gains adoption in multiple SSB stacks and distributions, then I think it could make sense for SSB DIDs to use that.


A simple starting point for SSB DID could be easily understood and have multiple independent interoperable implementations. DID-specific mechanisms for multi-party control could be used without specific support from the DID method, as described in %65eRuSM.... We could specify how multiple DID controllers should be handled. If SSB-specific multi-author/device mechanisms become prevalent, we could consider enable SSB DIDs to upgrade to use those. Or we could specify different feed types in the feed-type part of the DID (which currently would otherwise be ed25519).

Network identifier

Should non-SSB networks (alternative SHS capability key) be supported? This could be done with an additional optional part of the DID, or as a DID parameter (i.e. query string parameter). What about seed phrases for SHS cap keys (as in ssb-gardens - %Jm+/spO... by @micro). Message signing cap keys?


#ssb #did

@cel-desktop %3DR5ksARS4blGn+NCHLfFX7SC1aFc4KcqL7avFNH1Cg=.sha256


DID Parameters

DID Parameters versionId and versionTime are used to refer to specific versions of a DID Document or versions that existed at particular times. We could support versionTime by querying for the latest DID Document update message published at or before the given time.
versionId could be the message sequence number of a DID document update message, or the message id. Message id would be longer but would enable fetching the document using ssb-ooo.

Peer discovery and remote access

A SSB user could run a SSB DID resolver using their local SSB database. A pub could run a public or private SSB DID resolver, e.g. exposing the resolver over HTTP(S). It may also be possible or desirable to build a SSB peer server specifically for resolving SSB DIDs and DID URLs. If a feed contains only SSB DID document updates or DID URL resource updates, it does not necessarily contain pub messages or contact messages for discovering other peers or peer addresses. It may be useful to encode such information into the DID document for the SSB server to use.

Join Scuttlebutt now