Sharing
Status, from /shipped/: proposed Key pair per user generated at first run; public bundle written to directory/ · absent Sharing an entry with another user through their inbox
Single-user wrapping works until a secret must be readable by a second person. You cannot wrap it with their passkey, because their PRF secret never leaves their device, and you cannot send it through the server in plaintext. The answer is a key pair per user. The user interface for sharing is phase 2 and absent from the MVP; the data model is phase 1, because adding it later would mean rewriting every keyring.
The scheme
- At first run each user's browser generates a key pair (RSA-OAEP 4096 for encryption, ECDSA P-256 for signing). The private keys go into the keyring body, protected by the passkey like everything else.
- The public keys are published as a signed bundle at
directory/{uid}.pub.json, readable by any signed-in user of the same environment. - To share, your browser fetches the colleague's bundle, encrypts the entry's key to their public key, and drops the result in
inbox/{uid}/{shareId}.json. Any signed-in user may create an inbox object; only the owner may read or delete one. - On their next unlock, their browser decrypts the inbox item with their private key and adds it to their own keyring.
The public key shares keys, not data. The server carries the package and can never read it.
What it drags in, designed up front
| Concern | Why it matters | Approach |
|---|---|---|
| Revocation | A removed member already holds the key | Rotate the key, re-encrypt, re-share to the remaining members |
| Directory trust | A compromised admin could swap a public key and intercept the next share | Signed bundles, and fingerprints users can compare out of band before a sensitive share |
| Group membership | Who can open what is real metadata, visible to the bucket | Membership stored per shared set; updated on add and remove; accepted as metadata exposure |
| Kinds kept apart | A vault key shared by mistake opens a whole vault | An sgit-vault-key entry refuses to enter a shareable set without a confirmation |
Fit with sgit
sgit already supports public and private keys (sgit pki) and is designed to store encrypted data on top of its own encrypted data. The keyring, the per-user key pairs and the inbox are applications of that capability, not new machinery. The public bundle will use sgit's JSON bundle shape so that sgit pki import can read what a browser published and sgit pki decrypt can open what a browser sealed. Both are marked "verify first" and recorded as open in brief-corrections.md.
What ships when
- Step 4: the key pair is generated and stored in the first keyring.
- Step 9: the public bundle is written to
directory/and the inbox rules go live, with the sharing interface still proposed. - Phase 2: the interface, revocation and fingerprints. A later version, not the MVP.