Handle identity/account events from Jetstream firehose

[will-corrigan]

Context

Drainpipe already receives #identity and #account events from the Jetstream firehose (the Rust Jetstream library deserializes them), but currently drops them on the floor — only Commit events are forwarded to the app.

Meanwhile, the app resolves DID documents and handles live during server-side rendering for every post author, commenter, etc. This means page loads depend on external HTTP calls to plc.directory (for did:plc) or user domains (for did:web), cached with 1-hour revalidation. On cold cache or cache expiry, a slow or unreachable identity source can block the entire page render for up to 5 seconds.

Proposal

Decouple identity resolution from page rendering by caching handles in our own database, updated reactively via the firehose:

1. Store resolved handles in the database alongside DIDs — rendering reads from the DB instead of doing live DID resolution
2. Forward identity/account events from drainpipe to the app (new endpoint or extend receive_hook)
3. Update cached handles reactively when identity events arrive — re-resolve the DID document and update the stored handle
4. Periodic background re-resolution for did:web only as a safety net, since identity events are best-effort (changes can happen without events firing). This only applies to did:web users — did:plc changes reliably emit events via plc.directory. The did:web user count is tiny (~50 in the whole ecosystem), so this is negligible work.

Page renders become purely local DB reads. Identity resolution becomes a background process driven by firehose events.

Implementation notes

• The Rust Jetstream library already has full type definitions for IdentityEvent and AccountEvent — deserialization infrastructure is ready
• Jetstream sends identity/account events to all subscribers regardless of wantedCollections filters, so drainpipe is already receiving them
• Identity events are best-effort signals — the spec recommends re-resolving the DID document independently to verify
• #account events include a status field (deleted, suspended, deactivated, takendown) which could be used to mark accounts inactive

References

• Support did:web user authentication and identity #341 — did:web user support (this is a prerequisite for safe did:web support)
• AT Protocol sync spec — identity events
• Bluesky resolving identities guide

[tom-sherman]

Sounds good, we can probably cache the whole did doc too with this same technique.

[tom-sherman]

We need to take into account a handle becoming invalid without an identity event, this applies to all dids (including plc). Eg. If someone domain expires or they remove the DNS records.

I wonder how bluesky handles this?

[will-corrigan]

How Bluesky handles stale handles (without identity events)

Bluesky's AppView does lazy re-verification — no background sweeper or cron exists:

• Every firehose event for a DID calls indexHandle(), which only re-verifies if the handle is stale:
  • Valid handles: re-verified after 24 hours
  • Already-invalid handles: re-verified after 1 hour
• Re-verification is bi-directional: resolve DID → get declared handle from alsoKnownAs → resolve handle back to DID → check they match. If not → handle = null (rendered as handle.invalid).
• The relay cache layer has a separate TTL: 24 hours for valid, 5 minutes for invalid handles.

The gap: If a user's domain expires and they go inactive (no posts, no interactions), nothing triggers re-verification. Their stale handle persists indefinitely. There is no proactive "handle watcher."

For our approach: Since we're caching handles in the DB (#343), we could do better than Bluesky here — the background cron that re-resolves did:web pins could also re-verify handles for all users who haven't had a firehose event recently. This covers the "inactive user with expired domain" case that Bluesky misses.

[tom-sherman]

Prior art in this space: https://tangled.org/microcosm.blue/microcosm-rs/tree/main/slingshot