[bug] NIP-43 membership reconciliation runs once on first restart after events deleted, then silently fails on subsequent restarts — channel creation 403s despite valid membership
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
Describe the bug
NIP-43 membership reconciliation runs exactly once (on first restart after kind:13534 events are deleted), publishing the membership snapshot with member_count:5 and count:1. On all subsequent restarts, reconciliation reports count:0 and channel creation fails with 403 relay_membership_required — despite membership rows existing in relay_members table and kind:13534 events being present with all members.
Steps to reproduce
1. Deploy fresh relay with BUZZ_DOMAIN=naples.communities.buzz.xyz, RELAY_URL=wss://naples.communities.buzz.xyz
2. Add members via buzz-admin add-member (5 members: owner + 4 users)
3. Verify DB state:
SELECT * FROM relay_members; -- 5 rows
SELECT * FROM events WHERE kind = 13534; -- 1 row with all 5 members
4. Restart relay → logs show: "NIP-43 membership list published", "member_count":5 and "NIP-43 membership snapshots reconciled on startup", "count":1
6. Attempt channel creation: buzz channels create --name news --type stream --visibility open with any member key → 403 relay_membership_required
6. Restart relay again → logs show: "NIP-43 membership snapshots reconciled on startup", "count":0
7. Repeat channel creation → still 403 relay_membership_required
Expected behavior
Membership reconciliation should re-evaluate on every startup (or provide reconcile-membership admin command), and channel creation should succeed for valid relay members. Membership auth checks should read from relay_members table as fallback when events are stale.
Version and platform
- Buzz version: ghcr.io/block/buzz:latest (sha256:4e31b7c7abb7d00b6f513dc559e58d2b980416f1dc400aa01bcf762cf2989cfc, ~12h old)
- OS: Linux (Docker)
- Community: naples.communities.buzz.xyz (community ID aa2eff26-4bad-467d-92f1-14750be4d449)
- RELAY_URL: wss://naples.communities.buzz.xyz
- Reverse proxy: Caddy → 127.0.0.1:3000 (WebSocket capable)
Logs / additional context
Key evidence:
relay_members table
• Result: 5 rows, correct community ID
events kind:13534
• Result: 1 row, tags contain all 5 members
curl -H "Host: naples..." http://127.0.0.1:3000/_readiness
• Result: 200 {"status":"ready"} ✅
buzz channels create via wss://naples...
• Result: 403 relay_membership_required ❌
buzz channels create via https://naples...
• Result: 403 relay_membership_required ❌
First restart after event deletion
• Result: count:1, member_count:5 ✅
Subsequent restarts
• Result: count:0 ❌
Workarounds tested (all failed):
- ❌ Using https:// instead of wss://
- ❌ Using http://127.0.0.1:3000 with Host header (→ 404 no community configured for this host)
- ❌ Adding members after reconciliation already ran
- ❌ Multiple relay restarts
Related issues: #1761 (membership snapshot publishing fix), #3888 (403 relay_membership_required for kind:0), #4147 (URL-string mismatch causes separate community identities)
Diagnostic artifacts available: Full relay logs showing count:1 → count:0 transition, DB dumps of relay_members and events (kind:13534), exact CLI commands and 403/404 responses, Caddy config and relay env vars confirming URL strings match.
Priority: High — blocks all channel creation and agent onboarding for new communities.
---
Signed-off-by: Craig Christianson
Contributor guide
Assessment
This issue has not been assessed yet.