[Bug] Community name remains device-local instead of syncing from relay

[TheAngryPit]

Problem

Buzz Desktop treats a community's human-readable name as device-local
configuration rather than community state.

When the same owner identity connects to the same self-hosted community from a
second Desktop installation, the second device does not receive the name chosen
on the first device. It derives a new label from the relay hostname instead. For
an observed private IPv4 relay whose first octet was 100, the derived name was
100.

Every installation must therefore rename the same community independently. The
result is especially confusing because the relay already provides other
per-community presentation state, including the workspace icon, and Buzz's
architecture describes the relay as the source of truth.

The local label is not authorization state, and this behavior does not change
owner/admin roles. The problem is that users cannot establish one canonical
community name that follows the community across supported clients.

Evidence And Reproduction

Environment

• Observed Desktop release: v0.4.25
• Release commit:
  e8105d1446834f522c75d628bf1d9e77c9c077a4
• Observed OS: macOS on two separate installations
• Relay: self-hosted Buzz relay reached through a private IP WebSocket URL
• Identity: the same imported Nostr owner identity on both installations
• Current main rechecked at:
  9cc9652c7dec9145b0bf0ce2c4b46c8191d215f8

Minimal reproduction

1. Connect Desktop installation A to a self-hosted Buzz community.
2. Rename the locally displayed community to TheHive.
3. On Desktop installation B, import the same Nostr identity.
4. Connect installation B to the same relay URL.
5. Observe that channels, messages, profile, and membership load from the
   relay.
6. Open the community editor on installation B.
7. Observe that the community name was not received from the relay. For a relay
   addressed by a private IPv4 host beginning with 100, Desktop derives
   100.
8. Rename installation B to TheHive.
9. Observe that the rename affects only installation B and does not establish
   canonical community state for future installations.

Current result

• The same community can have unrelated names on different Desktop
  installations.
• Each installation persists its own name in buzz-communities local storage.
• deriveCommunityName() splits the relay hostname and uses its first segment,
  producing 100 for the example IP.
• The relay's community record has stable id and host fields plus
  per-community icon, but no canonical name.
• NIP-11 exposes a name field, but Buzz currently serves the static value
  Buzz Relay rather than the requesting community's name.
• Desktop fetches and caches the relay-provided community icon but has no
  equivalent community-name read path.

Evidence classification

Observed

• Two macOS Desktop installations using the same owner identity and relay
  displayed different locally configured community names.
• The second installation loaded relay-backed channels and history but derived
  100 as its community name.
• Both installations required a manual rename.

Code-proven

• desktop/src/features/communities/communityStorage.ts persists community
  records in local storage and derives an unnamed community from the first
  hostname segment.
• crates/buzz-db/src/lib.rs::CommunityRecord models only the stable community
  id and host; the current community presentation column is icon.
• crates/buzz-relay/src/nip11.rs::RelayInfo::build emits the static name
  Buzz Relay while accepting a host-scoped community icon.
• desktop/src-tauri/src/commands/workspace.rs::fetch_workspace_icon reads only
  the NIP-11 icon.
• The same behavior remains on current main at the SHA above.

Documented

• NIP-11 defines a human-readable relay name.
• PR feat(desktop): add drag-to-reorder for community rail #2549 explicitly describes Desktop community records as device-scoped and
  persisted in local storage.
• Issue [Feature] Reorder and color-code communities in sidebar #2667 proposes syncing community ordering or falling back to local
  storage, but does not define or synchronize a canonical community name.

Not yet runtime-proven in this report

• No raw relay database row or NIP-11 response from the observed private
  deployment is attached. The absence of a canonical name field and the static
  NIP-11 value are code-proven at the release and current-main commits.

Duplicate search

Open and closed issues and pull requests were searched for:

• canonical community name
• "community name" sync devices
• NIP-11 name desktop
• "device-scoped" community name
• community name sync
• rename community

No dedicated issue for canonical community-name synchronization was found as of
2026-07-25.

Expected Behavior

Buzz should have one owner/admin-controlled canonical name for each community.

• The canonical name is relay-backed community state.
• A fresh supported client displays that name after connecting.
• Renaming the community through a supported owner/admin path becomes visible
  on other clients after refresh or reconnect.
• The name is scoped to the host-derived community and cannot leak across
  communities in a multi-tenant deployment.
• Unauthorized members cannot change it.
• Community id, host, membership, channels, messages, icon, and other state are
  preserved during rename.
• If local aliases remain supported, they are explicitly labeled as local and
  never silently replace or mutate the canonical name.
• A relay with no canonical name has a documented compatibility fallback; an IP
  address is not presented as an intentional community name without
  explanation.

The exact wire representation is a design decision. The visible invariant is
that users name the community once, not once per device.

