Desktop v0.5.2 shows relay owner as non-member despite active channel_members row
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
## Summary
Buzz Desktop v0.5.2 connects successfully to a self-hosted closed relay, but after relaunch it displays the relay owner as a non-member of channels that the owner created.
The channel is discoverable through search and its messages persist, but Desktop shows zero people and “Join to participate.” Clicking Join has no visible effect.
The relay logs show that it receives the join request and skips it because the identity is already a member.
## Environment
- Buzz Desktop: v0.5.2, Apple silicon DMG
- Desktop commit associated with release: `3e48f1b`
- Client machine: Apple M5 Pro MacBook Pro, macOS 26.5.2
- Relay image: `ghcr.io/block/buzz:main`
- Relay platform: Apple M4 Mac mini, macOS 26.6, Docker Desktop
- Deployment: official `deploy/compose` production bundle
- Network: private Tailscale address using `ws://`
- Relay settings:
- `BUZZ_REQUIRE_AUTH_TOKEN=true`
- `BUZZ_REQUIRE_RELAY_MEMBERSHIP=true`
- `BUZZ_ALLOW_NIP_OA_AUTH=true`
- `BUZZ_AUTO_MIGRATE=true`
## Steps to reproduce
1. Deploy the official production Compose stack using `ghcr.io/block/buzz:main`.
2. Generate the owner identity using `buzz-admin generate-key`.
3. Configure that public key as `RELAY_OWNER_PUBKEY`.
4. Import the corresponding private key into Desktop v0.5.2.
5. Join the self-hosted relay through the “Join a community” onboarding path.
6. Complete onboarding and create/use the starter `#general` channel.
7. Send a message successfully.
8. Quit and reopen Desktop.
9. Search for `#general` because it is no longer present in the channel sidebar.
10. Open the channel and click “Join to participate.”
## Actual result
- The channel and its messages remain stored and searchable.
- Desktop displays zero people.
- Desktop displays “Join to participate.”
- Clicking Join does not update the UI or restore the channel to the sidebar.
- Each click reaches the relay, which logs:
```text
kind:9021 join — already a member, skipping
```
## Backend verification
`buzz-admin list-members` confirms the identity is the relay owner.
A direct read-only query of `channel_members` shows active owner rows for all three starter channels:
- `role = owner`
- `removed_at IS NULL`
- `hidden_at IS NULL`
`buzz-admin reconcile-channels` reports:
```text
Reconciled 0 channels (3 already had events, 3 total).
```
The Welcome channel also contains the three starter bots as active members.
Therefore, relay admission, channel membership, discovery events, message persistence, and database state appear correct. Desktop’s membership state disagrees with the authoritative backend.
## Version-alignment test
I attempted to use the server image matching Desktop v0.5.2:
```text
ghcr.io/block/buzz:sha-3e48f1b
```
The image exists, but it cannot start against this database because `main` already applied migration 26:
```text
migration 26 was previously applied but is missing in the resolved migrations
```
The relay was returned to `ghcr.io/block/buzz:main` and is healthy. No migration records or database rows were edited.
## Expected result
Desktop should recognize the existing active owner membership, display the member count, allow participation, and retain joined channels in the sidebar after relaunch.
If a redundant kind-9021 join is sent, the relay’s “already a member” success/no-op response should reconcile Desktop to the joined state rather than leaving it as a non-member.
## Related issues
- #2815 — `buzz-admin generate-key` emits hex while Desktop requires `nsec1`
- #2816 — self-host onboarding path is hidden behind “Join a community”
Contributor guide
Assessment
This issue has not been assessed yet.