| … | … | @@ -184,8 +184,8 @@ ceremonies. Design them as two from the start rather than discovering it in prod |
| 184 | 184 | autobase. favela-web is a **reader**, and every mutation it offers is an RPC to the peer — never a |
| 185 | 185 | direct append. |
| 186 | 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. |
| 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. |
| 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,6 +222,29 @@ 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 |
| 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. |
| 230 | |
| 231 | It is the first component in this stack whose design starts from the markdown record rather than |
| 232 | from atproto, which is precisely why it cannot be an existing daemon adapted. Its job: |
| 233 | |
| 234 | 1. **Hold the canonical records** — `records/net.favela.post/<rkey>.md`, one file per record, with |
| 235 | the substrate unchanged: `{$oid,size}` pointers in a shared StateBase autobase, bytes in |
| 236 | hyper-overlay (`favela-markdown/spec/library.md` §10). |
| 237 | 2. **Own and write this registry** (§7.5) — the sole writer; favela-web reads. |
| 238 | 3. **Drive the bridges as resources** (§6). `hyper-proto-peer` becomes `bridge:bsky`; `ap-bridge` |
| 239 | becomes `bridge:fediverse`. Neither is the peer; both are things the peer configures and grants |
| 240 | authority over. |
| 241 | 4. **Serve favela-web** over the socket favela-web already expects a daemon on. |
| 242 | |
| 243 | ⚠ **This is a larger change than the record encoding it serves.** `favela-markdown/spec/library.md` |
| 244 | §10.1 is a per-collection extension fix inside an existing store; a new peer daemon is a new |
| 245 | component with its own storage, swarm identity, admission and lifecycle. Sequencing them is a real |
| 246 | question and §10 item 6 is now about *order*, not identity. |
| 247 | |
| 225 | 248 | --- |
| 226 | 249 | |
| 227 | 250 | ## 8. Migration |
| … | … | @@ -265,11 +288,13 @@ designed before either registry is in use would be designed against guesses. |
| 265 | 288 | the peer owns and writes it; favela-web reads. See §7.5. |
| 266 | 289 | 5. **Bridge credential custody.** §6.1 says a bridge holds its own secrets; where they live, and |
| 267 | 290 | 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. |
| 291 | 6. **Sequencing `hyper-favela-peer` against everything else.** The peer is named (§7.6) but does |
| 292 | not exist, and both this registry and the markdown record path assume it. Whether the record |
| 293 | encoding lands first inside the existing store (`library.md` §10.1) or waits for the new peer is |
| 294 | undecided, and it is the biggest scheduling question in either document. |
| 295 | 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 | or stays a separate community concern is unexamined. |
| 273 | 298 | |
| 274 | 299 | --- |
| 275 | 300 | |