trustbloc / orb Goto Github PK

Transaction Client will:

• figures out last orb transaction for for each did that is referenced in the anchor
• creates new orb transaction with following information: anchor string, namespace, version and previous did transactions.

Implement an inbox for ActivityPub messages. The inbox receives an HTTP message with an activity and invokes a handler to process the activity.

Initial project setup

Implement the base Activity type object and also the following activity types:

• Create
• Announce
• Follow
• Accept
• Reject
• Like

Initial server components:

• initial CAS IPFS client
• core observer
• mocks : protocol, store and operation queue (to be replaced with DB-backed implementations)

Initial BDD test

Define the ActivityPub API and implement an in-memory store.

Generate id for anchor credential based on configured URL and uuid.

Implement the ActivityPub "Offer" activity and the "AnchorCredentialReference" object type.

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.

Add BDD test for the ActivityPub service for the follow/accept flow.

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.

Anchor credential builder will build and sign anchor credential.

Configure anchor credential parameters for orb server:

• ANCHOR_CREDENTIAL_ISSUER=http://peer1.com
• ANCHOR_CREDENTIAL_SIGNATURE_SUITE=Ed25519Signature2018
• ANCHOR_CREDENTIAL_DOMAIN=domain.com

• add transaction node into CAS
• read transaction node from CAS

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.

Create anchor credential storage.

Orb is a DID method based on the Sidetree protocol.
Conceptual overview: https://hackmd.io/@troyronda/Sy20HiD3v

This method relies on the following components:

• 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.

Orb Txn Processor will:

• will use sidetree-core operation provider to parse operation from batch files
• store anchored operations to operation store (did operation order is set based on previous operations for that did)

Create VC Signer that will be used to sign orb transaction.

Initial server components:

• initial CAS IPFS client
• core observer

Mocks (to be replaced with DB-backed implementations) :

• operation store
• operation queue

mock protocol (to be replaced with versioning solution)

Notes:

• 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).

Included:

• configure allowed anchor origins for server
• add anchor origin validator
• add anchor time validator
• set operation transaction/anchoring time to anchor credential's issued time

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 an ActivityPub persistent store which uses the aries-framework-go storage API.

Rename/move packages:
-- rename txn client to anchor writer
-- organize anchor credential related code (graph, writer, builder, util, model) under pk/anchor folder.

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.

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.

Updated:

• aries framework (0.1.6)
• sidetree-core (0.6.0)

Transaction client should sign Orb Transaction (Anchor Credential).

Implement the base Actor type object and also the Service actor type.

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.

Implement a Watermill logging adapter that redirects logs from the Watermill library to the edge-core logger.

Implement a handler for the ActivityPub 'Create' activity. The handler should publish one or more anchor credentials to an 'anchor credential' handler.

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.

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.'

Txn Graph:
-- add get did transactions to txn graph.

Txn Processor:
-- add retrieving all orb transactions for did and check them against operations in operation store.

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.

Implement a handler for the ActivityPub 'Reject' activity. The handler should notify any subscribers of the activity.

Implement an HTTP publisher for Watermill.

Handle CID as part of did:

• add CID to canonical ID in resolution result
• resolve did using canonical ID
• change canonical ID during recover

Define the basic ActibityPub vocabulary and provide an Object implementation that is able to marshal into a JSON-LD.

Orb Observer

• will listen to orb transactions
• retrieve transaction info from transaction graph before passing anchor string to sidetree-core for batch processing

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.

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.

A function should be added to the ActivityPub store API to query references since the result set may be very large (for example, likes & liked).

Implement the Collection and OrderedCollection types and add support for embedding Collection and OrderedCollection in the 'object' property.

Add support for an 'object' property, whose value may be a simple IRI or another ActivityPub object.

The ActivityPub service should be started when Orb starts and the inbox handler should be registered with the HTTP server.