Post-1.0: how portable identity rides the mesh (gossip, DHT records, revocation)

Design placeholder, deliberately post-1.0. The manual backup file plus the id.peerd.ai ceremony (docs/design/portable-identity/, PR #360) make one did portable by hand-carry. The mesh could remove the hand-carry, and gossip is the natural transport, but each integration point has a distinct trust posture and none should be front-run.

Candidate integration points

1. Own-device record sync. Your other installs are just peers that share your did. A fresh recovery-record version (new wrapper enrolled, passphrase rotated) could gossip to them so every device holds the latest record without a file export. Conflict rule is trivial (updatedAt, same did), but the payload is sensitive recovery ciphertext: a record with a passphrase wrapper is an offline guessing oracle, so gossip-carry probably requires passkey-only records (no offline oracle; the KEK needs the authenticator) or explicit opt-in.

2. The DHT as the hosted record store (decision D-B). Design 02 already specifies an opaque locator derived from the PRF output on its own HKDF branch. A record stored in the DHT under that locator is the serverless version of hosted lookup: a fresh install with only a synced passkey taps once at id.peerd.ai, derives the locator, and fetches its record from the mesh. Needs: replication/expiry policy for DHT values, size caps, and an answer for the cold-start case where none of your devices are online.

3. Device-cert and revocation gossip (design 03). Once the person/device split lands, peers need to learn that a device cert was revoked or expired faster than by direct contact. Signed revocation entries are a good fit for retained-topic gossip; the trust rule stays simple because everything is verifiable against the person did.

4. Did continuity signals. Presence and the Agent Card already gossip. After a restore, a did reappearing on a new device is legitimate; the same shape is also what a compromise looks like. Whether peers should see (signed) device-set changes for dids they interact with, and what UX that feeds, needs its own thought.

Constraints to hold

• Anything gossiped is attacker-observable and replayable: only ciphertext with no offline oracle, or signed statements verifiable against the did, ever ride the mesh.
• Rate and size caps per did, same posture as the dweb actor's inbound caps.
• Store channel remains dweb-free; all of this is preview-channel surface.
• The frozen protocol constants (RP ID, PRF input, HKDF branches) are already load-bearing here; the locator branch exists precisely so this issue never needs new credential-side derivations.

Depends on

Capsule/record (shipped), the ceremony deployment (peerd-site#14), device subkeys (design 03, proposal), and the DHT (live). Nothing here blocks 1.0.

Start with docs/design/portable-identity/ and the references to Design 02 and design 03, then review the live DHT and preview-channel surfaces. This is a post-1.0 design placeholder covering several possible integrations, not a bounded implementation task. Done would require a separately scoped, decided design for one integration and its trust, replay, rate, and storage constraints.