---
title: Stage 1 - Social Protocol (In-Transit Integrity)
type: reference
tags: :passepartout:roadmap:social-protocol:
created: 2026-05-24
---

← [[id:8cb760e2-37c6-4a78-af4d-f89f69d1678b][Stage 0 — Now]]  → [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Verification]]

# Stage 1: [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]]

*Summary: Every message is signed, DAG-tracked, and content-addressed.
Communication becomes provable - when you choose it to be.*

## What is added

- DID-based identity per participant (Ed25519 key pairs)
- Message-level authentication via JWE/JWS envelopes
- DAG of content-addressed messages for auditable history
- Channels for directed and broadcast communication
- End-to-end encryption (Double Ratchet, MLS) with perfect forward secrecy
- Ephemeral Notes via `ephemeral_duration` (time-locked encryption, key shedding, mandatory infrastructure GC)
- Off-the-Record (OTR) mode bypassing PDS storage entirely (volatile client memory only, clients prohibited from recording)
- Pseudonymous Personas for deniable identity
- Relays as transient routers (pub/sub model, no long-term storage)
- Onion routing between PDSs for metadata masking
- **Provenance store seeds:** signed data exchange for empirical parameters. When instances share a validated force field parameter or benchmark result, the message carries the experimental source signature and validation history. The receiving instance stores it with provenance — the first structured empirical data in the knowledge store

## What is eliminated

- **Message forgery** — every message is signed; you prove the sender
- **Message tampering in transit** — envelopes are authenticated; tampering changes the CID and breaks the chain
- **Impersonation / spoofing** — DID identity keys, not usernames
- **Replay attacks** — nonces and sequence numbers per message
- **MITM on social protocol-mediated channels** — end-to-end signatures; relays need no trust
- **Loss of message history** — DAG is append-only and content-addressed

## What does this cost?

- **Crypto overhead per message** — every message requires signing and verification.
  For high-throughput channels, this adds latency and CPU cost
- **DAG storage grows unbounded** — the append-only log never shrinks unless GC
  is explicitly designed
- **Key management burden** — DID resolution, key rotation, revocation. Lost keys
  mean lost identity. No "reset password" for DIDs
- **No anonymous participation by default** — DIDs tie every message to a
  cryptographic identity. Pseudonymity is a Persona choice, not the baseline

## What does this enable?

Provable communication infrastructure. You can prove who said what, when, and
to whom — or choose off-the-record privacy. Every subsequent stage builds on
this DAG: it is the source of truth for evidence, audit, and the accumulated
knowledge that later stages use for falsification.

## When is this viable?

Today. The social protocol is a protocol design that can be deployed on existing networks.
The infrastructure (PDS, Relay, Gateway) runs on conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]].

## In practice

Communication becomes provable - but only when the user chooses. The social protocol's Note
primitive supports the full spectrum: persistent DAG-stored messages for audit
and compliance, ephemeral Notes that self-destruct, and full Off-the-Record
(OTR) mode that bypasses PDS storage entirely.

The user chooses per-channel or per-message: permanent and attributable for
contracts and governance, ephemeral and deniable for private conversation. The
infrastructure enforces each choice - PDS garbage-collects expired CIDs, Relays
drop them from routing tables, clients shed message keys after display. The social protocol
replaces trust with evidence where evidence is wanted; elsewhere it provides
privacy by design.

The social protocol does not secure the endpoint. The machines running social protocol clients can
still be compromised at the OS, compiler, or hardware level. The keys are on
those machines - malware that compromises an endpoint can sign messages using
the endpoint's keys. The messages are authentic; the sender wasn't. The social protocol
carries the authorization; it doesn't evaluate it.

### Truth Layer — Contradiction Detection and Verification Economy

The provenance store seeds (signed empirical parameters) generalize to a
full **truth-accumulation layer** over the social protocol DAG. Every
knowledge assertion — not just parameters but any formal claim extracted
from Org prose by the LLM — is a signed, DAG-tracked message.

| Component | What it does | Depends on |
|-----------|-------------|------------|
| Signed knowledge assertions | Any instance asserts P (a formal claim) signed with its DID, Merkle-linked to source evidence | DID identities, DAG |
| Contradiction detection | The DAG flags when instance A asserts P and instance B asserts ¬P. Conflicts are protocol events, not bugs | Signed assertions, DAG query |
| Verification staking | Instances vouch for assertions with reputation or compute stake. Surviving challenges accumulate confidence; false assertions degrade the issuer's weight | Contradiction detection |
| Truth scoring | Every assertion carries a confidence tier: (1) extracted/LLM-guess → (2) locally consistent → (3) corroborated by N independent instances → (4) gate-enforced | Staking, corroboration count |
| Reasoner code exchange | The same protocol distributes CL reasoner prototypes. Users collaborate on the symbolic reasoner (Stage 2) before it enters the gate | Signed code, DAG versioning |

