Home › The Stack › Layer 2
LAYER 2 — PRIMARY BUILD

Trust Spanning — VTAs & TSP

The Trust Spanning Protocol (TSP): authenticated, optionally-confidential messaging between Verified Trust Agents over a transport-agnostic, cryptographically-secured channel. Direct Mode is fully implemented and tested.

Active — Direct Mode + Demo Flows Complete

What is the Trust Spanning Layer?

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 — Composable Event Streaming Representation), different cryptographic primitives (Ed25519 + HPKE-Auth), and a different relationship model (explicit RFI/RFA handshake).

What's Implemented

Layer 2 Direct Mode is fully implemented and tested. The following components are complete and operational, supporting VTA creation, relationship establishment (RFI/RFA), personhood ceremony, agent name registration, confidential messaging, and R-Card retrieval:

🌐

P2P Transport Interface

A clean TspTransport abstraction wrapping libp2p — TCP connections, noise encryption, yamux multiplexing, and the /tsp/1.0.0 protocol handler.

✅ Complete
🔢

Cryptographic Primitives

Ed25519 signing, X25519 key agreement, HPKE-Auth authenticated encryption (RFC 9180), and a CESR (Composable Event Streaming Representation) codec.

✅ Complete
🪪

Verifiable Identifiers

did:scid:vh and did:peer:4 VID creation, resolution, and cryptographic verification. Self-certifying identifiers — no network, no registrar, no DNS required.

✅ Complete
🗄️

Encrypted Key Storage

SQLite-backed keystore with Argon2id key derivation and AES-256-GCM authenticated encryption. Secure local storage for VID key pairs.

✅ Complete
🔐

TSP Message Sealing & Opening

TSP message structures, tspSeal() and tspOpen() for both plain (TSP_GEN) and confidential (TSP_GEN_CONFIDENTIAL) message types.

✅ Complete
🤝

Relationship Establishment

RFI/RFA handshake for peer-to-peer relationship formation. OOBI (Out-of-Band Introduction) encoding for peer discovery. Persistent relationship store.

✅ Complete
🔗

RelationshipManager

High-level orchestration API that ties together identity, transport, and message handling. The primary interface for building applications on Layer 2.

✅ Complete
🔒

HPKE-Auth Confidential Messaging

End-to-end encrypted messages using DHKEM(X25519, HKDF-SHA256) + ChaCha20/Poly1305. Sender identity is cryptographically bound to the ciphertext.

✅ Complete
🗺️

Routed Mode

Messages routed through intermediary nodes with metadata privacy. Long-lived, rotatable identities backed by Layer 1 VDR infrastructure.

Planned

How TSP Works

1. Identity: Verified Identifiers (VIDs)

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.

2. Discovery: OOBI

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.

3. Relationship Establishment: RFI/RFA

The initiating party sends a Relationship Formation Invitation (TSP_RFI) — a signed message containing a nonce and their full DID Document. The receiving party verifies the sender's VID, stores the relationship, and replies with a Relationship Formation Acknowledgement (TSP_RFA). After the handshake, both parties have a bidirectional, verified relationship record in their local SQLite database.

4. Messaging: TSP_GEN and TSP_GEN_CONFIDENTIAL

Once a relationship is established, parties can exchange:

  • TSP_GEN — signed, unencrypted application messages. The sender's Ed25519 key signs the message; the receiver verifies the signature against the sender's VID.
  • TSP_GEN_CONFIDENTIAL — HPKE-Auth encrypted messages. Uses DHKEM(X25519, HKDF-SHA256) + ChaCha20/Poly1305 for authenticated encryption between the sender's X25519 key and the receiver's X25519 key. Only the intended recipient can decrypt; the sender's identity is cryptographically bound to the ciphertext.

What's Next for Layer 2

The following capabilities are planned for future development:

  • Routed Mode — messages routed through one or more intermediary nodes, with metadata privacy (onion-style VID encryption for routing)
  • did:scid:vh production hardening — finalizing the rotation ceremony UX and Witness VTC bootstrapping for production deployments
  • Nested messages — TSP messages carrying other TSP messages (for relay and forwarding scenarios)
  • libp2p circuit relay — using libp2p's circuit relay as a TSP intermediary for NAT traversal
  • Additional transports — HTTP webhook, Bluetooth, QR-code-based message exchange
← Layer 1: Trust Support Layer 3: Trust Tasks →