Dina Protocol

Status: draft, reference-implementation-driven

This document defines Dina as a protocol rather than a single product implementation.

The goal is:

This document is intentionally broader than the current Go/Python/TypeScript reference implementation. Where the implementation already behaves consistently, the document is normative. Where the implementation still contains multiple active profiles or migration-era behavior, the document calls that out explicitly so the protocol can be frozen cleanly later.

1. Scope

Dina the product is a sovereign personal AI.

Dina the protocol is the standard for how humans and their software:

This protocol is not only a wire format. It is a layered interoperability contract.

2. Design Goals

The protocol exists so that:

3. Relationship to the Interaction Architecture

This protocol is grounded in the interaction architecture already defined for Dina:

Those documents answer:

This protocol document answers a different question:

4. Conformance Language

The keywords MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT are used in the RFC sense.

This document distinguishes:

5. Protocol Shape

The Dina protocol should be strict only where interoperability actually requires strictness.

Its shape is:

5.1 Minimal Frozen Core

The core protocol should freeze only the pieces that must be identical across implementations:

Everything else should remain profile-based or extensible.

5.2 Profiles

Profiles are named bundles of additional behavior on top of the core protocol.

Examples include:

Profiles allow an implementation to be fully Dina-compatible without pretending to support every optional behavior.

5.3 Extensions and Namespacing

The protocol SHOULD allow growth through explicit extension points.

Extensions SHOULD be:

Unknown optional extensions MUST NOT cause protocol failure by themselves.

Failure should occur only when:

5.4 Capability Discovery and Negotiation

Conforming implementations SHOULD support both:

Static capability advertisement answers:

Live capability negotiation answers:

At minimum, a capability advertisement SHOULD declare:

Capability advertisement MAY be published through:

The protocol should standardize the semantics of capability discovery, not require one single UI or deployment shape.

Draft machine-readable artifacts for this layer live in:

Live negotiation SHOULD choose, for a given interaction:

Two Dina-compatible implementations MUST be able to fall back to their common subset whenever possible.

An implementation MUST be able to say:

without forcing the remote side to guess.

5.5 Protocol Layers

Dina has six core protocol layers and one cross-cutting interoperability layer.

  1. Identity
  2. Authentication
  3. Encrypted Storage
  4. Agent Safety
  5. Dina-to-Dina Communication
  6. Trust Network
  7. Interaction Contract

The first six are the infrastructure core.

The seventh is the application interoperability layer that makes all higher-level scenarios portable across implementations.

6. Core Entities

The protocol recognizes the following principal types:

The protocol also recognizes the following counterparty classes:

These matter because the same user request may route through different fulfillment topologies while preserving the same external contract.

Every conforming implementation SHOULD also expose enough capability metadata for another Dina-compatible implementation to determine:

7. Layer 1: Identity

7.1 Purpose

Identity defines who a sovereign participant is and how other implementations recognize that participant.

7.2 Protocol Requirements

A Dina-compatible identity system MUST define:

7.3 Root Secret Model

The intended Dina identity model is:

The Dina-specific HD namespace is:

This prevents collision with wallet ecosystems such as BIP-44.

7.4 Current Reference Implementation

The current Dina reference implementation already uses:

Concrete derivation paths in the current implementation include:

7.5 DID Methods

A Dina-compatible Home Node SHOULD expose a did:plc identity.

Device and service principals MAY use:

The current reference implementation accepts all three DID prefixes at the domain layer, while using did:plc as the primary Home Node identity and did:key for CLI device identities.

7.6 DID Document Requirements

A Dina-compatible DID document SHOULD expose:

The reference implementation currently uses:

7.7 Rotation and Recovery

Home Node identities MUST support key rotation.

For did:plc, rotation SHOULD be driven through a recovery key distinct from the root signing key.

The current reference implementation derives PLC recovery keys from the dedicated m/9999'/2'/... subtree and supports PDS/PLC-backed DID lifecycle operations.

7.8 Protocol Freeze Point

The reference implementation currently has an unresolved identity-root question:

