Your tightest mutual-follow community, without downloading the follow graph. A thousand mutuals means about twenty thousand requests to know who follows whom — eleven minutes of staring at a spinner. This fetches rows in the order most likely to matter and shows you a real answer within seconds, which then only gets better.
Reading one account's follow list gives a complete row of the adjacency matrix,
not a sample of it, so a mutual edge is confirmed the moment both endpoints have been
read. Take the accounts read so far and find a set where everyone has at least
k mutuals inside that set: every one of those edges is real, and the
accounts not yet read can only add connections to them. So the group on screen
is a genuine k-core of the whole graph, found from a fraction of it.
More reading can raise k. It can never make what you are looking at wrong.
An unread account's in-degree from the rows already read is a free estimate of how central it is — if a dozen accounts you have already read follow it, it is probably in the same dense region they are. Reading highest-first assembles the core in the first few hundred rows instead of the last. On a planted test graph that is 80 rows against 389 for blind ordering.
"Everyone follows everyone" is maximum-clique: NP-hard, and brittle — one person who
missed one follow splits the group in two. "Everyone here has at least k
mutuals here" is linear to compute, survives a missing edge, and is a better
description of what a community actually is.
Follow lists are read from each account's own repository via
com.atproto.repo.listRecords rather than the AppView's
getFollows: half the bytes, and more complete — measured on one
account, the repo held 1,707 follow records where the AppView returned 1,509, having
quietly dropped follows to deactivated and blocked accounts. Followers have to come
from the AppView, since those are other people's records. Everything is cached in this
browser for six hours, so a second run is close to instant.