Scope

• Relay-backed, per-community canonical presentation metadata for the name.
• Owner/admin authorization for setting or changing the canonical name.
• A tenant-safe client read/discovery path.
• Buzz Desktop onboarding, community storage, refresh, editing, and fallback
  behavior.
• Migration and compatibility behavior for existing communities and existing
  Desktop local names.
• Focused relay, Desktop, and two-installation validation.

Owner boundary: the block/buzz community-presentation contract across its
relay and Desktop implementations.

Non-Goals

• Making a community name globally unique.
• Changing the community's stable id, hostname, relay URL, owner identity, or
  membership roles.
• Synchronizing user-specific community ordering, colors, notification
  preferences, repository directories, API credentials, or local archives.
• Public DNS, TLS, NIP-05, or hosted-community provisioning.
• Broad community-settings redesign.
• Reworking the already relay-backed workspace-icon contract.
• Implementing cross-relay account synchronization.
• Selecting a new event kind or database schema before the contract is
  accepted.

Acceptance Criteria

• An owner or admin can set a canonical community name through a supported
  path.
• A regular member cannot change the canonical name.
• Two clean Desktop installations connected to the same community display
  the same canonical name without manually duplicating it.
• A rename on installation A becomes visible on installation B after the
  documented refresh/reconnect boundary.
• The relay read path returns only the name of the host-derived community.
• Two communities served by shared infrastructure can use different names
  without leakage or cache-key collision.
• A failed or unauthorized rename preserves the previous canonical name
  and all unrelated community state.
• Retrying an accepted rename is safe and idempotent.
• Existing communities without canonical names remain accessible and use a
  documented fallback.
• Existing local Desktop names are migrated or reconciled without silently
  overwriting an intentional local alias.
• Offline or temporarily unreachable clients may show cached presentation
  state but clearly reconcile with relay truth when connectivity returns.
• Community icon, membership, channel, message, profile, and relay
  connection behavior remain compatible.

Validation Plan

• Add focused unit tests for canonical name validation, authorization,
  persistence, and idempotent rename.
• Add multi-community tests proving host-scoped reads and writes cannot cross
  tenant boundaries.
• Add migration tests for communities created before the canonical-name
  contract.
• Add Desktop tests for first connect, cached display, refresh/reconnect,
  rename, unauthorized failure, offline fallback, and any explicit local-alias
  behavior.
• Add a supported-path integration test using two clean Desktop storage
  profiles against one relay.
• Prove the exact relay response/state before and after rename and the
  operator-visible value on both clients.
• Run the repository-required focused suites, relay integration tests, Desktop
  E2E tests, and just ci.
• Record exact-head evidence and migration/recovery proof in the implementation
  PR. Auto-review belongs to that PR and is not pre-claimed by this issue.

Security And Compatibility

• The canonical name must use existing owner/admin authority and must not create
  a second administration plane.
• No private keys, API tokens, repository paths, private channel content, or
  unredacted deployment data are required.
• If the name is published through unauthenticated NIP-11, it becomes
  intentionally public to anyone who can reach that community host. That
  exposure must be documented and accepted as part of the contract.
• Multi-tenant host binding and cache scoping must prevent name enumeration or
  leakage across communities.
• Existing community ids, hosts, memberships, events, icons, and Desktop
  connections must remain valid.
• If persistence changes, the migration must have a safe fallback for existing
  rows and a tested rollback/recovery story.
• No additional network exposure, relay publication target, or credential scope
  is required.

References

• NIP-11 — Relay Information Document:
  https://github.com/nostr-protocol/nips/blob/master/11.md
• Current Desktop community local storage and name derivation:
  https://github.com/block/buzz/blob/9cc9652c7dec9145b0bf0ce2c4b46c8191d215f8/desktop/src/features/communities/communityStorage.ts
• Current relay community record:
  https://github.com/block/buzz/blob/9cc9652c7dec9145b0bf0ce2c4b46c8191d215f8/crates/buzz-db/src/lib.rs
• Current NIP-11 builder:
  https://github.com/block/buzz/blob/9cc9652c7dec9145b0bf0ce2c4b46c8191d215f8/crates/buzz-relay/src/nip11.rs
• Current Desktop NIP-11 icon reader:
  https://github.com/block/buzz/blob/9cc9652c7dec9145b0bf0ce2c4b46c8191d215f8/desktop/src-tauri/src/commands/workspace.rs
• PR feat(desktop): add drag-to-reorder for community rail #2549 — local community ordering and device-scoped storage:
  feat(desktop): add drag-to-reorder for community rail #2549
• Issue [Feature] Reorder and color-code communities in sidebar #2667 — adjacent community ordering/color synchronization proposal:
  [Feature] Reorder and color-code communities in sidebar #2667