Before Dina Protocol 1.0 is frozen, the protocol MUST standardize one root key material profile for downstream derivation.

Recommended direction:

8. Layer 2: Authentication

8.1 Purpose

Authentication defines how a participant proves who it is.

8.2 Protocol Requirements

A Dina-compatible authentication profile MUST support signed requests using Ed25519.

The canonical signing payload is:

METHOD
PATH
QUERY
TIMESTAMP
NONCE
SHA256_HEX(BODY)

The current reference implementation signs exactly this payload.

A draft normalized schema for signed-request interoperability lives in:

8.3 HTTP Header Contract

A signed HTTP request SHOULD carry:

X-Signature is the Ed25519 signature over the canonical payload.

8.4 Replay Protection

A conforming implementation MUST protect against replay.

The reference implementation currently enforces:

8.5 Device Pairing

A Dina-compatible Home Node SHOULD support device pairing as a bootstrap flow.

The reference implementation currently uses:

Pairing MAY result in either:

8.6 Service Keys

Internal or peer services MAY authenticate with distinct service Ed25519 keypairs.

This is already present in the reference implementation for Core-to-Brain and similar service paths.

8.7 Auth Modes

The Dina protocol recognizes at least these auth modes:

The protocol SHOULD treat signature-based authentication as the primary interoperable profile.

Paired bearer tokens are acceptable as a bootstrap or compatibility profile, but SHOULD NOT be the normative long-term cross-implementation trust model.

8.8 Caller Model

A Dina-compatible implementation SHOULD propagate caller context containing at least:

This becomes important for:

9. Layer 3: Encrypted Storage

9.1 Purpose

Encrypted Storage defines how personal data is protected and made portable across implementations.

9.2 Protocol Requirements

A Dina-compatible storage system MUST provide:

9.3 Persona Model

The protocol persona tiers are:

These tiers are already present in the reference implementation.

Expected semantics:

9.4 Physical Storage Profile

A Dina-compatible Home Node SHOULD use an encrypted SQL store per persona.

The reference implementation uses SQLCipher-backed SQLite databases, one per persona, with encrypted-at-rest FTS and embedding storage.

9.5 Logical Vault Schema

A Dina-compatible vault item model MUST be able to express:

The reference implementation's persona schema currently includes logical fields such as:

The protocol SHOULD freeze the logical schema, not the exact SQL DDL.

9.6 Search and Semantic Hydration

The protocol SHOULD support:

The reference implementation currently provides:

Important storage rule:

9.7 Backup and Export

Base Dina storage interoperability is logical, not file-format-level.

At minimum, conforming implementations MUST support:

Implementations MUST NOT create silent plaintext backups as a side effect of normal backup or migration.

Safe profiles therefore separate:

9.8 Encrypted Vault Portability Profile

The current implementation has more than one active DEK derivation style:

This matters only if the protocol wants to guarantee one of the following:

Those guarantees are useful, but they are not required for base Dina interoperability.

Therefore Protocol 1.0 MAY defer canonical DEK derivation at the core layer, provided it freezes:

If an encrypted vault portability profile is later standardized, it SHOULD define:

10. Layer 4: Agent Safety

10.1 Purpose

Agent Safety defines how agents interact with personal data and external systems without collapsing user sovereignty.

10.2 Protocol Requirements

A Dina-compatible safety layer MUST provide:

10.3 Session and Grant Model

The reference implementation already models:

An interoperable session model SHOULD include:

An interoperable access grant SHOULD include:

Grant scopes SHOULD at least distinguish:

10.4 Approval Model

An approval request MUST be portable across implementations.

Minimum approval fields SHOULD include:

The reference implementation already exposes this shape.

A draft machine-readable schema for this contract lives in:

Approval types currently include:

10.5 Intent Evaluation

A Dina-compatible agent safety layer MUST require agents to declare intent.

The current reference intent model is:

The current reference decision model is:

A draft machine-readable schema for executor intent declaration lives in:

10.6 Safety Rules

