A complete messaging DID document - Talaria Developer Documentation

A messaging-ready Talaria DID document publishes the public information another client needs to encrypt a message, select a Relay, and locate the recipient’s Cache service. The document does not contain private keys, messages, operational node interfaces, or network-management information.

Complete example

{
  "id": "did:talaria:1111111111111111111111",
  "verificationMethod": [
    {
      "id": "did:talaria:1111111111111111111111#keys-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:talaria:1111111111111111111111",
      "publicKeyMultibase": "z<ed25519-public-key>"
    }
  ],
  "authentication": [
    "did:talaria:1111111111111111111111#keys-1"
  ],
  "keyAgreement": [
    {
      "id": "did:talaria:1111111111111111111111#x25519-1",
      "type": "X25519KeyAgreementKey2020",
      "controller": "did:talaria:1111111111111111111111",
      "publicKeyMultibase": "z<x25519-public-key>"
    }
  ],
  "service": [
    {
      "id": "did:talaria:1111111111111111111111#relay",
      "type": "TalariaRelayService",
      "serviceEndpoint": [
        "https://relay.example.com"
      ]
    },
    {
      "id": "did:talaria:1111111111111111111111#cache",
      "type": "TalariaCacheService",
      "serviceEndpoint": [
        "https://cache.example.com"
      ],
      "authorization": [
        "did:talaria:1111111111111111111111#keys-1"
      ]
    }
  ]
}

Replace every placeholder with the public value for the identity or service you are publishing. Keep the same DID in the document id, component IDs, controllers, and authorization references.

What each component does

Component	Purpose	Used for
`#keys-1`	Ed25519 public verification method	Verifying signatures, authorizing DID updates, and proving Cache retrieval or acknowledgement access
`authentication`	Declares an authentication-capable verification method	Identifying which published key may authenticate as the DID
`#x25519-1`	X25519 public key-agreement method	Establishing encryption keys before creating the encrypted DDN payload
`#relay`	`TalariaRelayService`	Discovering the public base URL to which a sender submits an encrypted envelope
`#cache`	`TalariaCacheService`	Discovering the public base URL from which the recipient retrieves encrypted messages
Cache `authorization`	References one or more verification methods	Identifying the Ed25519 keys allowed to sign Cache retrieval and acknowledgement proofs

The fragment names are component identifiers, not secret keys. You may use different fragments, but every reference must match the complete component ID exactly.

Key roles are not interchangeable

The Ed25519 and X25519 entries serve different purposes:

The Ed25519 private key signs registration, authorized Directory mutations, and Cache access proofs. Its public half appears in verificationMethod.
The X25519 private key remains on the client and participates in message-key agreement. Its public half appears in keyAgreement.
authentication and Cache authorization reference the Ed25519 verification-method ID, not the X25519 key-agreement ID.
A sender uses the recipient’s X25519 public key for encryption. It does not use the Cache authorization key as the message-encryption key.

Both publicKeyMultibase values are public multibase strings. The leading z identifies Base58BTC encoding. Generate and store the corresponding private keys using a cryptographic library appropriate for each algorithm; never place either private key in the document. During ownerless registration, root_pubkey identifies the public Ed25519 root key that validates the registration signature. In the example above, it is the same public key published by #keys-1.

Relay service behavior

The Relay service advertises a public base URL:

{
  "id": "did:talaria:1111111111111111111111#relay",
  "type": "TalariaRelayService",
  "serviceEndpoint": ["https://relay.example.com"]
}

After resolving the recipient DID, a sender selects a TalariaRelayService endpoint and submits the encrypted DDN envelope to:

POST https://relay.example.com/relay

The recipient-bound form is also available:

POST https://relay.example.com/relay/{recipientDid}

The Relay entry does not authorize access to plaintext. Clients must encrypt the message before submission.

Cache service behavior

The Cache service advertises its public base URL and explicitly identifies the verification methods that may authorize retrieval:

{
  "id": "did:talaria:1111111111111111111111#cache",
  "type": "TalariaCacheService",
  "serviceEndpoint": ["https://cache.example.com"],
  "authorization": [
    "did:talaria:1111111111111111111111#keys-1"
  ]
}

The DID alone is not sufficient to retrieve cached messages. The recipient signs the documented Cache proof with the private Ed25519 key corresponding to an authorized verification method. The request identifies this service with the complete service ID:

X-Service-Id: did:talaria:1111111111111111111111#cache

The public Cache routes are relative to the advertised base URL:

POST https://cache.example.com/cache/store
GET  https://cache.example.com/cache/messages/{did}
GET  https://cache.example.com/cache/messages/{did}/{deviceId}
GET  https://cache.example.com/cache/chunks/{did}/{messageGroupId}
POST https://cache.example.com/cache/ack

Storage accepts an encrypted DDN envelope. Retrieval, chunk access, and acknowledgement use the Cache authorization proof documented on their endpoint pages. The private key never appears in the DID document or the Cache request.

How clients use the document

For a typical outgoing message, a client:

Resolves the recipient DID.
Rejects a deactivated identity.
Selects a compatible entry from keyAgreement and encrypts the DDN payload.
Selects a TalariaRelayService endpoint.
Submits the encrypted envelope to the Relay API.
Allows Relay delivery policy to use the recipient’s Cache service when immediate delivery is unavailable.

For message retrieval, the recipient:

Resolves its current DID document.
Selects its TalariaCacheService and complete service ID.
Selects an Ed25519 verification method listed in the service’s authorization array.
Signs the Cache retrieval proof locally.
Retrieves, persists, and acknowledges encrypted messages through the Cache API.

Publishing the document

You can include these service entries in the did_document sent during initial registration. You can also add or update each service later through the proof-authorized DID document component endpoints. After a mutation returns 202 Accepted, wait for chain confirmation and resolve the DID again before relying on the new endpoint.

Resolve the document

Read the current chain-backed DID record.

Add a service

Publish a Relay or Cache service with DID-key authorization.

Send through a Relay

Submit an encrypted DDN envelope to a resolved Relay endpoint.

Retrieve from a Cache

Build an authorized Cache retrieval flow.

​Complete example

​What each component does

​Key roles are not interchangeable

​Relay service behavior

​Cache service behavior

​How clients use the document

​Publishing the document