#Aims and reasoning
#The unit is a key, not a "main account"
A person should be able to communicate without handing a provider their phone number or email, and without maintaining a different app account for each part of their life. TalkCo uses cryptographic continuity instead of a central real-name directory. One person's experience may contain many spheres; that does not require one public identifier or public key that links them all (RFC6973).
#Contextual profiles: many faces, one person
The colleague who scans a work QR code should see a professional face and professional channels. The friend who receives a personal invitation should see the face intended for that relationship. Contextual profiles make this ordinary self-presentation explicit: the invite, exact username, or introduction through which someone arrives selects what they can initially see. The diagnosis is in §02; its theoretical grounding belongs in §02b.
A profile is a personal sphere, not a dossier curated separately for every contact. A sphere offers a default name, photos, bio, and channel selection. Per-contact exceptions remain possible, but using the app should not require continuous relationship classification.
#Revealing more over time
Relationships deepen without needing a formal account switch. An owner can reveal another photo, more profile material, or additional channels. The ordinary contact card becomes fuller; the client does not announce that a different profile exists. Sharing another username is a separate act because it offers another route of contact.
Multiple spheres may be intentionally revealed to one person. That recipient can know they share an owner. A shareable sphere may circulate through its intended audience; an owner-invite-only sphere still requires deliberate access. Neither should expose unrevealed spheres.
#Cold contacts see almost nothing
A raw identifier or third-hand username reveals only enough to decide whether to make contact. Rich public profile material exists only where its owner deliberately makes a sphere public or shareable. A public card does not make comments, relationships, engagement traces, or other spheres public.
#Names are local first
The working product model is petname-first. Contextual display names are non-unique; the everyday name for a contact is the recipient's local alias. An exact shared username is a locator, not a people directory. QR codes, invitations, and introductions are preferred because they can carry the contact context with the locator (SignalUsernames, SSBProtocolGuide).
There is no fuzzy people search, username browsing, public follower graph, public vouch count, or trust score. A future public-name integration such as ENS would be an explicit public identity choice, not the private locator default (ENSDocs).
#Trust is local and route-aware
The useful question is “does this key match the route by which I met this person?” A contact card can say Unverified, Introduced by Ana, or Verified directly. These labels describe the recipient's evidence; they are not network-wide badges. QR comparison is the preferred verification ceremony, followed by a safety-code or emoji comparison, with a raw fingerprint available for advanced use (SignalSafetyNumbers, MatrixSpec).
A link or a directory result can be substituted before first contact. Merely using a QR code or receiving a signature does not prove who a human is: verification depends on the authenticated route and comparison ceremony. Later trust hints must answer a bounded local question without publishing a social graph or turning introductions into status (GnuPGWebOfTrust, VCDataModel2).
#Contexts, not circles; no quantified closeness
Contexts arise as people use them. TalkCo does not require ranked circles or closeness scores before a relationship can begin. Closeness is expressed through what people choose to share and how they choose to be reached. A sphere may suggest “personal” or “work”; the recipient still controls interruption in §07.
#Recovery is a private bundle, not an account reset
Losing a device should not force a person to surrender identity ownership to a provider. The working recovery model is a user-held encrypted bundle and explicit device migration. A host can preserve ciphertext; it cannot invent continuity, reassign a sphere, or reset access by consulting a phone or email directory. Without protected recovery material, an authorized surviving device, or a prearranged recovery policy, contacts must verify new keys (SignalSVR, Kintsugi2025).
#Protocol and architecture
#How profiles relate to access
Profile separation and unlinkability are different claims. Grants can restrict which objects a recipient decrypts. Preventing an observer from linking two spheres also requires scoped identifiers, keys, endpoints, artifacts, and access patterns. An open client can expose any correlation already present in the protocol; client-side hiding cannot repair it (DIDCore, VCDataModel2, RFC6973).
A reveal grant changes authorized material. A recipient-scoped link grant explicitly permits two spheres to appear in one local card. Neither creates a public equivalence edge. Revocation affects future access and presentation; it cannot make a recipient forget a link or material already learned.
#The boundary that actually separates spheres
The private root is an implementation convenience, not a public account certificate. Its recovery and derivation scheme must not expose a common owner through public verification keys. A compromise of the local manager may still compromise several spheres; separate protocol identities do not isolate an already compromised device.
Correlation boundaries to test
| Surface | Required separation | Remaining leakage to measure |
|---|---|---|
| Identifiers and keys | Sphere/channel IDs, device credentials, wrapping keys, invite tokens, and migration authority | Reused signing keys or deterministic public derivation can reconnect spheres |
| Reach and transport | Scoped rendezvous handles, namespaces, push aliases, and authentication tokens | Common IPs, timing, volume, and distinctive endpoint combinations |
| Profile and content | Per-sphere profile objects and deliberate cross-context publication | Same photograph, text, social context, or recipient disclosure |
| Storage | Per-sphere/channel encrypted manifests and opaque custody references | Reused ciphertext hashes, fetch timing, sizes, billing, and repair patterns |
| Recovery | Encrypted private inventory; contact-visible succession records scoped to one sphere | A common recovery handle or provider account can link spheres |
Infrastructure endpoints can be shared by many unrelated users; requiring a unique endpoint per sphere may itself fingerprint the owner. The invariant is scoped authorization without a public owner link, followed by measurement of the complete traffic path. Fresh ciphertext locators reduce one correlation channel but do not make identical plaintext unrecognizable to readers.
#Likely implementation components
These are bounded uses of the shared technology inventory, not installed dependencies.
| Component | Proposed role and connection | Status / admission test |
|---|---|---|
| Rust core + platform keystore adapter | Own sphere keys and authorize device operations before storage or transport | Working candidate; verify target-OS key export, backup, and recovery behavior |
| SQLite / rusqlite; SQLCipher as an optional build | Store local aliases, grants, contact projections, and encrypted recovery indexes | First-slice candidate; database encryption does not protect a key already unlocked in a compromised process |
| Object AEAD + HPKE envelope | Encrypt profile revisions; wrap content keys only to validated recipient devices | Protocol candidate; RFC 9180 does not supply grant, replay, or recovery policy |
| Scoped authority records; COSE/CBOR candidate encoding | Authenticate device succession, grants, and permitted sphere links | Format candidate; avoid a shared public root and define conflict authorization before choosing bytes |
| p2panda-sync behind a TalkCo adapter | Reconcile authorized records and opaque payloads between paired devices | Research spike; native operation signatures and topic identifiers must not expose sphere links |
| Tessera-style log plus independent witnesses | Supply optional checkpoint consistency evidence | Gated alternative; neither a log nor its signature establishes human identity |
#Trust hints stay local
A conventional introducer signature remains transferable evidence even when its envelope is encrypted to one recipient. Recipient binding and expiry can limit accepted use, but they do not make a copied signature deniable. The first prototype can retain an authenticated local introduction note. Any stronger claim of non-transferable proof needs a separately reviewed authentication construction; public vouch credentials remain outside the product model.
Private-set or zero-knowledge hints are later options only for a bounded question such as whether an already trusted contact has seen a sphere key. They must not expose overlap counts, the introducer set, persistent graph edges, or ranking inputs. The trust research compares a local-history profile with optional scoped transparency.
#Recovery restores data before it restores authority
The bundle can preserve sphere material, profile manifests, local names, link decisions, storage indexes, and recovery authorizations. It must distinguish recoverable content from live ratchet/group state: restoring an old session snapshot can undo deletion, reuse cryptographic state, or revive a removed device. The recovery protocol therefore needs explicit rejoin and new-session rules rather than blind replay of a backup.
A password alone is unsuitable where an attacker can guess it against an exported bundle. High-entropy recovery secrets or a separately reviewed online/threshold recovery option must define that boundary. Passkeys may protect a local ceremony, but provider-synced authenticators add their own trust and availability dependencies. Public account-migration systems remain references for data transfer, not templates for private cross-sphere identity (ATProtoAccountMigration, MastodonMovingAccounts).
#Open questions and validation
- Sphere key hierarchy and metadata budget. Which keys and derivations can safely share a device manager, and which transport/storage observations defeat the declared anti-correlation profile?
- Offline device changes. What causal authorization and freshness rules admit device additions, removals, and recovery during partitions? Missing required evidence must leave a sensitive transition pending.
- Trust hints and deniability. Which introduction and link records need transferable evidence, and which require recipient-local authentication? Do not infer the latter from encryption alone.
- Recovery bundle. Specify protected fields, key rotation, old-session retirement, pairing, recovery quorum if any, and cross-sphere leakage tests before choosing a recovery provider.
The trust research page owns mechanism comparisons; §10 owns the shared authority boundary. No identity package has been adopted by this document revision.