At protocol level, Dina safety has four core principles:

The reference gatekeeper already treats actions such as:

as risky actions that require explicit user review.

10.7 PII Scrubbing

A Dina-compatible implementation MUST support PII scrubbing before cloud or third-party egress.

The reference implementation currently provides:

The protocol SHOULD allow additional tiers, but MUST preserve the contract that scrubbed text can be safely passed onward and later rehydrated only within an authorized local context.

10.8 Audit

Every approval, denial, sensitive access, or denied egress SHOULD be auditable.

This is already present in the reference implementation and should remain a required interoperability expectation for serious implementations.

11. Layer 5: Dina-to-Dina Communication

11.1 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.

11.2 Protocol Requirements

A Dina-compatible D2D layer MUST provide:

11.3 Wire Model

The reference implementation currently uses:

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": { ... }
}

11.4 Message Families

The current Dina D2D v1 families are:

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

11.5 Message Policy

The current scenario policy model is:

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

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

11.6 Contact and Sharing Policy

D2D interoperability requires more than cryptography.

It also requires:

The reference implementation already models:

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.

11.7 Outbox and Offline Delivery

A conforming implementation SHOULD support durable offline delivery.

The reference implementation already has:

Outbox states currently include:

11.8 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.

11.9 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:

Example:

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

Recommended request modes are:

Recommended lifecycle states are:

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

Optional fields SHOULD include:

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:

12. Layer 6: Trust Network

12.1 Purpose

Trust defines how Dina-compatible systems publish verifiable outcomes and query world trust.

12.2 Protocol Requirements

A Dina-compatible trust layer MUST support:

12.3 Write Path

The intended Dina trust write model is:

The current reference implementation already has:

12.4 Collection Namespace

The protocol trust namespace is com.dina.trust.*.

The current broader design already includes a large set of collections, including families such as:

The protocol MUST freeze at least a minimal required subset for 1.0.

Recommended minimal core subset:

12.5 Read Contract

A Dina-compatible AppView SHOULD expose read-side queries for:

The reference implementation already exposes local Home Node handlers that proxy profile resolve and search to an AppView.

12.6 Trust Score Semantics

The protocol MUST separate:

Write interoperability requires a stable record namespace and shape.

Read interoperability requires that a trust profile can at least expose:

Exact scoring algorithms, including EigenTrust-style convergence, SHOULD be published as profile definitions rather than assumed to be globally frozen at the protocol core.

12.7 Privacy Rule

The Trust Network MUST NOT become a backdoor for private vault disclosure.

Only explicitly publishable, signed, public trust records belong in the trust layer.

13. Layer 7: Interaction Contract

13.1 Purpose

This is the missing interoperability layer most systems ignore.

Without it, two implementations may share identity, auth, D2D, and trust but still fail to behave similarly from the user's point of view.

The Interaction Contract layer standardizes:

13.2 Semantic Operation Registry

The protocol SHOULD standardize semantic operation types, not command spellings.

The registry itself is already part of the protocol design. The remaining 1.0 work is to freeze:

Implementations SHOULD advertise their supported semantic operations through the capability discovery layer rather than forcing remote peers to infer them from product-specific UI or command names.

Recommended primary semantic operations are:

Control operations:

Resource operations:

Trust operations:

Outbound delivery operations:

These are protocol semantics, not command names.

One implementation might expose:

Another might expose:

Another might expose no slash commands at all and use only buttons, forms, or plain language.

All of them remain interoperable if they preserve the same semantic contracts.

13.2A Outbound Delivery Semantics

The interaction protocol is not only human -> Dina.

It must also standardize when Dina speaks to the human without a fresh inbound command.

At minimum, a conforming implementation SHOULD support these proactive delivery semantics:

These are semantic contracts, not UI prescriptions.

One implementation may show a push notification.
Another may add a notification center item.
Another may surface the item only in a daily briefing.

13.3 Reference Mapping

The current Dina reference product maps its external command surface approximately as follows:

Resource examples:

Trust examples:

This mapping is explicitly non-normative.

