A DID method implementation that extends the Sidetree protocol into a Fediverse of interconnected nodes and witnessed using certificate transparency. Spec: https://trustbloc.github.io/did-method-orb/
Implement a handler for the ActivityPub 'Announce' activity. The handler for the 'Create' activity should also be modified to post an 'Announce' activity to the service's followers.
Implement a handler for the ActivityPub 'Create' activity. The handler should publish one or more anchor credentials to an 'anchor credential' handler.
Implement an ActivityPub service that encapsulates an inbox and outbox. The service should allow clients to post messages to the outbox and also register for notifications of inbound activities.
Currently ActivityPub properties need to be checked for nil before the property may be dereferenced, which makes it cumbersome for clients to use. For example:
typeProperty := activity.Type()
if typeProperty != nil {
if typeProperty.Is(TypeCreate) {
. . .
}
}
This should be simplified as:
if activity.Type().Is(TypeCreate) {
. . .
}
Even if activity.Type() returns nil, the function Is(TypeCreate) should return false without panicing.
A content addressable storage (CAS) that holds Sidetree files (same as the CAS in Sidetree).
Batch writers also create CAS objects that represent the graph of Sidetree anchors from their point-of-view (playing the role of the ledger in Sidetree).
Witness logs that observe nodes of the anchor graph. An individual log does not need to hold the entire anchor graph. This role is similar to certificate transparency in PKI.
This method defines the DID string such that a resolver can:
discover a DHT and/or HTTP hosted well-known for the anchor graph.
and from this graph, DHT, and/or HTTP hosted well-known, also be able to discover CAS objects for the Sidetree files.
discover a checkpoint in the graph for a particular unique suffix.
and from this checkpoint, be able to discover the chain of patches for the DID document.
discover the witness log server for each checkpoint in the graph for a particular suffix.
and be able to handle transitions between witness logs.
This method spec defines:
the CAS HTTP APIs that each orb did server MUST expose to have interoperability.
the discovery information for each supported DHT (starting with IPFS) and also HTTP well-known. there may be other interesting DHTs such as Tor.
the encodings for the graph (initially thought to be IPLD).
the witness HTTP APIs that each orb witness server MUST expose to have interoperability.
the structure of an anchor node including the anchor string, parent anchor CIDs, and witness log proofs.
the structure of witness log proofs and the properties of a witness log (similar to certificate transparency).
the sidetree checkpoint operation for a unique suffix that is at the same level as recover and deactivate - it is not prunable.
We would like to submit the method spec as a work item to W3C Credentials Community Group (CCG) or the Decentralized Identity Foundation (DIF).
The TrustBloc implementation will be pluggable to allow additional DHTs to be plugged-in. This core repo will support HTTP and we also plan to initially support an IPFS DHT.
Additional Notes:
Can discover CAS endpoints via DHT or http well-known.
The anchor graph needs to be available at the DHT or http well-known. The rest of the files can be fetched via REST API (but can also support network like IPFS).
List the checkpoint node as a CAS CID in the DID string. The resolver should roll forward to the latest known checkpoint but return the same checkpoint ID as was in the DID string. If the resolver doesn’t know the CID then the DID is unresolvable.
Use witness logs in the similar manner to certificate transparency. The log doesn’t have the complete graph, it just observes certain nodes. It issues proofs that are included in the graph and maintains its own merkle log of what it has observed.
Implement a handler for the ActivityPub 'Like' (endorse) activity. The handler should invoke a 'proof' handler with the embedded proof so that it may handle the endorsed operation. The activity should also be added to the service's 'likes' list.
Implement a handler for the ActivityPub 'Accept' activity. The handler should add the actor to the service's 'following' list and notify any subscribers of the activity.
The start and end times for the 'Like' activity should be changed to conform to the spec: 'The Witness includes the time range when the Orb transaction will become included into their ledger using startTime and endTime fields.'
Implement a handler for the ActivityPub 'Offer' activity. The handler should invoke a 'witness' handler with the embedded anchor credential so that it may generate proofs. If successful, the handler should post a 'Like' activity with the proofs back to the actor (requestor). The activity should also be added to the service's 'liked' list.
Batch writer should sign anchor credential before creating an offer for witnesses. In order to do this we have to setup kms, crypto, couch db during server start-up.
Each of the non-cache and non-ledger databases can be kept within the same DB instance.
We are planning for the DB to be CouchDB or Postgres.
The ledger implementation is pluggable. Our initial ledger implementation is planned to be Verifiable Credential Transparency (Certificate Transparency).
The optional DHT implementation is pluggable. The initial implementation is planned to be IPFS.
Ledger monitoring and auditing is not shown in this diagram (but will be needed).
Implement a handler for the ActivityPub 'Follow' activity. The handler should ask an authorization handler if the service should accept or reject the follow request. If accepted, the handler should post an 'Accept' activity to the requesting actor and add the actor to the list of followers; otherwise a 'Reject' activity should be posted.
Implement an outbox for ActivityPub messages. The outbox sends an HTTP message with an activity and monitors whether or not the message was sent. If an error occurs then it should retry according to type of error.
A new HTTP subscriber implementation is required in order to re-use ORB's HTTP server instance (so that all REST endpoints are served from the same address/port). The out-of-the-box HTTP subscriber for Watermill does not offer a way to pass in a service instance'. Also, this implementation does not support TLS.
Implement an in-memory Publisher-Subscriber that supports the Watermill Subscriber and Publisher interfaces. This Publisher-Subscriber may later be replaced by a persistent message queue, such as RabbitMQ or Kafka.