Public Directory
A recipient identity publishes reachable services, keys, and the context needed for policy-aware delivery.
Theoretical use case / 01
Structured messaging
Policy-directed arbitrary payload relay
A globally reachable data layer in which identity and delivery intent are public infrastructure—while one finalized, bounded decision guides an application-controlled payload across the off-chain network.
CONCEPT BRIEFIllustrative architectureSeptember 2026
00 / ABSTRACT
A public route to a private exchange.
In this reference model, an OpenPayload Directory exposes globally resolvable user DIDs, public service endpoints, and scoped delivery intent anchored on chain. A sender addresses a recipient; the network selects the most specific applicable intent from finalized state and carries that bounded decision through the permitted delivery path.
The payload itself is a multipart structured envelope. Parts travel as bounded envelopes and are authenticated, ordered, and reconstructed by the recipient application. The exact wire schema, policy syntax, internal rule graph, and cryptographic profiles are intentionally outside this public brief.
01 / SYSTEM VIEW
Identity finds the network. Policy fixes the decision.
Scoped intent
One versioned policy can express different outcomes for identity, Persona, and message context.
Deterministic resolution
The network selects one applicable outcome from finalized state for the delivery attempt.
Bounded services
Permitted relay, storage, archive, or ordinary delivery behavior stays inside shared limits.
Recipient assembly
The receiving client verifies parts, restores ordering, and reconstructs the application-level message.
02 / MESSAGE PATH
One address. A policy-aware journey.
SENDEREncapsulate
→Split structured content into signed, bounded datagram parts under one message identifier.
DIRECTORYResolve
→Discover the recipient identity, reachable services, keys, and applicable policy context.
NETWORKBind + apply
→Select one finalized outcome, enforce its bounds, and direct permitted services.
RECIPIENTReconstruct
Authenticate the parts, reject invalid data, restore order, and rebuild the payload.
03 / POLICY OUTCOME
Rich intent becomes one bounded delivery decision.
Policy can distinguish message context, choose ordinary delivery, reject a class of traffic, permit transient storage, create an authorized archive copy, or direct one controlled onward handoff. The selected version remains fixed for the delivery attempt, and downstream services cannot expand the limits established by the applicable identity or Persona.
FINALIZED INTENT→MATCH CONTEXT→APPLY BOUNDS→DIRECT SERVICES→DELIVER
Specific intent without hidden expansion.
A more specific outcome may tighten routing, retention, size, or replication boundaries, but it cannot silently widen the shared limits above it. Encrypted content is not implicitly visible to a participating service.
04 / PROPERTIES
What this architecture is trying to make possible.
Portable identity
The address is a DID, not an account trapped inside one service provider.
Scoped delivery intent
Identity, Persona, and message context can select an appropriate finalized outcome.
Bounded handling
Relay, storage, archive, and ordinary delivery roles compose without open-ended forwarding.
Structured payloads
Applications exchange typed multipart data rather than assuming a single text body.
Transient continuity
When a recipient is offline, approved cache behavior can bridge the availability gap.
Provider independence
Compatible clients and operators can participate without one organization owning the whole path.
Decision continuity
The same resolved version and boundaries govern every permitted service in one delivery attempt.
Change declared intent, not the processing estate.
A traditional server-client deployment often requires an organization to reconfigure centrally controlled processors before it can change delivery behavior. Here, a new finalized policy version can reshape the bounded outcome chosen for future delivery attempts while compatible network roles continue to supply the path.
05 / DESIGN SPACE
Choices deliberately left to builders.
OpenPayload supplies shared identity, policy, and transport primitives. Applications can interpret and combine them according to their own risk model, user experience, and purpose.
- The application meaning of tags and classifications, and when to address an identity or Persona.
- Multipart envelope schema, delivery receipts, retry semantics, and maximum sizes.
- Key delegation for optional inspection without weakening unrelated routes.
- Abuse resistance, sender reputation, rate controls, and privacy-preserving spam indicators.
- Archive accountability, retention evidence, deletion semantics, and jurisdictional policy.
// 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 ↗