13.4 Outer Contract vs Execution Graph

This is the key interaction rule:

Examples:

This rule is required to handle real scenarios such as:

13.4A Multi-Turn Interaction Frames

The protocol SHOULD model interactions as frames, not isolated stateless turns.

An interaction frame SHOULD carry at least:

Follow-up turns SHOULD remain within the existing outer contract unless the user clearly pivots.

Examples:

13.5 Counterparty Classes

The interaction protocol SHOULD distinguish:

This distinction matters because:

13.5A Persona and Sensitivity Scope

The interaction protocol SHOULD treat persona scope as part of routing, not merely storage.

At minimum, a conforming implementation SHOULD evaluate:

This is necessary for interoperable governance because:

13.6 Context Resolution

Before fulfillment, a Dina-compatible implementation SHOULD resolve:

This is what allows phrases like:

to become structured interoperable requests.

13.6A Delivery and Notification Contract

The interaction protocol SHOULD also standardize how work completion and failure are surfaced back to the human.

At minimum, implementations should distinguish:

This is the outbound half of Silence First.

13.7 Response Contract

The response layer SHOULD support a portable envelope with a small, typed set of response kinds:

This is not just UI polish. It is part of protocol interoperability because agents, Dinas, bridges, and clients need a stable result contract.

At minimum, the response envelope SHOULD freeze these core fields:

The response layer SHOULD also remain explicitly extensible. A conforming envelope MAY include:

This is important because different Dina-compatible ecosystems may allow different downstream behaviors while still remaining interoperable.

Examples:

The protocol should require that such additions be explicit and machine-readable rather than hidden inside arbitrary text.

A draft machine-readable schema for this contract lives in:

Implementations SHOULD advertise supported response kinds, envelope versions, and extension namespaces through the capability discovery layer.

13.8 Bridges vs Native D2D

Email, chat apps, and provider APIs remain important, but they are not the same thing as Dina-to-Dina communication.

The interaction protocol therefore distinguishes:

This preserves the qualitative difference between:

without requiring every implementation to expose those differences through the same UI.

14. Conformance Profiles

Not every implementation must implement every layer.

The protocol SHOULD define conformance profiles.

Implementations SHOULD advertise their supported profile identifiers through the capability discovery layer.

14.1 Home Node Profile

Implements:

This is the fullest Dina implementation.

14.2 Device Profile

Implements:

May delegate storage and D2D authority to a Home Node.

14.3 Agent Executor Profile

Implements:

May act only through a Home Node and does not own Dina identity or vault authority.

14.3A Agent Compliance Model

The protocol SHOULD be explicit about what it means for an agent to be Dina-protocol-compliant.

Not every agent that can call a Dina endpoint is Dina-protocol-compliant.

At minimum, the protocol distinguishes:

  1. Dina-compatible agent executor
  2. implements the agent-executor profile
  3. authenticates using Dina-compatible auth
  4. declares intent and caller identity
  5. obeys session, grant, approval, and egress controls

  6. consumes or produces supported interaction semantics through a Home Node

  7. Dina-aware agent

  8. can talk to a Dina-compatible Home Node or bridge
  9. but does not itself implement the required executor profile contract

  10. is integration-capable, not protocol-conformant

  11. Sovereign Dina implementation

  12. implements a fuller profile such as home-node, provider-dina, or mobile-home-node
  13. may also host or route work to one or more compliant agent executors

An agent therefore SHOULD NOT be described simply as \"Dina-compatible\" without a profile qualifier.

Recommended language is:

This avoids conflating:

14.3B Minimum Agent Executor Requirements

To claim the agent-executor profile, an agent implementation SHOULD at minimum:

An agent executor MAY be narrow.

For example, an implementation may legitimately support only:

provided it advertises that subset honestly and negotiates against the remote common subset.

14.4 D2D Service / Provider Profile

Implements:

May satisfy requests through direct lookup, internal tools, or delegated execution.

14.5 Trust AppView Profile

Implements:

Does not need to implement vault storage or agent safety.

