What’s new in PACT 2
The identity is yours, not your host’s. Everything below follows from that one change; each item links to the section of the current text that specifies it, and the removed items say what their removal costs.
What changed, in one sentence
In PACT 1 the identity was a keypair held by the machine that ran the agent — one keypair per person, per agent installation, whose TLS client certificate was the identity — and a relay named in the card carried a person’s mail while that machine was offline (PACT 1 § 2, § 9). In PACT 2 the identity is a root certificate the person holds, a host serves it under a leaf the root issued, and there is no relay (§ 2, § 9).
Added or changed
- You own your identity. An identity is a self-signed root certificate whose private key lives in the person’s wallet and signs nothing but certificates; the root’s fingerprint is the identity’s name everywhere. The host holds a leaf the root issued for one address, valid for the span the person chooses, at most 398 days, and that one leaf key is the TLS certificate, signs every envelope, and is what contacts seal to (§ 2, § 14.1).
- A passkey can be your root. A wallet that can use a WebAuthn credential derives the root’s private key from the credential’s PRF output rather than generating and storing one — the same Ed25519 identity from any conforming wallet, indistinguishable on the wire — and proves the root before it signs anything (§ 2.1, § 2.2).
- The card carries a certificate. A contact card is a vCard with two required properties — the protocol major,
X-PACT-VERSION:2, andX-PACT-CERT, the leaf, which carries the endpoint, the leaf key, the issuing root’s fingerprint and the validity dates in one — and an optional sealing policy, in place of PACT 1’s separate address, key and gateway properties. A leaf is 400–500 bytes of DER, so the card stays under a kilobyte and reads from a QR (§ 3). - Renewal without ceremony. A renewal is the wallet issuing a new leaf for the same endpoint with a fresh key. Nothing is announced: a host carries its chain in its first envelope to each contact after a renewal, a contact that has not seen it asks for it, and because the endpoint is unchanged nobody has to approve it (§ 2). The newest leaf wins the instant it is seen (§ 14.3), and an envelope sealed to a key the host no longer holds is answered
certificate_renewedwith the current chain (§ 14.4). This replaces PACT 1’s key rotation: a signed hand-off under a grace period of up to 90 days, with both keys live meanwhile (PACT 1 § 2). - Move hosts without losing anyone. Moving is a new leaf for a new address and a call to
update_contactfrom there, carrying the new chain. The receiver validates the chain to the root it pinned — so this is provably the same person — and re-pins the address automatically, or asks its owner first, per itsaccept_new_hostssetting (§ 5.3). - Hosting instead of relaying. The hours a person’s own machine is off are covered by a host that runs the identity’s server all the time, under a leaf the person issued, and can be replaced. A host holds the leaf, its key and the identity’s data, never the root; a host that is left destroys the key and deletes every record; a leaf’s key is destroyed when the leaf expires (§ 9).
- Signing requests. A host asks a web wallet for a leaf with a form submitted by top-level navigation, carrying its certificate signing request, and receives the chain back in the fragment of its own address. The wallet shows the person the asking origin, the endpoint and the validity before it signs, and the person chooses the validity (§ 9.1).
- A portable export. Contacts, conversations and files move between hosts as one zip that holds no key of any kind. An importer checks the whole file before it writes anything, shows the person every contact before one is written, and ends the import with a new leaf from the person’s wallet (§ 9.2).
- Sealed envelopes hide the sender. An envelope’s header names one key,
kid, the recipient’s leaf; there is nofromand noto. The sender’s chain travels inside the ciphertext until the receiver holds the leaf, and is named by fingerprint after that; a receiver that cannot verify a fingerprint answerschain_required, the same to a stranger and to a blocked contact (§ 13.1, § 13.2). PACT 1’s header carried the sender’s and the recipient’s fingerprints in the clear (PACT 1 § 13.1). - An exact certificate profile and chain validation. Both certificates are specified field by field; a chain is exactly two of them; a verifier applies six rules in order and refuses at the first failure; and the compromise cases — what an attacker can hold, what stops it, what remains — are a table in the text (§ 14.1, § 14.2, § 14.5).
- Call budgets sized by the contacts an identity may hold. Every budget is a token bucket: a rate and a burst per contact, the identity’s contacts together at their number times that rate, and a guest budget of its own. The values in force are advertised in the
limitsmember ofget_card(§ 12). - Test vectors. Appendix B carries certificates to the profile, chain cases that name the rule each refusal fails, newest-leaf comparisons,
certificate_renewedanswers,v: 2envelopes and the passkey derivation, generated and proven against the text (Appendix B; the file).
Removed, and what each removal costs
- The relay. PACT 1’s card could name a relay: a store-and-forward gateway that queued sealed mail for a person whose machine was offline, and necessarily saw the sender, the recipient, the timing and the sizes of everything it carried (PACT 1 § 9). PACT 2 has no relay role: a node delivers directly, retries until the sender’s
expires, then reports failure to the sender’s human (§ 7, § 9). The cost: a machine that is not always on is not a PACT host; the answer is a provider, not a mailbox (§ 10). - Key rotation. PACT 1 rotated the identity key with a signed hand-off and a grace period (PACT 1 § 2). A PACT 2 root is never rotated; what is replaced is the leaf, by renewal. The cost: a lost or compromised root is the end of the identity, re-shared from a new one — deliberately, because whoever holds a compromised root could rotate too, and no ceremony could tell the two holders apart (§ 2, § 11).
- Coexistence with PACT 1. A card naming another major version is refused at intake, an envelope whose
vis not2is refused unopened, and an export ispact_export: 2, the only version there is; nothing converts (§ 3, § 13.3, § 9.2, § 12). The cost is the break itself: a PACT 1 card, envelope or export is refused, not translated.
Kept from PACT 1
The shape of the protocol is unchanged. Every participant exposes one MCP server, and sending a message is calling the other side’s tool (§ 6); contacts are vCards shared over the channels people already use (§ 3); invites are short URLs whose state lives with the issuer, revocable by deleting them (§ 4); adding a contact is always a manual, human approval (§ 5); conversations are threads a human can type into (§ 7); permissions are a per-contact switchboard (§ 8); a stranger reaches a guest tier of two tools (§ 6.1); and sealed envelopes carry identity and confidentiality past a terminating edge (§ 13).
Still not there, and said so
No forward secrecy at the envelope layer: a later compromise of a leaf key decrypts ciphertext recorded while that key was current, bounded by the leaf’s lifetime (§ 13.5). No recovery and no rotation of a lost root (§ 2). No post-quantum cryptography yet, deferred by decision with the path recorded (§ 13.5). No directory, no anonymity, and metadata that carriers see (the non-goals, § 11).