05 D2D

This chapter defines Dina-to-Dina transport, message families, policy, offline delivery, and federated execution.

Purpose

D2D defines how two sovereign identities coordinate securely.

It is not just a transport channel. It is a policy-aware, trust-aware coordination layer between two human-centered systems.

Protocol Requirements

A Dina-compatible D2D layer MUST provide:

• DID resolution for endpoint discovery
• sender authentication
• message confidentiality
• typed message families
• replay protection
• outbox / offline delivery semantics
• contact and sharing policy enforcement

Wire Model

The reference implementation currently uses:

• Ed25519 signatures over plaintext messages
• Ed25519-to-X25519 conversion for encryption
• NaCl sealed box encryption
• a JSON wrapper containing ciphertext and signature

The current transport wrapper is effectively:

{
  "c": "<base64 ciphertext>",
  "s": "<hex ed25519 signature over plaintext>"
}

The plaintext message model is currently:

{
  "id": "msg-123",
  "type": "coordination.request",
  "from": "did:plc:sender",
  "to": ["did:plc:recipient"],
  "created_time": 1710000000,
  "body": { ... }
}

Message Families

The current Dina D2D v1 families are:

• presence.signal
• coordination.request
• coordination.response
• social.update
• safety.alert
• trust.vouch.request
• trust.vouch.response

These are the transport-level v1 families the current implementation accepts as its strict D2D surface.

Message Policy

The current scenario policy model is:

• standing_policy
• explicit_once
• deny_by_default

Default scenario families in the reference implementation currently map roughly to:

• presence: standing
• coordination: standing
• social: standing
• safety: standing
• trust: explicit_once

safety.alert is treated as a special always-pass inbound case.

Contact and Sharing Policy

D2D interoperability requires more than cryptography.

It also requires:

• explicit contact state
• trust ring
• entity resolution mode
• per-category sharing policy

The reference implementation already models:

• trust rings
• resolution modes such as late binding vs plaintext
• per-category sharing tiers

This is critical for person-to-person interoperability because "can I reach this Dina" and "what may I disclose to this Dina" are different questions.

Outbox and Offline Delivery

A conforming implementation SHOULD support durable offline delivery.

The reference implementation already has:

• durable outbox records
• retries with exponential backoff
• pending approval state
• delivered vs failed state
• support for a Dina message box endpoint

Outbox states currently include:

• pending
• pending_approval
• sending
• delivered
• failed

Replay and Verification

A D2D implementation MUST reject replayed messages.

The reference implementation uses senderDID|messageID replay tracking and verifies inbound signatures against resolved verification methods.

Federated Execution

This is where interaction learnings materially expand the protocol.

A remote Dina is not just a mailbox. It may act as an orchestrator.

Therefore the protocol MUST allow the following D2D fulfillment patterns:

• direct response
• remote query
• remote delegated execution
• remote monitoring or subscription

Example:

• your Dina asks a transit operator Dina for a bus ETA
• the transit Dina may query its own database, call traffic systems, or invoke its own task executor
• your Dina receives a protocol-level outcome, not the transit Dina's internal implementation details

For this reason, D2D interop SHOULD standardize a generic request-state plane.

Recommended request modes are:

• inline_preferred
• async
• subscription

Recommended lifecycle states are:

• accepted
• waiting_approval
• waiting_input
• running
• partial
• completed
• failed
• cancelled
• expired

Required fields in a generic D2D request-state object SHOULD include:

• request_id
• correlation_id
• requested_capability
• response_mode
• status
• created_at
• updated_at

Optional fields SHOULD include:

• result
• error
• retryable
• progress
• percent
• eta
• expires_at
• provenance
• requires_human
• next_action

Support for request modes, lifecycle states, and optional fields SHOULD be advertised through the capability discovery layer so that remote peers know the highest common lifecycle they can use.

The current v1 transport families do not yet fully freeze this generic request-state plane. That is an open standardization task before Protocol 1.0.

Draft machine-readable artifacts for D2D interop live in:

• schemas/d2d-envelope.json
• schemas/capability-advertisement.json
• schemas/capability-negotiation.json