You don't follow them, they don't follow you, but you both interact all the time. Paste a Bluesky handle and metamoots reads their follow graph (to know who to skip) plus their likes, reposts, replies and quotes — in both directions — and ranks everyone outside the follow graph by how much engagement actually runs both ways.
reads Bluesky's public AppView + your own PDS, all in your browser — no login.
| # | who | score | likes (out/in) | reposts (out/in) | replies (out/in) | quotes |
|---|
getFollows and
getFollowers in full — everyone in either list is
excluded from the start, since the whole point is people
outside the follow graph. Then it reads two directions of
engagement, both bounded so the crawl finishes in a reasonable
time: outbound (what the target did) comes straight off
their own PDS via com.atproto.repo.listRecords — up
to 500 recent likes, 300 reposts, and 500 posts (mined for replies
and quotes) — since those are ordinary public repo records and
need no special endpoint. Inbound (what others did to the
target) has no anonymous "who liked this account" endpoint, so
instead metamoots samples the target's ~30 most recent posts and
reads each one's public getLikes,
getRepostedBy, and direct getPostThread
replies. Every candidate's counts are weighted — like ×1, repost
×2, reply ×3, quote ×3 — and summed across both directions into a
score. Anyone with engagement on only one side is
held out of the main table and shown separately: a real
meta-mutual needs nonzero engagement in both directions, not just
a fan or someone you happen to like a lot. Because inbound only
samples ~30 posts, a real two-way relationship can land in
"one-sided" if the return engagement happened to land on an older
post outside the sample — worth a glance if the main table comes
up thin.