14.6 Bridge Connector Profile

Implements:

This preserves interoperability without making bridges the protocol center.

14.7 Mobile Home Node Profile

Implements:

Delegates to hosted infrastructure:

This profile enables zero-cost sovereign operation
on a mobile device with no user-managed server.

15. Scenario Coverage

The protocol should be judged against scenario families, not only transport primitives.

15.1 Personal Memory

Pattern:

15.2 Live World-State Query

Pattern:

Example:

15.3 Social Coordination

Pattern:

Example:

15.4 Provider Request

Pattern:

Example:

15.5 Durable Delegated Work

Pattern:

15.6 Monitoring

Pattern:

Example:

15.6A Briefing and Proactive Delivery

Pattern:

Examples:

15.7 Trust Query

Pattern:

Example:

15.8 Trust Publication

Pattern:

16. Security Properties

At protocol level, Dina aims to guarantee:

17. Open Standardization Questions

17.1 Core Freeze Points

These should be resolved before calling the core protocol frozen:

  1. Root key material profile
  2. raw mnemonic entropy vs PBKDF2-expanded BIP-39 seed

  3. recommended 1.0 choice: 24-word BIP-39 mnemonic as recovery secret,
    PBKDF2-expanded BIP-39 seed as canonical root key material,
    with SLIP-0010 downstream derivation from that seed

  4. D2D generic request-state plane

  5. freeze request modes, lifecycle states, and required fields for federated execution

  6. recommended 1.0 choice: request modes inline_preferred, async, subscription;
    lifecycle states accepted, waiting_approval, waiting_input, running,
    partial, completed, failed, cancelled, expired;
    required fields request_id, correlation_id, requested_capability,
    response_mode, status, created_at, updated_at

  7. Trust core collection subset

  8. define the 1.0 mandatory namespace subset

  9. recommended 1.0 choice: com.dina.trust.attestation,
    com.dina.trust.vouch, com.dina.trust.flag,
    com.dina.trust.revocation, com.dina.trust.verification

  10. Capability discovery and negotiation

  11. freeze the capability advertisement contract, profile identifiers,
    extension namespace rules, and live negotiation semantics

  12. recommended 1.0 choice: static capability advertisement plus live negotiation,
    with profile identifiers at least for home-node, device, agent-executor,
    provider-dina, trust-appview, bridge, and mobile-home-node

  13. Interaction operation registry

  14. freeze the required core semantic operation set and extension rules

  15. recommended 1.0 choice: freeze semantic names and contracts for
    remember_context, answer_now, propose_plan, communicate_person,
    request_service, delegate_task, watch_condition, approve_operation,
    inspect_status, modify_existing, cancel_operation, recover_operation,
    deliver_briefing, deliver_alert, deliver_update, deliver_completion,
    deliver_failure, request_clarification, escalate_attention

  16. Response envelope schema

  17. freeze the portable typed response envelope and its extensibility model
  18. recommended 1.0 choice: response kinds summary, list, table,
    comparison, status, error, raw; required envelope fields
    schema_version, type, text, data; optional standardized fields
    title, meta, annotations, disclosures, extensions

17.2 Profile and Portability Questions

These affect optional profiles, not base protocol interoperability:

  1. Encrypted vault portability profile
  2. decide whether Protocol 1.0 will standardize canonical DEK derivation
    for encrypted vault interchange and seed-based encrypted recovery

  3. otherwise keep logical export/import as the required storage portability contract

  4. Mobile storage profile

  5. define minimum SQLCipher-equivalent encryption
    for iOS Keychain / Android Keystore integration
  6. define background/foreground lifecycle rules
    for DEK management on mobile

18. What "Dina as Protocol" Means

When this protocol is implemented correctly:

That is the transition from product to infrastructure.

19. Reference Implementation Status

The current Dina codebase already provides substantial pieces of this protocol:

The protocol document is therefore not speculative. It is extracted from a real system, while also identifying the exact points where the system still needs one canonical choice before the protocol can be declared stable.