| … | … | @@ -185,7 +185,7 @@ autobase. favela-web is a **reader**, and every mutation it offers is an RPC to |
| 185 | 185 | direct append. |
| 186 | 186 | |
| 187 | 187 | ⛔ **"The peer" is a ROLE, and `hyper-proto-peer` is explicitly not it** (user, 2026-09-02). The |
| 188 | | role is filled by a **new daemon, `hyper-favela-peer`** (user, 2026-09-02) — see §7.6. |
| 188 | role is filled by a **new daemon, `favela-peer`** (user, 2026-09-02) — see §7.6. |
| 189 | 189 | |
| 190 | 190 | That exclusion follows from this project's own thesis rather than being arbitrary. hpp is the |
| 191 | 191 | *self-custody **atproto** peer daemon*; once atproto is demoted from the canonical path to a |
| … | … | @@ -222,11 +222,12 @@ machine is a fork waiting to happen**, and a web process is the wrong thing to h |
| 222 | 222 | user without consulting `isRevoked()` — so the gate belongs at the writer, and the reader's copy |
| 223 | 223 | is advisory only. |
| 224 | 224 | |
| 225 | | ### 7.6 `hyper-favela-peer` — the full-mode peer |
| 225 | ### 7.6 `favela-peer` — the full-mode peer |
| 226 | 226 | |
| 227 | | **Decision (user, 2026-09-02).** A new daemon, `hyper-favela-peer`, is the peer. It does not exist |
| 228 | | yet. Naming follows the house convention already carried by hyper-proto-peer, hyper-overlay, |
| 229 | | hyper-rooms, hyper-svc and hyper-identity. |
| 227 | **Decision (user, 2026-09-02; renamed 2026-09-05).** A new daemon, `favela-peer`, is the peer. It |
| 228 | does not exist yet. It was first named `hyper-favela-peer` after the house convention carried by |
| 229 | hyper-proto-peer, hyper-overlay, hyper-rooms, hyper-svc and hyper-identity; the `hyper-` prefix |
| 230 | marks the shared substrate, and this daemon is favela's, not the substrate's. |
| 230 | 231 | |
| 231 | 232 | It is the first component in this stack whose design starts from the markdown record rather than |
| 232 | 233 | from atproto, which is precisely why it cannot be an existing daemon adapted. Its job: |
| … | … | @@ -288,12 +289,12 @@ designed before either registry is in use would be designed against guesses. |
| 288 | 289 | the peer owns and writes it; favela-web reads. See §7.5. |
| 289 | 290 | 5. **Bridge credential custody.** §6.1 says a bridge holds its own secrets; where they live, and |
| 290 | 291 | what happens on device loss, is #49's question wearing a different hat. |
| 291 | | 6. **Sequencing `hyper-favela-peer` against everything else.** The peer is named (§7.6) but does |
| 292 | 6. **Sequencing `favela-peer` against everything else.** The peer is named (§7.6) but does |
| 292 | 293 | not exist, and both this registry and the markdown record path assume it. Whether the record |
| 293 | 294 | encoding lands first inside the existing store (`library.md` §10.1) or waits for the new peer is |
| 294 | 295 | undecided, and it is the biggest scheduling question in either document. |
| 295 | 296 | 7. **What becomes of `favela-node`.** It is the co-owned-DID *community* node and is also |
| 296 | | atproto-shaped by its own README. Whether it folds into `hyper-favela-peer`, becomes a bridge, |
| 297 | atproto-shaped by its own README. Whether it folds into `favela-peer`, becomes a bridge, |
| 297 | 298 | or stays a separate community concern is unexamined. |
| 298 | 299 | |
| 299 | 300 | --- |