The Trust Spanning Protocol (TSP, Rev 3): authenticated, optionally-confidential messaging between Verified Trust Agents over a transport-agnostic, cryptographically-secured channel. Direct Mode is fully implemented and tested, including post-quantum signing and hybrid key encapsulation.
Layer 2 is the messaging and identity layer — the protocol that lets two Verified Trust Agents (VTAs) find each other, establish a verified relationship, and exchange messages that are authenticated, tamper-proof, and optionally end-to-end encrypted.
The protocol at this layer is the Trust Spanning Protocol (TSP). TSP is transport-agnostic — it defines the message format, signing, encryption, and relationship handshake, but does not dictate how messages are physically delivered. The current implementation uses libp2p as the transport, but TSP could equally run over HTTP, Bluetooth, QR codes, or any other channel.
TSP is inclusive of DIDComm-like concepts (authenticated messaging between DID-identified parties) but is not based on DIDComm. It uses a different wire format (CESR 2.0 — Composable Event Streaming Representation), different cryptographic primitives (Ed25519 with optional ML-DSA-65 signing and HPKE-Base encryption), and a different relationship model (an explicit XRFI/XRFA/XRFD handshake).
Layer 2 Direct Mode is fully implemented and tested against the TSP "Implementor's Draft Rev 3"
wire format (our third revision — the on-wire version string is YTSP-AAC, or 0.2). The
following components are complete and operational, supporting VTA creation, relationship
establishment (XRFI/XRFA/XRFD), personhood ceremony, agent name registration, confidential
messaging, and R-Card retrieval — and every one of them ships in the open source
v0.1.0 npm release:
A clean TspTransport abstraction wrapping libp2p — TCP connections, noise encryption, yamux multiplexing, and the /tsp/1.0.0 protocol handler.
Ed25519 and ML-DSA-65 (post-quantum) signing, X25519 key agreement with an MLKEM768-X25519 hybrid KEM, HPKE-Base authenticated encryption (RFC 9180), and a CESR 2.0 codec.
✅ Completedid:scid:vh and did:peer:4 VID creation, resolution, and cryptographic verification. Self-certifying identifiers — no network, no registrar, no DNS required.
SQLite-backed keystore with Argon2id key derivation and AES-256-GCM authenticated encryption. Secure local storage for VID key pairs.
✅ CompleteRev 3 message structures with tspSeal() and tspOpen() for signed upper-layer payloads (XSCS) and confidential messages, framed as -E##/-Z## envelopes with a self-addressing digest (SAID).
XRFI/XRFA/XRFD handshake for peer-to-peer relationship formation — invite, accept, and decline. OOBI (Out-of-Band Introduction) encoding for peer discovery. Persistent relationship store.
✅ CompleteHigh-level orchestration API that ties together identity, transport, and message handling. The primary interface for building applications on Layer 2.
✅ CompleteEnd-to-end encrypted messages using HPKE-Base (DHKEM(X25519, HKDF-SHA256) + ChaCha20/Poly1305) — the mandatory confidential mode in Rev 3 — with an optional MLKEM768-X25519 hybrid KEM for post-quantum secrecy. The surrounding signed envelope binds the sender.
✅ CompleteMessages routed through intermediary nodes with metadata privacy. Long-lived, rotatable identities backed by Layer 1 VDR infrastructure.
Planned
Each participant generates a Verified Identifier (VID). The primary method is
did:scid:vh — self-certifying with hash-chained verifiable history, pre-rotation,
and witness attestation. did:peer:4 (self-certifying, no rotation) is also
available for quick development. In both cases, this creates an Ed25519 signing key pair and
an X25519 encryption key pair, encodes them into a
DID Document, and derives a self-certifying DID string from the document's hash. The entire
identity is self-contained — no network lookup, no registrar, no DNS.
To connect, one party shares an Out-of-Band Introduction (OOBI) — a small JSON object containing their VID and their libp2p transport address (PeerID + multiaddrs). This can be shared via QR code, link, copy-paste, or any out-of-band channel. The OOBI is not a secret.
The initiating party sends a Relationship Formation Invitation (XRFI) — a signed envelope carrying a nonce, a self-addressing digest, and (in this single-stack codebase) the sender's DID Document. The receiving party verifies the sender's VID and may reply with a Relationship Formation Acknowledgement (XRFA) or a Relationship Formation Decline (XRFD). After the handshake, both parties have a bidirectional, verified relationship record in their local SQLite database.
Once a relationship is established, parties can exchange:
XSCS) — application messages
(chat, credentials, protocol messages) carried inside a signed TSP envelope. The sender's key
signs the envelope and the receiver verifies it against the sender's VID. Signatures may use
Ed25519 or ML-DSA-65 (post-quantum).
TSP has moved through three revisions of the ToIP "Implementor's Draft". Layer 2 now speaks
Rev 3 — a flag-day wire-format change that replaces the earlier framing while
preserving every application capability on top of it. The version is carried on the wire as
YTSP-AAC (major 0, minor 2), so a mixed-version fleet fails loudly rather than
silently.
What changed from the previous revision:
-E## / --E##### signable envelopes with a -Z## payload tag, replacing the older -TAE generic group.4B## value, not a bare key.XRFI (invite), XRFA (accept), and the new XRFD (decline).The following capabilities are planned for future development: