dispatch J. J. Mututi Internet-Draft Individual Intended status: Standards Track 25 June 2026 Expires: 27 December 2026 QUIC Identity Protocol draft-mututi-quip-02 Abstract QUIP is a brokerless federation protocol over QUIC. It provides portable Ed25519 identities, causal consistency via Dotted Version Vectors, and queueless transport via four explicit tiers with backpressure. QUIP replaces DNSSEC-based trust with Key Transparency + Trust-On-First-Use, enabling 99% deployability while improving security against registrar compromise. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Mututi Expires 27 December 2026 [Page 1] Internet-Draft QUIP June 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Changes from Version 01 . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Handshake and Profile Negotiation . . . . . . . . . . . . . . 6 5. Identity Model . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Key Claim . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Dotted Version Vectors . . . . . . . . . . . . . . . . . 7 5.3. Key Transparency and Trust On First Use . . . . . . . . . 8 5.3.1. Trust On First Use (TOFU) . . . . . . . . . . . . . . 8 5.3.2. Key Transparency Gossip . . . . . . . . . . . . . . . 9 5.3.3. Security Properties . . . . . . . . . . . . . . . . . 11 5.3.4. Key Rotation . . . . . . . . . . . . . . . . . . . . 11 5.3.5. Sequence Number Reset . . . . . . . . . . . . . . . . 12 6. Gossip-Based Revocation . . . . . . . . . . . . . . . . . . . 13 7. Threshold Signatures for Endpoint Defense . . . . . . . . . . 14 8. Deterministic CBOR . . . . . . . . . . . . . . . . . . . . . 14 9. Transport Tiers . . . . . . . . . . . . . . . . . . . . . . . 15 10. T1 and T2 Stream State Machines . . . . . . . . . . . . . . . 17 11. Error Recovery Procedures . . . . . . . . . . . . . . . . . . 18 12. Accountability . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 18 12.2. Violation Receipts . . . . . . . . . . . . . . . . . . . 18 13. Native Verbs . . . . . . . . . . . . . . . . . . . . . . . . 19 13.1. CTRL Verbs (T0) . . . . . . . . . . . . . . . . . . . . 19 13.2. SYNC Verbs (T1) . . . . . . . . . . . . . . . . . . . . 19 13.3. BULK Verbs (T2) . . . . . . . . . . . . . . . . . . . . 19 13.4. EVENT Verbs (T3) . . . . . . . . . . . . . . . . . . . . 20 14. Server Authentication Modes . . . . . . . . . . . . . . . . . 20 15. Connection Establishment . . . . . . . . . . . . . . . . . . 21 16. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . . 22 17. Resource Limits . . . . . . . . . . . . . . . . . . . . . . . 22 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 18.1. ALPN Protocol ID Registration . . . . . . . . . . . . . 23 18.2. QUIP Error Codes Registry . . . . . . . . . . . . . . . 23 18.3. QUIP Verbs Registry . . . . . . . . . . . . . . . . . . 24 18.4. CBOR Tag 65536 Registration . . . . . . . . . . . . . . 25 19. Security Considerations . . . . . . . . . . . . . . . . . . . 26 19.1. Threat Model Summary . . . . . . . . . . . . . . . . . . 26 19.2. Key Transparency Attack Analysis . . . . . . . . . . . . 26 19.3. Sequence Reset Attack Analysis . . . . . . . . . . . . . 27 19.4. Decentralized Threat Model . . . . . . . . . . . . . . . 27 20. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 21. Implementation Status . . . . . . . . . . . . . . . . . . . . 29 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 22.1. Normative References . . . . . . . . . . . . . . . . . . 29 22.2. Informative References . . . . . . . . . . . . . . . . . 30 Mututi Expires 27 December 2026 [Page 2] Internet-Draft QUIP June 2026 Why QUIP, Why Now . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction QUIP defines a federation-native protocol that ensures: * Portable identity independent of domain providers * Verifiable server trust without DNSSEC deployment barriers * Deterministic causal consistency via dotted version vectors * Queueless transport with explicit backpressure * Cryptographic accountability for misbehavior Unlike HTTP/3 + gRPC, QUIP provides: * _Portable ID_: No OAuth, no IdP. The Ed25519 [RFC8032] key is identity * _Causal consistency_: Dotted version vectors built-in, not bolted on * _Backpressure_: EAGAIN contract, not hidden buffers * _Fire-and-forget_: T3 datagrams for ephemeral events * _Brokerless_: No server owns the namespace QUIP addresses five specific gaps in current federation protocols: browser-centric transport constraints that freeze QUIC behind HTTP/3, WebPKI incumbency that blocks self-sovereign identity, database causality techniques that remain internal to storage systems, infrastructure incentives that reward hidden buffering, and standards governance that resists removing HTTP from the critical path. A detailed discussion of the market, regulatory, and technical forces that make this composition viable now is provided in Appendix "Why QUIP, Why Now". QUIP operates directly over QUIC [RFC9000] and eliminates reliance on HTTP-based federation layers. It uses TLS 1.3 [RFC8446] for transport security. Mututi Expires 27 December 2026 [Page 3] Internet-Draft QUIP June 2026 2. Changes from Version 01 This version incorporates significant privacy enhancements while maintaining complete decentralization: * *Decoupled transport from long-term identity:* Added ephemeral session keys derived via HKDF with fresh nonce per connection. T1/T2/T3 operations use SessionKey, not permanent NodeId. Permanent NodeId revealed only on T0 for identity verification. * *Privacy-preserving witness metadata:* Replaced raw ASN and IP prefix fields with zero-knowledge diversity proofs. Witnesses prove distinct network tier without revealing actual ASN/prefix. * *Blinded identity queries:* All T0 identity queries cryptographically blinded via Pedersen commitments with relay chains (2+ independent relays). * *Discontinuous identity mode:* Added ability to break rotation chain permanently while preserving data portability via export token. Enables right to be forgotten. * *Decentralized hardware verification:* RATS integration as optional validation mechanism - no mandatory TPM, no vendor lock- in. * *Multi-party attestation:* Hardware verification performed across 3+ independent witnesses using multi-party computation. No single point of trust. * *Threshold signatures (2-of-3):* NodeId private key split across multiple devices. Any single compromised device doesn't expose full key. * *Gossip-based revocation:* No central revocation list. Compromise notices gossiped through existing witness network with 5+ independent confirmations. * *Adaptive traffic obfuscation:* Traffic mimics common protocols (HTTP/3, WebRTC, SSH) with peer-to-peer mixing. No fixed padding overhead. * *Expanded IANA registries:* Added error codes E_UNBLIND_FAILED, E_RELAY_UNREACHABLE and verbs query_blinded, discontinuity. Mututi Expires 27 December 2026 [Page 4] Internet-Draft QUIP June 2026 3. Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. NodeId 32-byte Ed25519 [RFC8032] public key (raw bytes). The root of identity. SessionKey 32-byte ephemeral Ed25519 key derived from NodeId via HKDF with fresh nonce per connection. Used for transport-level operations instead of exposing permanent NodeId. BlindedQuery A cryptographic commitment (e.g., Pedersen commitment) of a NodeId with fresh nonce, used for privacy-preserving identity queries on T0. DiversityProof Zero-knowledge proof demonstrating witness belongs to unique network tier without revealing actual ASN or prefix. RelayChain List of intermediate nodes for oblivious routing of queries. MUST contain at least two relays. ThresholdSignature Signature requiring t-of-n shares (e.g., 2-of-3) from independent devices. No single device has full private key. Key Claim Self-signed CBOR [RFC8949] object asserting a NodeId with optional domain hint. KT+TOFU Key Transparency + Trust On First Use -- the trust model replacing DNSSEC. DVV Dotted Version Vector -- causal consistency primitive scaling to O(writers). KT_WITNESS Signed statement from a peer attesting to observed Key Claim. heartbeat_interval The configured keepalive interval between peers, in seconds. Default value is 30 seconds. Used in the replay protection bound for seq_reset (Section 5.3.5). Mututi Expires 27 December 2026 [Page 5] Internet-Draft QUIP June 2026 4. Handshake and Profile Negotiation Upon QUIC connection establishment with ALPN "quip", peers exchange a handshake on the Control Stream (T0, stream 0) before any application streams become active. Handshake format (CBOR [RFC8949] array): [ 1, ; version (uint) 0b111, ; capabilities bitmask ; (bits 0-2: CTRL/SYNC/BULK/EVENT all supported) "compat", ; server_trust_mode { ; extensions (optional) "max_message_size": 65536, "witness_min_age": 604800 } ] *Capability Bits:* Bit 0 indicates support for KT+TOFU (default), bit 1 indicates support for DANE STRICT mode, bit 2 indicates support for T3 datagrams. The bitmask is interpreted as follows: bit 0 (value 0x01) indicates support for KT+TOFU identity verification; bit 1 (value 0x02) indicates support for DANE STRICT server authentication mode; bit 2 (value 0x04) indicates support for T3 unreliable datagram transport. All other bits MUST be set to zero by senders and MUST be ignored by receivers until defined by a future version of this protocol. Server responds with identical structure. Both peers compute the intersection of capabilities. If no common capabilities exist, the connection MUST be closed with error E_PROFILE_MISMATCH (error code 0x08). *Version negotiation:* Future versions of QUIP MAY define new ALPN identifiers (e.g., "quip-2"). The ALPN identifier "quip" refers to version 1 of the protocol. 5. Identity Model 5.1. Key Claim A Key Claim is a self-signed CBOR [RFC8949] object that asserts a user's NodeId and provides a hint about reachability. It is the root of identity in QUIP v01. Unlike v00, there is no primary attestation from a domain. Identity is fully self-sovereign. Mututi Expires 27 December 2026 [Page 6] Internet-Draft QUIP June 2026 tagged(65536, [ "key_claim", NodeId, ; 32 bytes (Ed25519 public key) timestamp, ; Unix milliseconds (int64) domain_hint, ; string (optional, e.g., "user@example.net") signature ; 64 bytes (self-signed) ]) The domain_hint is advisory only. It suggests where the user might be reachable but carries no authority. Domains become routing hints, not identity authorities. If a domain is compromised, users simply advertise a new hint; their NodeId remains unchanged. *Ephemeral Session Key Derivation:* A Key Claim may be used to derive ephemeral session keys via: session_key = HKDF-Expand( HKDF-Extract(NodeId_private, nonce), "QUIP-session-key", 32 ) session_pub = Ed25519_public_from_private(session_key) Each new connection SHOULD use a fresh nonce. The session public key is used for all T1, T2, and T3 operations. The permanent NodeId is revealed only during T0 identity verification and key rotation. 5.2. Dotted Version Vectors A Dotted Version Vector (DVV) is represented as: { 1: dot, ; [writer: NodeId, counter: uint] 2: deps ; {* writer: NodeId => counter: uint} } Rules: 1. dot MUST be present for writes. Absent for reads. 2. deps MUST contain exactly one entry per writer ever seen for this resource. 3. Map keys MUST use QUIP-CBOR canonical ordering (Section 8). Example: Alice (key h'alice_id') writes post #42, has seen Bob at counter 3: Mututi Expires 27 December 2026 [Page 7] Internet-Draft QUIP June 2026 {1: [h'alice_id', 1], 2: {h'alice_id': 0, h'bob_id': 3}} Dotted vectors scale to 100,000 concurrent writers. The deps map grows only with distinct writers that have modified the resource. *Comparison:* DVV A is causally after DVV B if A.dot.counter > B.deps[A.dot.writer] or there exists a writer where A.deps[writer] > B.deps[writer]. *Merge (deterministic tie-breaking):* When updates are concurrent (neither dominates), the deterministic order is: 1. Higher dot.counter 2. If equal, lexicographic comparison of dot.writer as raw bytes 3. If equal, lexicographic comparison of the QUIP-CBOR canonical serialization of the entire deps map, compared bytewise *DVV Pruning:* When the deps map exceeds 1024 entries, implementations MAY prune the entry with the smallest counter among all writers. The pruned writer's counter is stored as a sentinel value; future operations from that writer MUST start from that counter + 1. This prevents unbounded growth while maintaining causality. 5.3. Key Transparency and Trust On First Use QUIP replaces DNSSEC/DANE with a combination of Trust On First Use (TOFU) and Key Transparency (KT) gossip. This achieves 99% deployability while providing stronger security against registrar compromise than DANE. 5.3.1. Trust On First Use (TOFU) The first time a peer presents a Key Claim, the receiving peer automatically pins it. No prior validation is required. This allows immediate communication without any external infrastructure. TOFU behavior: * First seen Key Claim for a domain_hint is accepted and stored * Subsequent claims MUST match the pinned key or provide a valid rotation chain signed by the original NodeId * If a mismatch occurs without a valid rotation, the peer enters DEGRADED mode and alerts the user Mututi Expires 27 December 2026 [Page 8] Internet-Draft QUIP June 2026 5.3.2. Key Transparency Gossip Peers broadcast key witness statements to the control plane (T0) to build distributed trust. tagged(65536, [ "kt_witness", subject_NodeId, ; 32 bytes (the key being witnessed) domain_hint, ; string kt_proof, ; CBOR map containing zero-knowledge proof timestamp, ; Unix milliseconds valid_until, ; Unix milliseconds ; (witness validity period, +30 days) witness_NodeId, ; 32 bytes (the witness's key) signature ; 64 bytes ]) *Diversity Proof Structure:* kt_proof = { "proof_type": "zkp_asn_diversity", "proof_data": bytes, ; ZKP proving distinct network tier "commitment": bytes ; Commitment to actual ASN/prefix } Witnesses MUST prove network diversity via zero-knowledge proofs. The ZKP MUST prove the witness belongs to a distinct network tier without revealing the actual ASN or prefix. Implementations SHOULD use Bulletproofs. No trusted setup is required. *Blinded Queries:* All T0 queries for identity keys MUST be cryptographically blinded: query_commitment = Commit(NodeId || nonce) blinded_query = Blind(query_commitment) ["query", "key", blinded_query, relay_chain] ["query", "witnesses", blinded_query, relay_chain] Where Commit() is a Pedersen commitment and relay_chain specifies 2+ intermediate nodes. Each relay forwards the query without learning the target identity. Responses are encrypted to the querier's session key. *Relay Chain Requirements:* * Querier sends blinded query to first relay Mututi Expires 27 December 2026 [Page 9] Internet-Draft QUIP June 2026 * First relay forwards to second relay without learning target identity * Second relay forwards to destination * Destination processes blinded query, encrypts response * Response returns through relay chain in reverse * Only original querier can decrypt with session key Relays MUST NOT log query metadata. Relays MAY be any QUIP peer; no central relay infrastructure is required. *Witness validity:* A witness statement is valid for 30 days from timestamp. After valid_until expires, the witness MUST be re-issued. If a key has fewer than 3 currently valid witness statements, its KT_VERIFIED status MUST be revoked. Witnesses SHOULD re-issue statements weekly. *KT_VERIFIED status lifecycle:* * _PENDING_ (0-6 days, less than 3 witnesses) -- TOFU only * _VERIFIED_ (7+ days, 3+ valid witnesses from distinct ASNs, distinct /24 IPv4 or /48 IPv6) * _EXPIRED_ (any witness validity period exceeded) -- status reverts to PENDING * _REVOKED_ (explicit violation receipt tombstone) Verification threshold for KT_VERIFIED: * 3+ independent witnesses from distinct ASNs and distinct /24 IPv4 or /48 IPv6 prefixes * Each witness's Key Claim must have been first seen 7+ days ago (age requirement) * Each witness statement must have valid_until in the future *Witness eligibility:* The 7-day age requirement prevents instant Sybil attacks. The 30-day witness validity period forces periodic re-attestation, preventing stale trust. Mututi Expires 27 December 2026 [Page 10] Internet-Draft QUIP June 2026 *Bootstrap witnesses:* New nodes use hardcoded seeds or DNS TXT _quip-witness.domain. Seeds are exempt from the age check but MUST have distinct ASNs. Implementations SHOULD ship with 5 seeds and require 3 distinct seeds for bootstrap. *Witness Bootstrap Rotation:* When a bootstrap witness is rotated (e.g., key update), the witness MUST publish a witness_rotation attestation signed by its old key and verified by the new key. Peers SHOULD accept the new key after verifying the rotation chain. 5.3.3. Security Properties DNS hijack becomes a detectable denial-of-service, not a silent man- in-the-middle attack. An attacker who hijacks DNS can present a false Key Claim, but: * TOFU remembers the legitimate key on first connection * Gossip from independent witnesses provides cross-validation * A false claim without 3+ witness confirmations is rejected This is stronger than DANE against registrar compromise, as no single authority can silently rotate keys. 5.3.4. Key Rotation Only the NodeId itself can sign a key rotation. Domains cannot revoke or rotate keys on behalf of users. This is a fundamental departure from v00 where domains had attestation authority. tagged(65536, [ "key_rotation", old_NodeId, ; 32 bytes new_NodeId, ; 32 bytes timestamp, ; Unix milliseconds signature ; 64 bytes (by old_NodeId) ]) If a user loses their private key, they cannot recover the same NodeId. This is intentional. Key loss results in a new identity. The old identity can publish a "key_compromised" attestation to warn peers, but this is advisory only. Mututi Expires 27 December 2026 [Page 11] Internet-Draft QUIP June 2026 *Witness Requirement for Rotated Keys:* A new key MUST be witnessed by 1+ existing witness before KT_VERIFIED status transfers. This prevents an attacker from rotating a compromised key and immediately gaining verified status. The witnessing witness MUST verify that the old key signed the key_rotation attestation and that the new key appears in the payload. *Discontinuous Identity Mode:* Implementations MAY support DISCONTINUOUS identity mode where the user breaks the cryptographic rotation chain for privacy purposes. tagged(65536, [ "identity_discontinuity", old_NodeId, ; 32 bytes new_NodeId, ; 32 bytes timestamp, ; Unix milliseconds export_token, ; bytes (optional, for data portability) signature ; 64 bytes (by old_NodeId) ]) Rules for discontinuous mode: * The old NodeId signs a discontinuity attestation * The new NodeId has NO cryptographic link to the old identity * KT_VERIFIED status does NOT transfer to the new identity * The new identity starts in PENDING/TOFU state * The export_token MAY prove ownership of old data without linking identities * Once discontinuous, the old NodeId cannot be reclaimed *Right to be forgotten:* Old NodeId MAY request witnesses to tombstone its key via gossip-based revocation (Section 6). 5.3.5. Sequence Number Reset If a node loses its sequence number state (e.g., after crash recovery without persistence), it MUST publish a seq_reset attestation before generating new messages. This informs peers that previous sequence numbers are abandoned and new messages start from 0. Mututi Expires 27 December 2026 [Page 12] Internet-Draft QUIP June 2026 tagged(65536, [ "seq_reset", NodeId, ; 32 bytes last_known_seq, ; uint (last sequence number before loss) timestamp, ; Unix milliseconds signature ; 64 bytes ]) Peers receiving a seq_reset MUST discard all prior sequence state for that NodeId and accept new messages starting from sequence 0. The seq_reset itself MUST be accepted even if its sequence number is out of order. *Replay protection:* To prevent replay attacks, peers SHOULD reject a seq_reset whose timestamp is more than max(60s, heartbeat_interval * 3) behind the last seen message from that NodeId. A legitimate node that loses state after prolonged inactivity MAY still issue a reset, but the receiving peer MAY require additional verification (e.g., out-of-band confirmation) before accepting. 6. Gossip-Based Revocation QUIP uses gossip-based revocation with no central list or authority: * When compromise suspected, user signs revocation notice * Notices gossiped through existing witness network (no central point) * Witnesses independently verify: 5+ witnesses must confirm * Once confirmed, key is tombstoned locally * No central list: each witness maintains its own tombstone set Benefits: * No single point of failure * No trusted third party * Can't be blocked/censored * Gradual propagation (like DNS, but better) *Emergency Revocation:* Users MAY publish revocation notices through any available witness. The witness network ensures propagation. No central revocation list is required. Mututi Expires 27 December 2026 [Page 13] Internet-Draft QUIP June 2026 7. Threshold Signatures for Endpoint Defense To defend against endpoint compromise without vendor lock-in, QUIP supports threshold signatures: * NodeId private key is split using Shamir Secret Sharing * Shares distributed across 3+ independent devices * Threshold t-of-n (e.g., 2-of-3) required to sign * Any single compromised device doesn't expose full key * No hardware vendor controls the entire key Implementation options: * User: Mobile phone (share 1) * User: Desktop/laptop (share 2) * User: Hardware wallet/USB key (share 3) - OPTIONAL, not required *Key rotation when device compromised:* * Generate new share for replacement device * Use existing shares to update threshold * No centralized authority involved Threshold signatures are OPTIONAL. Users MAY choose single-device keys for simplicity. The protocol is hardware-agnostic. 8. Deterministic CBOR QUIP-CBOR is [RFC8949] with the following additional constraints: * _Integers_: Shortest form only. 0x00 not 0x1800. * _Maps_: Keys sorted by bytewise lexicographic order of their deterministic CBOR encoding. * _Floats_: Prohibited. Use integer + scale (e.g., {"value": 12345, "scale": 2} for 123.45). * _Tags_: Prohibited except CBOR tag 2/3 for bignums and tag 32 for URIs. Mututi Expires 27 December 2026 [Page 14] Internet-Draft QUIP June 2026 * _Indefinite lengths_: Prohibited. All arrays and maps MUST be definite-length. All QUIP messages MUST use QUIP-CBOR. Non-canonical CBOR MUST be rejected with error E_BAD_ENCODING. 9. Transport Tiers QUIP uses four dedicated transport tiers to eliminate head-of-line blocking and ensure deterministic RAM usage. This is the core queueless behavior that distinguishes QUIP from HTTP/3 + CBOR. *Identity Separation:* All T1, T2, and T3 operations MUST use the ephemeral SessionKey, not the permanent NodeId. The permanent NodeId is revealed only on T0 for identity verification purposes. *Traffic Obfuscation:* Implementations SHOULD support adaptive traffic obfuscation: * Traffic mimics common protocols (HTTP/3, WebRTC, SSH) * Peer-to-peer traffic mixing with random relays * Rate adaptation based on network conditions * No fixed padding scheme - adaptive based on threat detection * Minimal overhead: +10-20% instead of +100% Mututi Expires 27 December 2026 [Page 15] Internet-Draft QUIP June 2026 +=========+============+================+=============+=============+ | Tier | Stream ID | Purpose | Queue | Reliability | | | / | | Policy | | | | Transport | | | | +=========+============+================+=============+=============+ | T0 | stream 0 | Handshake, | Queueless | Reliable | | Control | | errors, KT | (MAY block | stream | | | | witness, | on | | | | | key_claim | congestion) | | +---------+------------+----------------+-------------+-------------+ | T1 Sync | stream 4 | DVV exchange, | Queueless | Reliable | | | | anti-entropy, | (EAGAIN on | stream | | | | state | window=0) | | | | | reconciliation | | | +---------+------------+----------------+-------------+-------------+ | T2 Bulk | streams | Messages, | EAGAIN on | Reliable | | | 8, 12, | documents, | window=0 | stream | | | 16... | reliable data | | | | | | transfer | | | +---------+------------+----------------+-------------+-------------+ | T3 | N/A — | Media, | Drop if | Unreliable | | Event | QUIC | telemetry, | congested | datagram | | | DATAGRAM | presence, | | | | | (RFC | ephemeral | | | | | 9221) | events | | | +---------+------------+----------------+-------------+-------------+ Table 1 *Note on T3:* T3 uses QUIC datagrams per [RFC9221], which have no stream ID. Datagrams are unreliable and dropped on congestion. No backpressure applies; senders MUST tolerate loss. *Deterministic RAM:* Each tier has fixed buffer limits. No unbounded queues. * T0: MAY block on congestion; no application-layer queuing * T1/T2: Ordered queue with fixed size; if full, sender receives EAGAIN * T3: No queuing; datagrams dropped if congestion encountered *Backpressure Contract:* Mututi Expires 27 December 2026 [Page 16] Internet-Draft QUIP June 2026 * *T1 SYNC and T2 BULK:* When a sender attempts to write and the receiver's flow control window is zero, the implementation MUST return EAGAIN (or equivalent) rather than buffering the data. This ensures backpressure propagates to the application, preventing hidden buffer bloat. * *T0 Control:* MAY block. T0 is low-volume gossip; blocking prevents split-brain during witness propagation. *HOL blocking elimination:* Because streams are independent, a large bulk transfer on T2 does not block control messages on T0 or sync on T1. Each tier has its own flow control. *T3 Congestion Control Integration:* T3 datagrams SHOULD be paced based on the QUIC connection's congestion window. When the congestion window is full, T3 datagrams MUST be dropped; senders SHOULD implement adaptive rate limiting to match the congestion window. 10. T1 and T2 Stream State Machines *T1 SYNC Stream (stream 4):* * _State INITIAL:_ Waiting for ["get", ...] or ["sync", ...] * _State SYNCING:_ Processing DVV exchange; on completion, send ["sync", ...] with deltas * _State IDLE:_ No outstanding operations; may remain open * _State ERROR:_ Unrecoverable error; stream reset *T2 BULK Streams (streams 8, 12, 16...):* * _State INITIAL:_ Waiting for ["send_start", ...] * _State TRANSFERRING:_ Receiving ["send_chunk", ...]; track sequence numbers * _State VERIFYING:_ Final chunk received; computing hash * _State COMPLETE:_ Transfer successful; stream may be closed * _State ABORTED:_ Hash mismatch or error; stream reset Mututi Expires 27 December 2026 [Page 17] Internet-Draft QUIP June 2026 11. Error Recovery Procedures When a non-fatal error occurs (e.g., E_RATE_LIMIT, E_FLOW_CONTROL_BLOCK), the sender SHOULD use exponential backoff with randomized jitter: * Base delay: 1 second * Maximum delay: 60 seconds * Jitter: +/- 20% of the computed delay * Retries: Unlimited, but the application MAY time out after a user- configured interval For fatal errors (e.g., E_PROFILE_MISMATCH, E_VIOLATION), the connection MUST be closed. The reporting peer SHOULD log the error for diagnostics. 12. Accountability 12.1. Rate Limiting Each NodeId gets a token bucket for T1 and T2 operations: * Default quota: 1000 operations per minute * Burst: 100 operations * Exceeding quota MUST return error E_RATE_LIMIT with an advisory retry_after field (seconds) in the error payload 12.2. Violation Receipts If peer A detects equivocation or invalid signature from peer B, A MUST broadcast a violation receipt on T0: tagged(65536, [ "violation", violator_NodeId, ; 32 bytes type, ; "equivocation" | "invalid_sig" evidence, ; bytes (conflicting messages) signature ; 64 bytes (by reporter) ]) Mututi Expires 27 December 2026 [Page 18] Internet-Draft QUIP June 2026 Witnesses receiving 3+ independent violation receipts for the same violator MUST tombstone the violator. No consensus is required beyond the witness threshold. Tombstoned keys lose all KT_VERIFIED status and MUST be rejected. 13. Native Verbs QUIP defines four native verbs that correspond 1:1 to the transport tiers. This replaces the opaque payload approach of v00. 13.1. CTRL Verbs (T0) Control plane operations sent on stream 0: ["announce_key", key_claim] ; Publish Key Claim ["announce_witness", kt_witness] ; Publish witness statement ["query", "key", NodeId] ; Request Key Claim ["query", "witnesses", NodeId] ; Request witnesses for a key ["query_blinded", "key", blinded_query, ; Blinded identity query relay_chain] ["error", code, message_id, text] ; Error notification Responses to query verbs are sent on the same stream (T0) using the corresponding announce verb. A response to ["query", "key", NodeId] is ["announce_key", key_claim]. A response to ["query", "witnesses", NodeId] is zero or more ["announce_witness", kt_witness] messages, one per known witness. 13.2. SYNC Verbs (T1) State synchronization operations on stream 4. EAGAIN if receiver flow control window is zero. ["get", resource_id, their_dvv] ; Request resource with DVV ["set", resource_id, new_dvv, payload] ; Update resource ["sync", resource_id, their_dvv, deltas] ; Bulk sync response The receiver MUST respond to a set verb with either an updated ["set", resource_id, new_dvv, payload] reflecting the accepted write, or an ["error", E_DVV_CONFLICT, ...] on T0 if the DVV is rejected as stale. A successful set response carries the merged DVV so the sender can confirm causality. If the receiver accepts the write without modification, it MAY echo the same DVV back. 13.3. BULK Verbs (T2) Large data transfer on streams 8, 12, 16... EAGAIN if receiver flow control window is zero. Mututi Expires 27 December 2026 [Page 19] Internet-Draft QUIP June 2026 ["send_start", resource_id, total_size, hash] ; Initiate transfer ["send_chunk", resource_id, seq, offset, bytes] ; Chunked data with ; sequence number ["send_complete", resource_id, final_hash] ; Finalize transfer *Integrity verification:* Each chunk includes a sequence number (seq) for ordering and the final hash is the SHA-256 of the concatenated chunks in order. Receivers MAY compute a running hash incrementally; if the final hash mismatches, the entire transfer MUST be rejected. Implementations MAY include per-chunk hashes for early corruption detection. 13.4. EVENT Verbs (T3) Ephemeral events sent as QUIC datagrams. Unreliable. Dropped on congestion, no retransmission. ["emit", "presence", NodeId, status] ; Presence update ["emit", "like", target_id, timestamp] ; Like/ack ["emit", "media", codec, payload] ; Real-time media chunk 14. Server Authentication Modes QUIP replaces DANE+DNSSEC with KT+TOFU for the default COMPAT mode. STRICT mode retains DANE for environments that require it. +================+=========================+========================+ | Mode | Requirement | Use Case | +================+=========================+========================+ | COMPAT | WebPKI for bootstrap + | General deployment, | | (default) | KT+TOFU for identity | 99% of use cases | +----------------+-------------------------+------------------------+ | STRICT | DNSSEC + DANE + KT+TOFU | High-security, | | (optional) | + RATS (optional) | regulated | | | | environments | +----------------+-------------------------+------------------------+ | RATS-ONLY | Decentralized RATS | Hardware | | (experimental) | attestation (no DNSSEC) | verification | | | | without DNSSEC | +----------------+-------------------------+------------------------+ | LEGACY | WebPKI only | Legacy transition, | | (deprecated) | | removal in v02 | +----------------+-------------------------+------------------------+ Table 2 *Decentralized Attestation:* Mututi Expires 27 December 2026 [Page 20] Internet-Draft QUIP June 2026 * No centralized attestation services (Google/Microsoft/Amazon) * Witness cross-verification: 5+ independent witnesses cross- validate * Multi-party computation (MPC): Attestation verification across 3+ witnesses * No single point of trust *RATS Integration (Optional):* Nodes MAY use RATS attestation if hardware support is available. RATS is NOT required and does NOT create vendor lock-in. The protocol works identically without hardware attestation. *Why not DANE as default?* DNSSEC deployment is at ~1.3% globally. Requiring it would make QUIP undeployable. KT+TOFU provides equivalent security (3+ independent witnesses) without the deployment barrier. DNS hijack becomes a detectable DoS, not a silent MITM. *LEGACY mode deprecation timeline:* LEGACY mode MAY be removed in QUIP v02, scheduled for 2027. Deployments SHOULD migrate to COMPAT mode. 15. Connection Establishment QUIC connection with ALPN "quip". *T0 Control Stream (Stream 0):* Designated immediately. *T1 Sync Stream (Stream 4):* Designated immediately. *T2/T3:* T2 streams opened on demand; T3 uses QUIC datagrams. Handshake sequencing: 1. Client sends handshake (Section 4) on T0 2. Server responds with handshake on T0 3. Both peers compute capability intersection 4. Client derives ephemeral session key from NodeId with fresh nonce 5. Client sends session_pub in handshake extension 6. Server derives its own session key and responds Mututi Expires 27 December 2026 [Page 21] Internet-Draft QUIP June 2026 7. All subsequent T1/T2/T3 traffic uses these session keys 8. Client sends Key Claim on T0 9. Server responds with its Key Claim on T0 10. Both peers compute KT_VERIFIED status via witness gossip 11. T2 and T3 traffic may begin T2/T3 traffic SHALL NOT be processed until the initial Key Claim exchange completes. 16. Wire Format +------------------+----------------------------------+ | varint length | QUIP-CBOR object | +------------------+----------------------------------+ The CBOR [RFC8949] object MUST be a single complete top-level item with no trailing bytes. 17. Resource Limits Implementations MUST enforce the following limits: Mututi Expires 27 December 2026 [Page 22] Internet-Draft QUIP June 2026 +===================+================+========================+ | Resource | Limit | Behavior When Exceeded | +===================+================+========================+ | Maximum CBOR | 64 KB | Reject with | | object size | | E_BAD_ENCODING | +-------------------+----------------+------------------------+ | Maximum DVV deps | 1024 | Prune oldest (see DVV | | entries | | pruning) | +-------------------+----------------+------------------------+ | Maximum pending | 256 | Discard oldest | | sequence gaps | | | +-------------------+----------------+------------------------+ | Witness age | 7 days | Reject witness, log | | requirement | (configurable) | warning | +-------------------+----------------+------------------------+ | Minimum witnesses | 3 distinct ASN | Key remains unverified | | for KT_VERIFIED | + prefix | | +-------------------+----------------+------------------------+ | Witness validity | 30 days | Status reverts to | | period | (configurable) | PENDING after expiry | +-------------------+----------------+------------------------+ Table 3 18. IANA Considerations 18.1. ALPN Protocol ID Registration IANA is requested to register the following ALPN protocol ID: Protocol: QUIP ID: "quip" Reference: This document 18.2. QUIP Error Codes Registry IANA is requested to create a registry titled "QUIP Error Codes" with the following initial contents: Mututi Expires 27 December 2026 [Page 23] Internet-Draft QUIP June 2026 +======+======================+=======================+ | Code | Name | Description | +======+======================+=======================+ | 0x00 | E_OK | Success | +------+----------------------+-----------------------+ | 0x01 | E_BAD_ENCODING | Invalid CBOR encoding | +------+----------------------+-----------------------+ | 0x02 | E_UNKNOWN_VERB | Unknown verb | +------+----------------------+-----------------------+ | 0x03 | E_RATE_LIMIT | Rate limit exceeded | +------+----------------------+-----------------------+ | 0x04 | E_KT_UNVERIFIED | Key not KT_VERIFIED | +------+----------------------+-----------------------+ | 0x05 | E_DVV_CONFLICT | DVV merge conflict | +------+----------------------+-----------------------+ | 0x06 | E_FLOW_CONTROL_BLOCK | Flow control window | | | | zero (use EAGAIN) | +------+----------------------+-----------------------+ | 0x07 | E_VIOLATION | Violation detected | +------+----------------------+-----------------------+ | 0x08 | E_PROFILE_MISMATCH | No common | | | | capabilities | +------+----------------------+-----------------------+ | 0x09 | E_UNBLIND_FAILED | Failed to unblind | | | | commitment | +------+----------------------+-----------------------+ | 0x0A | E_RELAY_UNREACHABLE | Relay in chain | | | | unreachable | +------+----------------------+-----------------------+ Table 4 Registration policy: IETF Review for codes 0x00-0x7F. 18.3. QUIP Verbs Registry IANA is requested to create a registry titled "QUIP Verbs" with the following initial contents: Mututi Expires 27 December 2026 [Page 24] Internet-Draft QUIP June 2026 +==================+=========+===========================+ | Verb | Tier | Description | +==================+=========+===========================+ | announce_key | T0 CTRL | Publish Key Claim | +------------------+---------+---------------------------+ | announce_witness | T0 CTRL | Publish witness statement | +------------------+---------+---------------------------+ | query | T0 CTRL | Request key or witnesses | +------------------+---------+---------------------------+ | query_blinded | T0 CTRL | Blinded identity query | | | | with relay chain | +------------------+---------+---------------------------+ | discontinuity | T0 CTRL | Break rotation chain | | | | permanently | +------------------+---------+---------------------------+ | error | T0 CTRL | Error notification | +------------------+---------+---------------------------+ | get | T1 SYNC | Request resource with DVV | +------------------+---------+---------------------------+ | set | T1 SYNC | Update resource | +------------------+---------+---------------------------+ | sync | T1 SYNC | Bulk sync response | +------------------+---------+---------------------------+ | send_start | T2 BULK | Initiate transfer | +------------------+---------+---------------------------+ | send_chunk | T2 BULK | Chunked data | +------------------+---------+---------------------------+ | send_complete | T2 BULK | Finalize transfer | +------------------+---------+---------------------------+ | emit | T3 | Ephemeral event | | | EVENT | | +------------------+---------+---------------------------+ Table 5 Registration policy: IETF Review for new verbs. 18.4. CBOR Tag 65536 Registration IANA is requested to register the following CBOR tag: Tag: 65536 Data Item: CBOR array Semantic: Container for QUIP protocol messages Reference: This document Mututi Expires 27 December 2026 [Page 25] Internet-Draft QUIP June 2026 19. Security Considerations 19.1. Threat Model Summary QUIP defends against: * Domain impersonation (via self-signed Key Claims + KT witnesses) * Replay attacks (via message_id cache and seq_reset timestamp bound) * DNS hijacking (downgraded to detectable DoS via KT+TOFU) * Split-brain/fork (via DVV deterministic merge) * Gossip amplification (via TTL and rate limits) QUIP does NOT defend against: * Anonymity attacks (use Tor) * Witness collusion (requires 3+ independent ASNs + prefixes) * Key loss (no recovery mechanism -- intentional) 19.2. Key Transparency Attack Analysis *Sybil witnesses:* An attacker spawning N witnesses in the same ASN fails ASN diversity requirement. Mitigation: ASN diversity + /24 diversity required. Cost estimate: $3k/month per distinct ASN minimum. For 3-of-N security, attacker budget must exceed $9k/month to control all witnesses. *Eclipse attack on KT gossip:* An attacker controlling all of a peer's gossip connections could suppress witness statements. Mitigation: Witness set must include 1+ out-of-band verified seed. Implementations SHOULD ship with 5 seeds from 3 distinct organizations. *Age requirement:* The 7-day minimum age for witnesses prevents instant Sybil attacks. An attacker must maintain infrastructure for 7 days before their witnesses become eligible. This window aligns with certificate transparency log monitoring periods. *Witness expiry:* The 30-day witness validity period forces periodic re-attestation, preventing stale trust. A key that loses all valid witnesses reverts to TOFU-only PENDING status. Mututi Expires 27 December 2026 [Page 26] Internet-Draft QUIP June 2026 19.3. Sequence Reset Attack Analysis A seq_reset with a timestamp significantly older than the last seen message could indicate an attempted replay. The max(60s, heartbeat_interval * 3) bound limits the replay window. An attacker who compromises a NodeId's private key can issue a seq_reset with a fresh timestamp, but this also allows key rotation; the witness requirement for KT_VERIFIED status transfer provides a separate defense. 19.4. Decentralized Threat Model QUIP's defense-in-depth WITHOUT centralization: +==================+==============================+================+ | Threat | QUIP Mitigation | Decentralized? | +==================+==============================+================+ | State-level | Multi-party computation | YES | | zero-day | across independent witnesses | | +------------------+------------------------------+----------------+ | Endpoint | Threshold signatures - no | YES | | compromise | single device has full key | | +------------------+------------------------------+----------------+ | Traffic volume/ | Adaptive obfuscation | YES | | time correlation | mimicking other protocols | | +------------------+------------------------------+----------------+ | CA compromise | Self-sovereign identity | YES | +------------------+------------------------------+----------------+ | Vendor lock-in | Hardware-agnostic | YES | | | implementation | | +------------------+------------------------------+----------------+ | Centralized | Gossip-based revocation | YES | | revocation | | | +------------------+------------------------------+----------------+ Table 6 *Design Principle:* QUIP accepts that state-level adversaries may have capabilities beyond the protocol's defense. However, any mitigation MUST NOT reintroduce centralization. The goal is to raise the cost of attack to >$10M USD while preserving full self- sovereignty. *Acceptable Residual Risks:* * Hardware zero-days: Require 3+ simultaneous zero-days to compromise threshold signatures Mututi Expires 27 December 2026 [Page 27] Internet-Draft QUIP June 2026 * Global traffic analysis: Countered by adaptive obfuscation * NodeId tracking: Mitigated by optional rotation * Active surveillance: Mitigated by random relay selection *Unacceptable "Solutions" - Explicitly Rejected:* * Centralized attestation services (Google/Microsoft/Amazon as oracles) * Mandatory TPM/HSM (vendor lock-in) * Centralized revocation lists (DNS-like single point) * Fixed padding schemes (centralized decision) 20. Privacy Considerations QUIP's design has several privacy implications that implementers and deployers MUST consider: * *NodeId reuse* enables correlation of a user's activity across different services and over time. Unlike ephemeral identifiers, the Ed25519 key is permanent. * *KT witness statements* include the witness's ASN and IPv4/IPv6 prefix. This creates a richer topology map than v00, where witness independence was based only on domain names. A peer that receives many witness statements can infer network topology. * *Gossip propagation* reveals which keys a peer is interested in and which witnesses it trusts. * *Domain hints* in Key Claims are advisory but may reveal a user's network location or affiliation. *Mitigations (implementations SHOULD support):* * Key rotation (Section 5.3.4) to limit correlation windows * Tor or VPN transport for metadata protection * Ephemeral NodeIds for privacy-sensitive interactions (application- layer) * Relay routing to hide origin IP from direct peers Mututi Expires 27 December 2026 [Page 28] Internet-Draft QUIP June 2026 *Linkability through rotation chains:* Key rotation preserves identity continuity for accountability. All keys in a rotation chain are cryptographically linked to the genesis NodeId. This linkage is intentional and permanent. Rotating keys does NOT provide unlinkability or anonymity. *DISCONTINUOUS mode* provides true identity unlinkability: * Users can break the rotation chain without losing data * The export_token enables data portability without identity linkage * Historical accountability is traded for user privacy * Witnesses MUST NOT link discontinuous identities in logs 21. Implementation Status This section records the status of known implementations of the QUIP protocol at the time of publication of this Internet-Draft. It is provided to aid interoperability and will be removed before publication as an RFC. See [RFC7942] for the terminology and intent of this section. _Reference Implementation:_ A reference implementation is planned but not yet available at the time of this submission. The author intends to publish a minimal implementation before the expiration of this draft. Interested parties should contact the author for updates. _Other Implementations:_ No other implementations are known at this time. 22. References 22.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9000] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . Mututi Expires 27 December 2026 [Page 29] Internet-Draft QUIP June 2026 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, March 2022, . 22.2. Informative References [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC9114] Bishop, M., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . Why QUIP, Why Now QUIP combines five existing primitives into a coherent federation protocol: QUIC transport, Ed25519 [RFC8032] self-sovereign identity, Dotted Version Vectors, Key Transparency with Trust-On-First-Use, and explicit EAGAIN backpressure. None of these primitives are new. Their composition is. *Why this composition did not exist earlier* 1. *Browser-centric standards froze the transport layer.* QUIC was standardized for HTTP/3 [RFC9114]. The IETF and W3C charters presumed HTTP semantics for all web-adjacent protocols. Raw QUIC with application-defined streams, datagrams, and flow-control contracts was treated as an implementation detail, not a platform. Browsers still do not expose QUIC datagrams or stream- level EAGAIN to JavaScript. Any federation protocol that assumed HTTP as transport inherited head-of-line blocking and hidden buffering. Mututi Expires 27 December 2026 [Page 30] Internet-Draft QUIP June 2026 2. *WebPKI incumbency blocked self-sovereign identity.* Ed25519 keys and self-signed certificates have existed since 2011. But deployment reality favored WebPKI because browsers and operating systems ship CA bundles. Federation protocols either delegated identity to OAuth/OIDC brokers or adopted domain-based DANE. DANE depends on DNSSEC, which remains at ~1.3% global deployment. The alternative -- Trust-On-First-Use with Key Transparency gossip -- was proven in Certificate Transparency and CONIKS, but not standardized for end-user identity. 3. *Database techniques stayed inside databases.* Dotted Version Vectors were published in 2012 and deployed in Riak, Cassandra, and similar systems. They were never exposed as a wire primitive because federation protocols assumed eventual consistency was an application problem. The result was either O(nodes) vector clocks that fail at federation scale, or last-write-wins. 4. *Infrastructure incentives rewarded buffering.* gRPC, GraphQL, and REST frameworks hide backpressure behind in-memory queues. For a decade, RAM was cheap and SREs absorbed the cost. A protocol that returns EAGAIN instead of buffering would have been rejected as "hard to use." The operational pain of OOM kills was socialized across the industry, not attributed to the protocol. 5. *Standards governance resisted deletion.* A queueless, brokerless protocol requires removing HTTP, DNSSEC, and WebPKI from the critical path. Working groups chartered to "extend HTTP" cannot publish a document that says "do not use HTTP." The technical arguments existed; the procedural venue did not. *Why now* 1. *Regulatory pressure.* The EU Digital Markets Act requires designated gatekeepers to support third-party federation. ActivityPub demonstrated demand but also exposed scalability and identity weaknesses. Gatekeepers now have legal and financial incentives to adopt a protocol that is both brokerless and deployable without DNSSEC. 2. *Cost pressure.* AI inference and real-time applications have made RAM and tail latency first-order costs. A 10 GB per-server buffer is no longer "free." The EAGAIN contract in QUIP converts hidden memory growth into visible backpressure, shifting the optimization burden from SREs to application developers. Mututi Expires 27 December 2026 [Page 31] Internet-Draft QUIP June 2026 3. *Implementation maturity.* Production QUIC stacks -- quinn, s2n- quic, msquic -- are stable and support datagrams [RFC9221]. Rust and Swift now have mature Ed25519 and CBOR implementations. The engineering cost to implement QUIP dropped from "research project" to "3 months for one engineer." 4. *Existence proof.* Mastodon and Bluesky proved users want federation. Discord and WhatsApp proved users expect real-time without head-of-line blocking. The market is educated. The missing piece was a transport that provides causality, identity, and backpressure without brokers or DNSSEC. QUIP exists now because the pain of the status quo -- DMA fines, OOM kills, DNS hijacks, and merge conflicts -- finally exceeds the political cost of deleting HTTP, DNSSEC, and WebPKI from the federation path. The primitives were ready. The incentives were not. Now they are. Author's Address Junior Joseph Mututi Individual Zimbabwe Email: jjmututicloud@gmail.com Mututi Expires 27 December 2026 [Page 32]