Theoretical use case / 04
Event-driven applications
From stored payload to application action
An encrypted payload reaches temporary storage. A signed event starts your application’s next action, without giving the transport network access to message plaintext.
00 / THE SCENARIO
Offline does not have to stop the workflow.
Imagine an application exchanging private updates with a recipient who is temporarily offline. The client encrypts the update, addresses the recipient, and includes a registered application identifier in its public envelope. Recipient routing determines whether a Cache may retain it.
Once the Cache durably stores the envelope, an Application policy can match the storage event and trigger a signed HTTPS Call. Your receiver verifies the request and decides whether to queue a notification or start another application action.
01 / THE PATH
One private payload. A separate public signal.
The application creates an encrypted DDN envelope and submits it to a Relay.
Recipient-authorized storage completes before the CacheStored action is queued.
The worker checks current policy and domain authority, then signs a Call to the exact HTTPS URL.
The receiver validates the node, policy, URL, and freshness; deduplicates the event; then accepts the action.
The recipient’s DID or addressed Persona controls routing and retention. The Application policy adds actions alongside that route. It cannot choose a different Relay or extend message retention.
02 / DOMAIN AUTHORITY
Call a destination you control.
The Application’s control DID owns an active, DNSSEC-verified domain Persona and binds that domain to the Application. The policy can call that domain or its descendants. Expiry or ownership transfer disables Calls under the old owner.
Public action templates can use envelope and event metadata. They do not decrypt the original payload. Provider credentials and application secrets stay in your receiver’s own configuration.
Read the authorization and receiver contract ↗03 / YOUR INTEGRATION
The network supplies primitives. You supply the receiver.
Create the Application and any required linked-DID or DNS domain authority.
Publish a signed policy document with supported events and actions. The chain checks publication authority; services interpret its rules. Keep templates public and bounded.
Deploy a receiver that validates signed requests and handles repeated calls safely.
Talaria Chat now uses this pattern in the alpha. Its Application is registered and bound to its DNS domain, its signed policy matches CacheStored and requests sendPush through an authorized HTTPS Call, and its push receiver is deployed. Policy publication was verified on October 17; the receiver and network services were updated on October 18. Background push to an updated receiving device still needs a fresh end-to-end test. Other applications supply their own registration, policy, and receiver.
04 / DESIGN SPACE
Keep outcomes explicit.
- Relay acceptance does not mean a recipient received or processed a message.
- A node signature identifies the sending node; the receiver must validate its authority and application proofs.
- Retries can repeat a Call. Deduplicate its call identifier before performing the action.
- A notification or HTTP acceptance is not a recipient application acknowledgement.
// BUILD THE NEXT USE CASE
Take the protocol in
an unexpected direction.
Explore the public Directory, Relay, and Cache interfaces, then design an application around your own arbitrary payload.
Open developer docs ↗