| … | … | @@ -0,0 +1,92 @@ |
| 1 | # favela-peer — scope |
| 2 | |
| 3 | **Status:** scoping. Nothing built. |
| 4 | **Date:** 2026-09-05 |
| 5 | **Defined by:** `favela-identity/spec/identity.md` §7.6 (the fission). This document scopes it. |
| 6 | **Lives here** because the peer spans identity, records and bridges — putting its scope inside any |
| 7 | one of those repeats the mistake hyper-social #58 §1 records. |
| 8 | |
| 9 | --- |
| 10 | |
| 11 | ## 1. What it is |
| 12 | |
| 13 | **Not a new daemon — hyper-proto-peer splits in two** (user, 2026-09-05). Both halves are existing, |
| 14 | running code: |
| 15 | |
| 16 | - **`bridge:bsky`** ← PLC, minting, rotation authority, the MST/commit signer, firehose, AppView proxy |
| 17 | - **`favela-peer`** ← records, the identity registry, admission, serving favela-web, driving bridges |
| 18 | |
| 19 | ⛔ **Success criterion, one question: does `favela-peer` still assume a per-identity public repo?** |
| 20 | The room is the container and a personal feed is a one-writer room (`SOCIAL-MODEL.md`), so a fission |
| 21 | that keeps the repo as the container has **moved** the atproto shape rather than left it. |
| 22 | |
| 23 | ## 2. The measured baseline |
| 24 | |
| 25 | What is actually there, at L0–L2 of the layer map (`SOCIAL-MODEL.md` §2.5): |
| 26 | |
| 27 | | | measured | |
| 28 | |---|---| |
| 29 | | `bootSwarmDevice` | **545 lines, 28 named parameters**, one function (`device-node.js:115-660`) | |
| 30 | | corestores | `store`, `membrane`, `atproto-repo-overlay`, plus `namespace('membrane:<did>')` | |
| 31 | | record store root | keyed by **roomKey** — `join(storage,'atproto-repo',roomKey.hex.slice(0,16))` (`:232`) | |
| 32 | | storage generations coexisting | **three** — pre-cutover own-corestore StateBase, shared-store namespace, RESYNC side stores | |
| 33 | | RESYNC references in the boot path | **54** | |
| 34 | | DID-root lock-in (moves or evaporates) | **~974 lines** — `rotation-cli` 295, `notifications` 179, `mint` 146, `rotation-guard` 143, `repo-mirror` 94, `rebuild-did` 67, `sessions` 50 | |
| 35 | |
| 36 | **That parameter count is the finding.** 28 parameters and 545 lines is what one function becomes |
| 37 | when a protocol's concerns accumulate in it. The scoping question is not "what shall we build" but |
| 38 | **"which of these 28 survive when the atproto half leaves"** — and each one is answerable by reading, |
| 39 | not by design. |
| 40 | |
| 41 | ## 3. What it inherits |
| 42 | |
| 43 | Already generic; comes across unchanged in kind: |
| 44 | |
| 45 | - `coowner` (245) — admitting another machine, which is **room admission** under the new model |
| 46 | - `adopt` (106) — blind-pairing device admission |
| 47 | - `cores` (316), `conflict-watch` (126) — diagnostics |
| 48 | - `device-node`'s multi-tenant orchestration (874) — becomes **multi-room** rather than multi-DID |
| 49 | - the whole L0/L1 substrate: `OverlayRepoStore`, `PointerSubstrate`, `hyper-overlay` |
| 50 | |
| 51 | ## 4. The open questions, and what would settle each |
| 52 | |
| 53 | Carried from `identity.md` §10. Each is annotated with the **layer** it lives at and whether it is |
| 54 | settled by measurement or by decision — the discipline of §2.5. |
| 55 | |
| 56 | | # | question | layer | settled by | |
| 57 | |---|---|---|---| |
| 58 | | 1 | where the registry autobase lives — own corestore or a namespace | **L1** | **measurement**: the daemon already namespaces three stores; read whether `IdentityRegistry`'s `prefix` + a namespace is sufficient, or whether blast-radius argues for its own | |
| 59 | | 2 | who admits the first writer; how a second device joins | **L2** | **measurement first** — `DeviceLinker` exists in `packages/hyper-identity`; read it before designing. This is also hyper-social #49 | |
| 60 | | 3 | ~120 DID-keyed call sites in `favela-web/lib` | **L4** | **measurement**: counted by grep, never audited. Sample them; most are probably mechanical | |
| 61 | | 5 | bridge credential custody | **L2** | **decision** — `identity.md` §6.1 says a bridge holds its own; where they live is #49 again | |
| 62 | | 6 | sequencing the fission | — | **decision**, and it got easier: the record layer is now closed | |
| 63 | | 7 | what becomes of `favela-node` | — | **measurement**: read it; it is atproto-shaped by its own README | |
| 64 | |
| 65 | ### 4.1 ⛔ One question this scope ADDS |
| 66 | |
| 67 | **Does RESYNC survive?** 54 references in the boot path exist because a poisoned autobase local writer |
| 68 | needs a fresh side-corestore re-join. hyper-social #43 records the root cause: genesis writer |
| 69 | derivation is deterministic (`deriveGsKeyPair(roomSeed)`), *"so a fresh corestore re-derives the |
| 70 | creator instead of shedding it"* — which forks for the creator where it is safe for everyone else. |
| 71 | |
| 72 | That is **L2, and it is not atproto's fault** — it follows from deriving a room's genesis writer from |
| 73 | its seed. So it survives the fission **unless the room's genesis derivation changes**, and that is a |
| 74 | question to answer *before* building, not after inheriting 54 references worth of recovery machinery. |
| 75 | |
| 76 | ## 5. What must be measured before building |
| 77 | |
| 78 | In order, and none of it is design work: |
| 79 | |
| 80 | 1. **`DeviceLinker`** (`packages/hyper-identity/lib/device-linker.js`) — the admission story is #2, #5 |
| 81 | and #49 at once, and it is the least-known piece. |
| 82 | 2. **`bootSwarmDevice`'s 28 parameters** — classify each as atproto / generic / scar. That single |
| 83 | classification is most of the fission. |
| 84 | 3. **`favela-node`** — read it; it may fold in, become a bridge, or be deleted. |
| 85 | 4. **A sample of the ~120 call sites** — enough to tell a mechanical rename from a model change. |
| 86 | |
| 87 | ## 6. What this scope does not claim |
| 88 | |
| 89 | - It does not estimate the work. Every number here is a measurement of what exists, not a projection. |
| 90 | - It does not settle the sequencing (§4 #6). |
| 91 | - It does not assume RESYNC is removable — §4.1 states it as an open question, not a saving. |
| 92 | - It is not a design. `identity.md` §7.6 defines the peer; this says what must be known to build it. |