**The verification economy emerges naturally.** Instances that contribute
verified assertions gain reputation. Instances that propagate falsehoods
lose it. Over time, the protocol converges toward truths the same way
markets converge toward prices — without a central authority, through
incentive alignment.

**Cost:** Assertion storage grows with the DAG. Contradiction detection
requires O(log n) DAG traversal per new assertion — feasible at social-
protocol scale (thousands of instances, not millions). Verification
staking introduces economic attack surface (Sybil, collusion) that must be
modeled in the stake function.

**Bootstrap path:** The first assertions are LLM-extracted from Org prose
(confidence tier 1). Contradictions are initially rare (few instances,
sparse knowledge). As the instance count grows, contradiction frequency
increases and quality converges. This is Cyc's pump-priming problem solved
through network effects instead of hand-curation.

## Full Library Dependency Map

Stage 1 depends on three tiers of libraries: existing CL, new CL (need development), and bridged sidecars.

### Existing CL Libraries (ready now)

These are mature, production-tested Common Lisp libraries that require no development work:

| Library | Role in Stage 1 |
|---------|----------------|
| Ironclad | All crypto primitives — Ed25519, SHA-256, AES, ChaCha20-Poly1305, HMAC, DH |
| hunchentoot | HTTP server — PDS API endpoints |
| drakma | HTTP client — inter-PDS communication, sidecar calls |
| cl+ssl | TLS everywhere — server and client |
| websocket-driver | Real-time Relay connections |
| jonathan | JSON parsing/serialization — DID docs, JWE headers, API payloads |
| cl-sqlite | Message storage, user data, DAG index |
| local-time | Timestamps for Notes, DAG entries |
| bordeaux-threads | Concurrency — connection handling, parallel verification |
| alexandria | General utilities |
| log4cl | Structured logging |
| fiveam | Testing framework |
| cffi | Foreign function interface to C/Rust sidecars |
| usocket | Socket abstraction |

### New CL Libraries (need development)

| Library | What it implements | Key correctness challenge |
|---------|-------------------|-------------------------|
| cl-dag / cl-cid | IPLD Merkle DAG — CID encoding, multihash, DAG tree operations | Spec compliance (IPLD test vectors) |
| cl-did | W3C DID — Ed25519 key wrapping, DID document construction, did:key resolution | Spec compliance (W3C test suite) |
| cl-jose | JWE/JWS — envelope serialization, key wrapping modes, algorithm selection | Surface area (combinatorial spec, not deep math) |
| cl-double-ratchet | Signal Double Ratchet — DH ratchet, symmetric ratchet, associated data, header encryption | **Highest risk** — one byte wrong in associated data breaks every message |
| cl-bip | BIP-32/39/44 — mnemonic encoding, HD key derivation, hardened vs non-hardened paths | Silent failure (wrong derivation produces wrong keys, no error) |
| cl-didcomm | DIDComm v2 — message packing, forwarding, routing, attachment handling | Composes the above libraries; protocol logic correctness |

### Bridged Sidecars (initial release)

Replace native CL development risk with battle-tested implementations via CFFI or sidecar processes:

| Component | Bridge method | Source | Replaced by |
|-----------|--------------|--------|-------------|
| Double Ratchet | CFFI → libsignal | Signal's C library, MIT license | cl-double-ratchet |
| DID operations | CFFI → didkit | Spruce, Rust + C bindings, Apache 2.0 | cl-did |
| DIDComm | CFFI → didcomm-rust | DIDComm WG, C bindings, Apache 2.0 | cl-didcomm |
| DAG/CID storage | HTTP API → ipfs daemon | IPFS Go daemon, MIT license | cl-dag |
| BIP derivation | CFFI or sidecar | libbitcoin or bip-utils | cl-bip |
| JOSE envelopes | CFFI → libjose or OpenSSL CMS | libjose/OpenSSL | cl-jose |

### Infrastructure Code (Passepartout-specific)

These are not libraries but Passepartout systems that must be built:

| Component | Role |
|-----------|------|
| PDS server | HTTP/WS API, message routing, storage orchestration, gate integration |
| Relay server | Pub/sub message routing between PDSs, connection management |
| Client API layer | Protocol endpoints the mobile apps call |

### Risk Distribution

- **Low risk:** cl-dag, cl-did, cl-bip — published standards with test vectors, or bridged via sidecar
- **Medium risk:** cl-jose — large spec surface area but well-documented
- **High risk:** cl-double-ratchet — protocol logic depth, must get state transitions exactly right

The sidecar strategy collapses the high-risk items to near-zero implementation risk for the initial release.

← [[id:8cb760e2-37c6-4a78-af4d-f89f69d1678b][Stage 0 — Now]]  → [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Verification]]

:PROPERTIES:
:CREATED:  [2026-05-24 Sun]
:WEIGHT:  12
:ID:       4a1f23b0-abc2-4def-9876-543210abcdef
:END:
