| … | … | @@ -178,6 +178,40 @@ favela's signer election is the same shape. Granting a user `write` on `bridge:b |
| 178 | 178 | make its device a writer on the room's autobase. Both grants are needed, and they are separate |
| 179 | 179 | ceremonies. Design them as two from the start rather than discovering it in production. |
| 180 | 180 | |
| 181 | ### 7.5 The peer owns the registry; favela-web reads it |
| 182 | |
| 183 | **Decision (user, 2026-09-02).** `hyper-proto-peer` is the sole **writer** of favela's |
| 184 | IdentityRegistry autobase. favela-web is a **reader**, and every mutation it offers is an RPC to |
| 185 | the peer — never a direct append. |
| 186 | |
| 187 | This is not a new topology, it is the existing one extended to identity. favela-web already treats |
| 188 | the peer as its daemon: `favela-web/lib/cli.js:120` fails with *"no hpp connection — is the local |
| 189 | hpp running? (pgh app status hyper-proto-peer)"*, and `lib/auth.js:19` already describes favela-web |
| 190 | as a *"keyless VIEW"*. That comment was half right — favela-web does not need to **write** the |
| 191 | registry. It does need to read it. |
| 192 | |
| 193 | It is also exactly pear-git-v3's shape: the daemon owns the autobase, and the CLI and web talk to it |
| 194 | over UDS. `pgh` is the sole CLI and its daemon-RPC commands receive a hyper-svc client rather than |
| 195 | opening the store. Same split here, for the same reason — **two writers to one autobase from one |
| 196 | machine is a fork waiting to happen**, and a web process is the wrong thing to hold a write lock. |
| 197 | |
| 198 | **What follows:** |
| 199 | |
| 200 | 1. **Sign-in, credential linking, designating an atproto credential (§5.1), and bridge grants (§6) |
| 201 | are all peer RPCs.** favela-web renders the form; the peer performs the op and is the only thing |
| 202 | that appends. |
| 203 | 2. **The registry lives in the peer's storage**, which also settles §10 item 1: it is backed up and |
| 204 | blast-radiused with the peer, not with the web app. |
| 205 | 3. **A second device is a second peer**, admitted as an autobase writer — not a second web process. |
| 206 | That constrains §10 item 2: `DeviceLinker` blind-pairing runs peer-to-peer. |
| 207 | 4. **favela-web without a local peer can only read.** The SSR gateway serving other people's DIDs |
| 208 | has no write path at all, which is the correct and already-shipped posture (the own-repo write |
| 209 | gate) rather than a new limitation. |
| 210 | 5. ⚠ **A read is not a permission check.** favela-web reading `globalPermissions` renders UI; the |
| 211 | peer re-checks on every RPC. pgv3's audit found the mirror of this — surfaces that resolved a |
| 212 | user without consulting `isRevoked()` — so the gate belongs at the writer, and the reader's copy |
| 213 | is advisory only. |
| 214 | |
| 181 | 215 | --- |
| 182 | 216 | |
| 183 | 217 | ## 8. Migration |
| … | … | @@ -217,8 +251,8 @@ designed before either registry is in use would be designed against guesses. |
| 217 | 251 | 2. **Who admits the first writer**, and how a second device joins. `DeviceLinker` blind-pairing is |
| 218 | 252 | the candidate and is what #49 describes from scratch; it is not yet chosen here. |
| 219 | 253 | 3. **Scoping the ~120 call sites** — mechanical rename or genuine model change, per site. |
| 220 | | 4. **Whether the peer or favela-web owns the registry instance.** Both need it; only one should |
| 221 | | write it. |
| 254 | 4. ~~**Whether the peer or favela-web owns the registry instance.**~~ **CLOSED (2026-09-02)** — |
| 255 | the peer owns and writes it; favela-web reads. See §7.5. |
| 222 | 256 | 5. **Bridge credential custody.** §6.1 says a bridge holds its own secrets; where they live, and |
| 223 | 257 | what happens on device loss, is #49's question wearing a different hat. |
| 224 | 258 | |