OverviewFilesCommitsIssuesDocsReleasesPeers

favela-node commits / 3aa7e36

README: link sibling repos, which this tree already does and I did not
The convention was already here — favela-web and favela-node link siblings as [hyper-proto-peer](../hyper-proto-peer), favela-community as [hyper-rooms](../hyper-rooms). The READMEs I wrote from scratch had ZERO of them; the ones I only edited kept theirs. Measured before fixing: favela-bridge, favela-host, favela-identity, favela-markdown, favela-peer, favela-surface and favela-surface-android each had 0 relative links while mentioning 5-10 siblings by name. Linked on FIRST mention only, prose only. Skipped code fences, tables, existing links and URLs, and left later mentions as code spans so a paragraph does not turn into a row of blue. One case the automated pass got wrong and I reverted by hand: favela-surface's Boundary section lists the modules it may NOT import, as a uniform run of code spans. Linking hyper-overlay and ap-bridge there broke the list's formatting and read as "go read these" when the point is "never import these". Those two are code spans again. Rewrapped the lines the inserted links pushed past 100 columns, which is where the rest of this tree wraps. The long lines that remain in favela-community and favela-node are pre-existing prose — verified against HEAD — and one is inside a code fence. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3aa7e3648e828c5dc64e4ab626cf0b90af85e348
by plankatron <fleeky@gmail.com> · 2026-09-20T21:23:03.000Z

Changed files (1) +8 -4

README.md +8 -4
……@@ -3,13 +3,15 @@
33The **full-node** that composes a Favela community's two substrates (see
44[`favela-web/spec/lens-export.md`](../favela-web/spec/lens-export.md) §3):
55
61. the community's **co-owned atproto DID** — an [hyper-proto-peer](../hyper-proto-peer)-style identity
61. the community's **co-owned atproto DID** — an [hyper-proto-peer](../hyper-proto-peer)-style
7identity
78 whose admins co-sign its repo ([atproto-room](../atproto-room): `StateBaseV3` admins + `Lease` +
89 `Signer` / `LabelRoom` = the **multiswarm-PDS pattern**). Owns/signs the community's
910 `app.bsky.feed.generator` + `app.bsky.labeler.service` records and its `com.atproto.label` labels.
1011 It is the **owner** of those records; the service each one points at is a `did:web`, not this DID
1112 (see Notes).
122. the keyless **CommunityRoom** roster ([favela-community](../favela-community)) — the MEMBER audience
132. the keyless **CommunityRoom** roster ([favela-community](../favela-community)) — the MEMBER
14audience
1315 [favela-web](../favela-web) reads. The room's **mods == the DID's admins** (one attested set).
1416
1517A community is thus a **co-owned did:plc**: to bsky it's one account; behind it, N admins co-author with no
……@@ -18,9 +20,11 @@ single point of key custody — exactly how a multi-device hyper-proto-peer pres
1820## Which stack this belongs to
1921
2022The atproto / lens-export stack, alongside [favela-community](../favela-community) — not the
21markdown-record stack, whose rooms live in `favela-peer` on autobee and share none of this.
23markdown-record stack, whose rooms live in [favela-peer](../favela-peer) on autobee and share none
24of this.
2225
23Nothing imports this package. `serve.js` runs as a pgh daemon on tabertron, and what it uniquely holds
26Nothing imports this package. `serve.js` runs as a [pgh](../pgh) daemon on tabertron, and what it
27uniquely holds
2428is a **writable** store for `loser-club` — the one that could add or ban a member. It is not what keeps
2529the roster readable: measured 2026-09-20, favela-web on both tabertron and stortron holds its own
2630keyless replica of that room from its shipped default, stortron serves the live feed skeleton from