#Aims and reasoning
#Verify the relationship without publishing a person-wide identity
A correct key is useful only relative to a question: who supplied it, through which route, for which context, and with which authority? A relay can identify its endpoint without proving a correspondent's identity. A directory can consistently repeat a key that the user never authorized. A mutual contact's introduction can establish a route without establishing universal trust.
§03 owns contextual profiles, local names, gradual reveal, and the private-root boundary. Cryptographic key isolation should support those ordinary interactions without making people curate a separate social profile for every contact. Own-device knowledge that two spheres share an owner must not become a public certificate by accident.
#Keep uncertainty visible and offline work possible
First-use continuity is weaker than direct verification. Lost-device recovery is a different event from changing a display name. The client should represent those distinctions plainly, while allowing actions that remain authorized during a disconnection. A quiet or offline participant is not socially invalid because they produced no recent activity.
Sensitive actions such as adding a device, widening an audience, or recovering a key may require fresh evidence. An unavailable witness must not silently weaken those checks. Equally, an optional directory outage should not block every ordinary local edit. Each profile must say which actions can proceed, which remain pending, and what evidence resolves them.
#Protocol and architecture
#What each method actually proves
| Mechanism | Useful evidence | Boundary |
|---|---|---|
| Trust on first use (TOFU) | Continuity from the first observed key | A malicious first key and unauthorized recovery remain possible |
| QR / NFC / SAS / safety code | Key comparison or possession in a verified ceremony | The route must be authentic; future device changes need their own rules |
| Recipient-local introduction | One accepted relationship route | Ordinary signed introductions can become transferable person/key certificates |
| Device succession / cross-signing | Transition under an accepted earlier key or rule | Scope and identity binding need review; signature validity alone is not authorization |
| Context membership history | Technical authority under a selected policy | Not personhood, social legitimacy, or global consistency |
| Scoped key transparency | History/consistency evidence and detectable equivocation when views can be compared | Not inherently private lookup or guaranteed detection for an isolated client |
| Witnesses / gossip | Independent observations of checkpoints | Cannot create legitimate authority or perpetual availability |
| WebAuthn / passkeys | Authenticator use and origin-bound credentials | Not a correspondent's identity; synced credentials add provider assumptions |
| DID / VC / KERI / PGP patterns | Optional naming, claims, or succession interoperability | Shared identifiers, issuers, metadata, and graphs can defeat context privacy |
| UCAN / Biscuit / Meadowcap | Action delegation after authority is accepted | Not automatic key discovery, human verification, or decryption |
| iroh / libp2p endpoint ID | Cryptographic transport endpoint continuity | Not TalkCo membership or permission to read |
Primary references include Signal protocols, DID privacy considerations, WebAuthn, and the key-transparency architecture work. Specifications and implementation support require version-specific review before adoption.
#Variation — Local history and direct verification
This profile minimizes directory dependence and makes a small offline prototype possible. It does not provide global split-view detection or establish that a peer has shown everyone the same device history. A key received through an unauthenticated link cannot be presented as verified simply because its self-signature is valid.
SQLite stores observations and accepted transitions; it does not supply their authorization. Platform keystores protect local key use subject to target-OS behavior. Pairing and device succession may borrow cross-signing interaction patterns, but TalkCo must keep their certificates scoped and evaluate their effect on private-authorship evidence.
#Variation — Scoped transparency and independent witnesses
A Tessera-style log can implement append-only storage and checkpoints; an application-specific directory layer, witness selection, monitoring, private queries, and authorization rules remain separate (Tessera, witness tooling). Conflicting checkpoints are observable only when the evidence can be compared. A valid logged key can still violate the user's accepted device policy.
#Trust profiles
| Context profile | Ordinary operation | Sensitive transition | Unavailable evidence |
|---|---|---|---|
| Ordinary relationship | Local continuity and optional direct verification | Explicit device/key-change handling | Show uncertainty; retain already authorized local work |
| Private shared context | Accepted membership and history rules | Device addition, recovery, and audience widening under the context policy | Leave transitions pending when required evidence is absent |
| High-risk context | Direct ceremony plus declared independent checks | Fresh scoped evidence and stricter recovery policy | No silent TOFU, public-directory, or direct-route fallback |
| Public discovery | Explicit unaudited lookup if that sphere permits it | Verification before granting private access | Discovery success alone grants nothing |
The table defines candidate behavior, not universal timeout values. Exact freshness windows, offline authorization, equivocation response, and conflict rules belong to #4 and #5.
#A private identity binding must not become a public certificate
Each edge can add a proof the application did not intend to expose. Pairwise keys do not prevent correlation if a global signing key, recovery handle, image URL, or stable endpoint reconnects them. Encrypting an ordinary certificate restricts its initial readership but not its later transferability. A contextual signing key with a deniable personal binding is a different candidate from a non-transferable message authenticator (authentication analysis).
Explicit local card linking is permitted. It should not publish a universal equivalence relation or cause other contacts to learn the link. A recipient deliberately told about two spheres can still disclose that knowledge; the protocol cannot promise otherwise.
#Key transparency is not decentralization
Logs, directories, and witnesses add operators and query patterns. Their scopes must be chosen before deployment: which identifiers are visible, how long history is retained, who may request it, who witnesses which checkpoints, and which actions require fresh evidence. A public root or witness transcript may improve consistency while breaking sphere isolation or private attribution. The proposed adapter must measure that tradeoff rather than calling transparency inherently private.
#Recovery without silent resurrection
Restored content and current authority are separate. Old-device pairing, offline bundles, or bounded third-party ciphertext custody can recover data under a previously accepted policy. They cannot let a host invent identity continuity. Recovery must also avoid reusing obsolete ratchet/group state or deriving intentionally erased content keys from a surviving root.
Archive keys, device roots, message ratchets, descriptors, and storage indexes need different retention rules. Passkey synchronization and OS backup behavior must be tested on the actual client target. A fresh recovery ceremony should not expose a public inventory of all spheres. §03 owns the user-facing pairing and migration flow.
#Peer discovery sequence
Discovery supplies a place to try, not permission to join. A private context must not query public discovery or fall back to a direct IP path simply because the preferred carrier is unavailable. Shared endpoints may conceal individual users among a larger set, while tokens and authorization remain separate per context. The networking research owns route-level leakage.
#Likely components and their boundary
| Candidate from the technology inventory | Proposed integration | Gate before adoption |
|---|---|---|
| SQLite / rusqlite | Local aliases, observations, accepted scoped history, and recovery indexes | Crash/rollback handling and protection of relationship metadata |
| Platform keystore; WebAuthn where appropriate | Protect local key use or authenticate an origin-bound ceremony | Target-specific export/backup, provider dependency, and lost-device recovery |
| Context-scoped control records, COSE/CBOR candidate format | Device succession and permissions under an explicit evidence profile | No global root; versioned authorization and proof-transferability review |
| p2panda-auth / p2panda-sync | Compare decentralized membership and history reconciliation | Exact conflict semantics, context separation, native signatures, and offline recovery |
| Tessera + witness tooling | Optional checkpoint/log backend behind a scoped directory adapter | Private queries, split-view tests, witness independence, freshness, and outage behavior |
| iroh / libp2p or privacy carrier adapter | Reach and authenticate a transport endpoint | Never derive application membership from peer identity; prohibit unapproved route fallback |
p2panda exposes separate synchronization, discovery, storage, encryption, and authorization crates (current project overview); that modularity supports a bounded integration experiment. Its native keys, topics, and signed operations still need an evidence and metadata review. A dependency must have one clear state-machine responsibility, not a second authority system hidden below the application.
#Falsification tests
- A substituted first key is never labeled verified without the required route evidence.
- Introductions, device certificates, migration, and recovery do not create unintended cross-context or personal-authorship proof.
- An old backup cannot restore revoked authority or intentionally erased key paths.
- Witness outages invoke the declared sensitive-action policy without silently weakening it or freezing unrelated local work.
- Local card linking works without publishing a universal owner edge.
- Multiple own devices use selected spheres without exposing the private root or the other spheres.
- Endpoint authentication and a valid directory entry never independently authorize membership, reading, or publication.
- Private routes do not fall back to public discovery or direct links without the profile's explicit authorization.
#Open questions and research links
#4 owns the key graph, ceremonies, recovery, and freshness; #3 owns transferable identity evidence; #9 owns route and witness-query leakage; #10 owns platform keystore, persistence, and background behavior.
Continue to encryption, access, network/storage, tools, or profile tests. Earlier evidence remains in Wave 1 and the September authentication note. Primary package-role checks were refreshed on 2026-10-24; no key-transparency or recovery implementation was exercised.