bfe3f9b · favela-identity

favela-identity commits / bfe3f9b

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>

bfe3f9b7524e332e6941c747f99ca7de2999cdc0

by plankatron <fleeky@gmail.com> · 2026-09-20T21:23:03.000Z

Changed files (1) +7 -4

README.md +7 -4

…	…	@@ -139,16 +139,18 @@ challenge for an attacker to keep trying proofs against.
139	139	whether that root holds that name, because this package has no registry and must not grow one. An
140	140	identity root is public, so a bridge that skips the second half hands a stranger the entire inbound
141	141	social graph of anyone whose username they can read off a web page. The second half lives in
142		ap-bridge's `collect.js`.
	142	[ap-bridge](../ap-bridge)'s `collect.js`.
143	143
144	144	Total: every path returns `{ ok, error }` and nothing throws. This runs on a request path fed by
145	145	strangers.
146	146
147	147	### `lib/peer-client.js`
148	148
149		`class FavelaPeer(sock)` — how anything reaches its own favela-peer over the local unix socket.
	149	`class FavelaPeer(sock)` — how anything reaches its own [favela-peer](../favela-peer) over the local
	150	unix socket.
150	151	Newline-delimited JSON, `{id, cmd, args}` → `{id, ok, value\|error}`, one request per connection,
151		30 s timeout. Not hyper-svc: the two daemons in this path speak different protocols and favela-peer's
	152	30 s timeout. Not [hyper-svc](../hyper-svc): the two daemons in this path speak different protocols
	153	and favela-peer's
152	154	is deliberately the smallest thing that works.
153	155
154	156	\| \| \|
…	…	@@ -186,7 +188,8 @@ Each one re-exports rather than reimplements:
186	188	`spec/identity.md` holds the account model this package belongs to: an account is a User, a DID is a
187	189	credential attached to it, a bridge is a resource it holds. favela made the atproto DID the root of
188	190	identity, which is why the DID cannot be rotated, why destroying a vault destroys the account, and
189		why there is no way to add or subtract a credential. pear-git-v3 has never worked that way —
	191	why there is no way to add or subtract a credential. [pear-git-v3](../pear-git-v3) has never worked
	192	that way —
190	193	`getIdentityByDid` sits beside `getIdentityBySSHKey` and `getIdentityByNoiseKey`, so a DID is a leaf
191	194	there, one credential among several hanging off a durable user record.
192	195