block / block/buzz

[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

Open
#5,433 0 comments 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.