Add "Followed by" / Followers view — surface who follows the user

[asherp]

Summary

Add a "Followed by" / Followers view that surfaces who follows the user on Nostr. Today nostr-mail only shows the outbound direction — the user's own follow list — and has no way to see who has added the user as a contact.

Current state in the codebase

The backend (tauri-app/backend/src/nostr.rs) only resolves the following direction by reading the user's own kind 3 (ContactList) event:

• fetch_following_profiles(...) — fetches the user's kind 3 event and resolves profiles for the p-tagged pubkeys they follow.
• fetch_following_pubkeys(...) — returns the bech32 npubs the user follows.

There is no function that resolves the reverse (followers). The Contacts page is populated from the follow list only.

Why this is non-trivial on Nostr (research)

Nostr follow lists (NIP-02, kind 3) are one-directional: an event lists who you follow, with no inverse index. To compute followers, a client must find every kind 3 event anywhere that contains the user's pubkey in a p tag — which a single relay generally cannot answer fully, and reverse-querying/counting all kind-3 events referring to a pubkey is prohibitively expensive to do naively. (NIP-02, Kind 3: Follow List)

This is fundamentally a social-graph indexing problem, which is exactly what a graph service is built to answer.

How other apps have handled it

• Indexer/aggregator services — clients historically relied on indexing services (notably nostr.band) that crawled relays and maintained a reverse follow index, exposing follower lists/counts via API. ⚠️ Update: nostr.band is no longer available, which removes the de-facto third-party follower index much of the ecosystem depended on, and is a strong argument for using our own graph infrastructure rather than a third party.
• NIP-45 COUNT — relays that support the COUNT verb can return an aggregate follower count ({"count": N}) without streaming every event, though support is inconsistent and the NIP has been contested. (NIP-45)
• Best-effort relay query — simpler clients subscribe for kind 3 events with a #p filter for the user's pubkey across configured relays and show whatever they find, accepting that it's incomplete.
• Caveat widely noted: for popular accounts a large share of "followers" are bots/spam, so raw counts are noisy.

Preferred approach: use our own Graph Name Service (asherp/GNS)

Rather than depend on a third-party indexer (now that nostr.band is gone), this is a good driver to lean on our own GNS (Graph Name System) project. GNS is a decentralized naming/discovery layer built on the Nostr social graph: it already runs Nostr relay clients with relay attribution, does BFS graph traversal over follow lists, and exposes an HTTP API with a TTL-based cache. Computing followers is the reverse-edge case of the graph it already builds.

Proposed direction:

