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
-
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.
-
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.
-
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.
-
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.
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
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.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.
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.
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
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.