| … | … | @@ -158,6 +158,60 @@ network → a configured bridge instance → its credentials and endpoint. Two c |
| 158 | 158 | - A network in `reach` with no configured bridge is a **visible** no-op, reported like any other |
| 159 | 159 | projection loss (`library.md` §4) rather than silently dropped. |
| 160 | 160 | |
| 161 | ### 6.3 Where the DID lives after the demotion |
| 162 | |
| 163 | Measured 2026-09-05. Today the DID signing key has two homes: the vault |
| 164 | (`hyper-proto-peer/lib/config.js:8` — *"the self-custody key is written to the vault |
| 165 | (`<storage>/peer-identity.json`) on first boot… config.json is only consulted to MINT the vault"*), |
| 166 | and, for the multi-DID daemon, the per-DID swarm config bundle (`config.js:110`). |
| 167 | |
| 168 | **After the demotion the DID splits in two, and the halves go to different places:** |
| 169 | |
| 170 | | | what it is | where | |
| 171 | |---|---|---| |
| 172 | | **`did:plc:…`** the identifier | **public** | a credential row on the `User` in this registry (§3) — replicated, because there is nothing secret in it | |
| 173 | | **the signing key** | **secret** | **`bridge:bsky`'s own credential store** — §6.1: *"those are the **bridge's** secrets, not a person's"* | |
| 174 | |
| 175 | ⇒ **The DID key stops being the peer's identity and becomes one bridge credential among several**, |
| 176 | the same status as ap-bridge's RSA key. That is §4's demotion expressed as storage rather than as a |
| 177 | data model. |
| 178 | |
| 179 | **The vault survives with a different tenant.** `peer-identity.json` stops holding the DID key and |
| 180 | holds the **peer's own device identity** — the hyperident root and device proof that |
| 181 | `favela://<identity-root>` resolves against (`interaction.md` §3.4). |
| 182 | |
| 183 | #### 6.3.1 A thin bridge per peer, fronted by a keyless tier — and it already exists |
| 184 | |
| 185 | The custody worry was: if a bridge holds the DID key and a bridge is a shared service, self-custody |
| 186 | is gone. **It is not, because the bridge is already two tiers**, and only the inner one holds a key: |
| 187 | |
| 188 | ``` |
| 189 | favela-peer ── bridge:bsky (co-located, HOLDS the DID key, SIGNS) |
| 190 | │ signed commits + firehose over the swarm |
| 191 | ▼ |
| 192 | atproto-bridge — the keyless membrane (stortron / an HTTP endpoint) |
| 193 | holds NO keys, serves what the peer signed |
| 194 | ``` |
| 195 | |
| 196 | ✅ **Verified in source 2026-09-05:** `RepoManager`, `signCommit` and `privateKey` appear in |
| 197 | `atproto-bridge` **only under `pds/test/`** — nowhere in its production code. The membrane fetches a |
| 198 | peer's *already-signed* commit and serves it; `read-view.js`'s `getRepoFromCommit` is the keyless |
| 199 | path, and it **refuses** a commit that does not match the records it rebuilds. |
| 200 | |
| 201 | This is the peer/bridge split already recorded as the current architecture, given its proper name. |
| 202 | Two consequences worth stating: |
| 203 | |
| 204 | - **Self-custody is structural, not a policy.** The public tier cannot sign because it holds nothing |
| 205 | to sign with. Nothing has to be trusted not to. |
| 206 | - **Scaling the public tier costs no custody.** A second membrane, or a membrane on someone else's |
| 207 | hardware, adds availability and no key exposure — which is why `bridge:fediverse` (ap-bridge, which |
| 208 | *does* hold an RSA key) is single-instance by construction while the atproto membrane is not. |
| 209 | |
| 210 | ⚠ **Still open: device loss.** Where a bridge's secrets are backed up, and what happens when the box |
| 211 | holding them dies, is hyper-social #49 and is not answered here. |
| 212 | |
| 213 | --- |
| 214 | |
| 161 | 215 | ### 6.3 Retraction bookkeeping lives here |
| 162 | 216 | |
| 163 | 217 | `design.md` §6 identifies the one thing that cannot live in the record: to retract a post you must |
| … | … | @@ -324,8 +378,8 @@ designed before either registry is in use would be designed against guesses. |
| 324 | 378 | 3. **Scoping the ~120 call sites** — mechanical rename or genuine model change, per site. |
| 325 | 379 | 4. ~~**Whether the peer or favela-web owns the registry instance.**~~ **CLOSED (2026-09-02)** — |
| 326 | 380 | the peer owns and writes it; favela-web reads. See §7.5. |
| 327 | | 5. **Bridge credential custody.** §6.1 says a bridge holds its own secrets; where they live, and |
| 328 | | what happens on device loss, is #49's question wearing a different hat. |
| 381 | 5. ~~**Bridge credential custody.**~~ **ANSWERED 2026-09-05 — §6.3 below.** The DID splits in two, |
| 382 | and the tiering that keeps it self-custodial already exists. |
| 329 | 383 | 6. **Sequencing the fission against everything else.** §7.6 is now subtraction from hpp rather than a |
| 330 | 384 | new build, which lowers the risk but does not settle the order: whether the record encoding lands |
| 331 | 385 | first inside the existing store (`library.md` §10.1) or waits for the split. Still the biggest |