| … | … | @@ -222,29 +222,61 @@ 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 `favela-peer` — the full-mode peer |
| 226 | | |
| 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. |
| 231 | | |
| 232 | | It is the first component in this stack whose design starts from the markdown record rather than |
| 233 | | from atproto, which is precisely why it cannot be an existing daemon adapted. Its job: |
| 234 | | |
| 235 | | 1. **Hold the canonical records** — `records/net.favela.post/<rkey>.md`, one file per record, with |
| 236 | | the substrate unchanged: `{$oid,size}` pointers in a shared StateBase autobase, bytes in |
| 237 | | hyper-overlay (`favela-markdown/spec/library.md` §10). |
| 225 | ### 7.6 `favela-peer` — a FISSION of hyper-proto-peer, not a new daemon |
| 226 | |
| 227 | **Decision (user, 2026-09-02; renamed and reframed 2026-09-05).** `favela-peer` is the peer. It was |
| 228 | first named `hyper-favela-peer` after the house convention (hyper-proto-peer, hyper-overlay, |
| 229 | hyper-rooms, hyper-svc, hyper-identity); the `hyper-` prefix marks the shared substrate, and this |
| 230 | daemon is favela's, not the substrate's. |
| 231 | |
| 232 | ⛔ **It is not a new component beside hpp — hpp SPLITS IN TWO** (user, 2026-09-05). An earlier |
| 233 | version of this section called it "a new daemon… with its own storage, swarm identity, admission and |
| 234 | lifecycle", which would be exactly the hand-crafted layer that `hyper-social/docs/ROOMS-ARE-THE-COMPUTER.md` |
| 235 | warns against. It is the opposite: **subtraction**. Both halves are existing, running code. |
| 236 | |
| 237 | - **`bridge:bsky`** ← the atproto half: PLC, minting, rotation authority, the MST/commit signer, the |
| 238 | firehose, the AppView proxy. |
| 239 | - **`favela-peer`** ← what remains: records, this registry, co-ownership and admission, serving |
| 240 | favela-web, driving the bridges. |
| 241 | |
| 242 | **The lock-in, measured 2026-09-05** (line counts, headers read): |
| 243 | |
| 244 | | module | lines | exists because | |
| 245 | |---|---|---| |
| 246 | | `rotation-cli` | 295 | *"the operator surface for PLC rotation authority"* | |
| 247 | | `notifications` | 179 | proxies `listNotifications` to **bsky's AppView** | |
| 248 | | `mint` | 146 | *"create a NEW atproto identity"* | |
| 249 | | `rotation-guard` | 143 | *"can this node still CHANGE the identities it hosts?"* | |
| 250 | | `repo-mirror` | 94 | *"the atproto CONVERGENCE layer"* | |
| 251 | | `rebuild-did` | 67 | notary revival — export a DID's CAR | |
| 252 | | `sessions` | 50 | *"the swarm's bsky-login path"* | |
| 253 | |
| 254 | **~974 lines**, plus the signing half of `swarm-device.js` (879) — all of it downstream of the DID |
| 255 | being the identity ROOT and PLC being append-only. §4 demotes the DID to a credential, at which point |
| 256 | rotation stops being an operator ceremony with its own CLI and guard and becomes a registry op. Those |
| 257 | 438 rotation lines largely **evaporate** rather than move. |
| 258 | |
| 259 | Kept, because it was never atproto: `coowner` (245), `adopt` (106), `cores` (316), |
| 260 | `conflict-watch` (126), and `device-node`'s multi-tenant orchestration (874). |
| 261 | |
| 262 | **Its job:** |
| 263 | |
| 264 | 1. **Hold the canonical records** — `<room>/records/net.favela.post/<rkey>.md`, one file per record, |
| 265 | substrate unchanged: `{$oid,size}` pointers in a StateBase autobase, bytes in hyper-overlay |
| 266 | (`favela-markdown/spec/library.md` §10). |
| 238 | 267 | 2. **Own and write this registry** (§7.5) — the sole writer; favela-web reads. |
| 239 | | 3. **Drive the bridges as resources** (§6). `hyper-proto-peer` becomes `bridge:bsky`; `ap-bridge` |
| 240 | | becomes `bridge:fediverse`. Neither is the peer; both are things the peer configures and grants |
| 241 | | authority over. |
| 268 | 3. **Drive the bridges as resources** (§6). |
| 242 | 269 | 4. **Serve favela-web** over the socket favela-web already expects a daemon on. |
| 243 | 270 | |
| 244 | | ⚠ **This is a larger change than the record encoding it serves.** `favela-markdown/spec/library.md` |
| 245 | | §10.1 is a per-collection extension fix inside an existing store; a new peer daemon is a new |
| 246 | | component with its own storage, swarm identity, admission and lifecycle. Sequencing them is a real |
| 247 | | question and §10 item 6 is now about *order*, not identity. |
| 271 | ⛔ **The success criterion, and it is a single question: does `favela-peer` still assume a |
| 272 | per-identity public repo?** The room is the container |
| 273 | (`hyper-social/docs/SOCIAL-MODEL.md`), and a personal feed is a one-writer room — so a fission that |
| 274 | keeps the repo as the container has moved the atproto shape rather than left it, just with nicer |
| 275 | bytes. `favela-peer` holds **rooms**; `bridge:bsky` **gathers** the public ones into a repo. |
| 276 | |
| 277 | ⚠ **`favela-peer` is not the room.** Rooms are keet-shaped multi-writer autobases; the peer is the |
| 278 | node that holds them, serves the web and drives bridges. Building room machinery inside it would |
| 279 | reintroduce the layer this reframing removes. |
| 248 | 280 | |
| 249 | 281 | --- |
| 250 | 282 | |
| … | … | @@ -289,10 +321,10 @@ designed before either registry is in use would be designed against guesses. |
| 289 | 321 | the peer owns and writes it; favela-web reads. See §7.5. |
| 290 | 322 | 5. **Bridge credential custody.** §6.1 says a bridge holds its own secrets; where they live, and |
| 291 | 323 | what happens on device loss, is #49's question wearing a different hat. |
| 292 | | 6. **Sequencing `favela-peer` against everything else.** The peer is named (§7.6) but does |
| 293 | | not exist, and both this registry and the markdown record path assume it. Whether the record |
| 294 | | encoding lands first inside the existing store (`library.md` §10.1) or waits for the new peer is |
| 295 | | undecided, and it is the biggest scheduling question in either document. |
| 324 | 6. **Sequencing the fission against everything else.** §7.6 is now subtraction from hpp rather than a |
| 325 | new build, which lowers the risk but does not settle the order: whether the record encoding lands |
| 326 | first inside the existing store (`library.md` §10.1) or waits for the split. Still the biggest |
| 327 | scheduling question in either document. |
| 296 | 328 | 7. **What becomes of `favela-node`.** It is the co-owned-DID *community* node and is also |
| 297 | 329 | atproto-shaped by its own README. Whether it folds into `favela-peer`, becomes a bridge, |
| 298 | 330 | or stays a separate community concern is unexamined. |