| … | … | @@ -180,15 +180,25 @@ ceremonies. Design them as two from the start rather than discovering it in prod |
| 180 | 180 | |
| 181 | 181 | ### 7.5 The peer owns the registry; favela-web reads it |
| 182 | 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. |
| 183 | **Decision (user, 2026-09-02).** **The peer** is the sole **writer** of favela's IdentityRegistry |
| 184 | autobase. favela-web is a **reader**, and every mutation it offers is an RPC to the peer — never a |
| 185 | direct append. |
| 186 | |
| 187 | ⛔ **"The peer" is a ROLE, and `hyper-proto-peer` is explicitly not it** (user, 2026-09-02). Which |
| 188 | daemon fills the role is open — see §10 item 6. |
| 189 | |
| 190 | That exclusion follows from this project's own thesis rather than being arbitrary. hpp is the |
| 191 | *self-custody **atproto** peer daemon*; once atproto is demoted from the canonical path to a |
| 192 | projection (`favela-markdown/spec/design.md` §1), hpp is describing a **bridge**, not a peer. Under |
| 193 | §6 it is the natural implementation of `bridge:bsky`, sitting beside ap-bridge as |
| 194 | `bridge:fediverse`. The full-mode peer — the thing that holds markdown records, owns this registry, |
| 195 | and drives the bridges — is a different role that does not exist yet. |
| 196 | |
| 197 | The *topology* is nonetheless already in place, whatever fills the role. favela-web treats a peer |
| 198 | daemon as its backend today: `favela-web/lib/cli.js:120` fails with *"no hpp connection — is the |
| 199 | local hpp running?"*, and `lib/auth.js:19` already describes favela-web as a *"keyless VIEW"*. That |
| 200 | comment was half right — favela-web does not need to **write** the registry. It does need to read |
| 201 | it. What changes is which daemon is on the other end of that socket, not the shape of the split. |
| 192 | 202 | |
| 193 | 203 | It is also exactly pear-git-v3's shape: the daemon owns the autobase, and the CLI and web talk to it |
| 194 | 204 | over UDS. `pgh` is the sole CLI and its daemon-RPC commands receive a hyper-svc client rather than |
| … | … | @@ -255,6 +265,11 @@ designed before either registry is in use would be designed against guesses. |
| 255 | 265 | the peer owns and writes it; favela-web reads. See §7.5. |
| 256 | 266 | 5. **Bridge credential custody.** §6.1 says a bridge holds its own secrets; where they live, and |
| 257 | 267 | what happens on device loss, is #49's question wearing a different hat. |
| 268 | 6. ⛔ **Which daemon is "the peer".** The role is decided (§7.5); the implementation is not. |
| 269 | `hyper-proto-peer` is ruled out by the user and is better understood as `bridge:bsky` under §6. |
| 270 | `favela-node` is *also* atproto-shaped — its README describes composing "a community's co-owned |
| 271 | atproto DID" — so it is not an obvious answer either. This is the largest open question in this |
| 272 | document: every other section assumes a writer exists, and nothing names it. |
| 258 | 273 | |
| 259 | 274 | --- |
| 260 | 275 | |