1. Extend GNS to expose a reverse-follow / followers query (list + count) for a given pubkey, leveraging its existing graph traversal, caching, and relay-attribution layers. → tracked in Reverse-edge query: followers index (pubkey → who follows it) GNS#9.
2. nostr-mail backend (nostr.rs): add a fetch_followers(...) (+ optional fetch_followers_count(...)) that primarily queries GNS via its HTTP API, with a fallback to a best-effort relay #p kind-3 query (and optionally NIP-45 COUNT) when GNS is unavailable. Resolve profiles for the resulting pubkeys (reuse the path from fetch_following_profiles).
3. Frontend: surface results — e.g. a "Followers" / "Followed by" tab or sub-tab on the Contacts page, and/or a follower count on the Profile page. Indicate mutual relationships ("follows you" / "you follow") by cross-referencing the existing following list. GNS additionally enables provenance / graph-relative naming (e.g. how you're connected to a follower), which is a richer UX than a flat count.
4. Caching: cache follower results in the local SQLite store (like contacts are cached) since the query is expensive and incomplete in real time.

Acceptance criteria

• Backend can resolve followers (pubkeys + profiles) for the current user, primarily via GNS, with a graceful relay-query fallback and handling of incompleteness.
• UI surfaces followers (list and/or count), e.g. on Contacts and/or Profile.
• Mutual-follow state is indicated where known (cross-referenced with the existing following list).
• Results are cached locally to avoid repeated expensive queries.
• Clear UX messaging that follower data is best-effort/approximate on Nostr.

Open questions

• Data source priority: GNS as primary (preferred) with relay #p fallback — confirm. Do we still want NIP-45 COUNT as a fast-count option where supported?
• GNS deployment: which GNS endpoint does nostr-mail talk to (self-hosted vs. a hosted instance), and is it configurable in Settings?
• Where to surface it: a Contacts sub-tab, the Profile page, or both? Show provenance/paths from GNS, or just a flat follower list to start?
• Spam/bot filtering — apply any trust-rank/heuristics, or show raw results?
• Privacy: querying an external GNS instance still reveals interest in a pubkey — default-on or opt-in?

Related

• Reverse-edge query: followers index (pubkey → who follows it) GNS#9 — Reverse-edge query: followers index (pubkey → who follows it). This issue consumes that API. (Motivated by nostr.band's disappearance.)

Sources

• NIP-02 — Follow List
• Kind 3: Follow List — Nostrbook
• NIP-45 — Event Counts (COUNT)
• asherp/GNS — Graph Name System

[asherp]

How fetching followers actually works on Nostr — and what GNS now exposes

One clarification that simplifies the design a lot: finding direct followers does not require walking the graph or expanding it to any depth. It's a single reverse query, not a BFS.

The core mechanism: a reverse #p query on kind 3

NIP-02 follow lists are one-directional, but relays index event tags. So "who follows X" is one subscription:

["REQ", "followers", { "kinds": [3], "#p": ["<hex-pubkey-of-X>"] }]

Every relay holding a kind-3 (contact list) event that tags X returns it; the author of each such event is a follower. The relay does the reverse lookup against its tag index — the client never walks anyone's follow list. The cost isn't depth, it's breadth of relay coverage: a follower only shows up if at least one relay you query has their latest kind-3. So the result is always a lower bound, never a census — which is the right framing for the "best-effort/approximate" UX messaging in the acceptance criteria.

Minimal client-side version (the relay fallback path described in this issue):

// Subscribe across configured relays, keep the NEWEST kind-3 per author, stop on EOSE.
const followers = new Map(); // author pubkey -> { event_id, created_at, relays:Set }
//   on EVENT(ev): if ev references X in a #p tag AND ev.created_at is newer than stored,
//                 store { ev.id, ev.created_at, relays:{thisRelay} }
//   on EOSE:      close the sub for that relay

Two things to handle explicitly: (1) re-confirm the #p tag actually references X — the relay-side filter is advisory, not a guarantee; (2) dedupe to the newest kind-3 per author across relays, since people re-publish their contact list.

GNS now exposes exactly this (GNS#9 → done, shipped in GNS#10)

The reverse-edge endpoint has landed: GET /api/followers. It does the multi-relay #p fan-out, keeps the newest kind-3 per follower, and attaches provenance — so it slots directly into the "primary via GNS" path proposed here:

GET /api/followers?pubkey=<npub|hex>&limit=50&offset=0

{
  "pubkey": "…", "npub": "npub1…",
  "count": 42, "limit": 50, "offset": 0,
  "followers": [
    {
      "npub": "npub1…",
      "pubkey": "…",
      "follow_event_id": "f03bcf09…",                 // the exact kind-3 that tags you
      "relays": ["wss://relay.damus.io", "wss://relay.primal.net"],
      "created_at": 1781158059
    }
  ],
  "best_effort": true                                  // lower bound, not a census
}

So fetch_followers(...) in nostr.rs can be a thin HTTP call to GNS, with the raw #p REQ above as the offline/unavailable fallback. follow_event_id + relays give provenance for free (where each follow was seen), and best_effort is the honest "this is approximate" flag the UI can surface. Paging is limit/offset.

On a few of the open questions

• Fast counts: NIP-45 COUNT with {kinds:[3], "#p":[pubkey]} returns an aggregate without streaming events, but relay support is inconsistent — treat it as an optimization for a headline number, not the source of truth.
• Mutual state: you already have the user's own follow list (fetch_following_pubkeys); intersect it with the follower set to mark "follows you / you follow" — no extra queries.
• Spam/bots: raw follower sets for popular accounts are noisy. GNS provenance (which relays served the follow, graph distance) is a better signal to rank/filter on than a flat count.

One footgun if the backend opens relay sockets itself

(Aside — this bit us in GNS this week, so flagging it.) If nostr.rs opens relay WebSockets via tokio-tungstenite + rustls 0.23, the first wss:// handshake panics unless a crypto provider is installed once at startup:

rustls::crypto::ring::default_provider().install_default().ok();

The panic is silent per-request (empty reply, no error in the response), so it's easy to misdiagnose as a relay/timeout issue. Doesn't apply if you go through nostr-sdk (it manages TLS), but worth knowing if the followers fallback opens sockets directly.