> ## Documentation Index > Fetch the complete documentation index at: https://docs.talaria.chat/llms.txt > Use this file to discover all available pages before exploring further. # A complete messaging DID document > See how identity keys, encryption keys, Relay discovery, and Cache authorization fit together 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 ```json theme={null} { "id": "did:talaria:1111111111111111111111", "verificationMethod": [ { "id": "did:talaria:1111111111111111111111#keys-1", "type": "Ed25519VerificationKey2020", "controller": "did:talaria:1111111111111111111111", "publicKeyMultibase": "z" } ], "authentication": [ "did:talaria:1111111111111111111111#keys-1" ], "keyAgreement": [ { "id": "did:talaria:1111111111111111111111#x25519-1", "type": "X25519KeyAgreementKey2020", "controller": "did:talaria:1111111111111111111111", "publicKeyMultibase": "z" } ], "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: ```json theme={null} { "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: ```text theme={null} POST https://relay.example.com/relay ``` The recipient-bound form is also available: ```text theme={null} 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: ```json theme={null} { "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: ```text theme={null} X-Service-Id: did:talaria:1111111111111111111111#cache ``` The public Cache routes are relative to the advertised base URL: ```text theme={null} 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: 1. Resolves the recipient DID. 2. Rejects a deactivated identity. 3. Selects a compatible entry from `keyAgreement` and encrypts the DDN payload. 4. Selects a `TalariaRelayService` endpoint. 5. Submits the encrypted envelope to the Relay API. 6. Allows Relay delivery policy to use the recipient's Cache service when immediate delivery is unavailable. For message retrieval, the recipient: 1. Resolves its current DID document. 2. Selects its `TalariaCacheService` and complete service ID. 3. Selects an Ed25519 verification method listed in the service's `authorization` array. 4. Signs the Cache retrieval proof locally. 5. 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. Read the current chain-backed DID record. Publish a Relay or Cache service with DID-key authorization. Submit an encrypted DDN envelope to a resolved Relay endpoint. Build an authorized Cache retrieval flow.