[Bug] Desktop profile conflates Nostr name with display name

[TheAngryPit]

Problem

Buzz Desktop presents the first-community profile field as Your username
but persists that value as Nostr display_name. The same value is later shown
under Settings → Profile → Display name.

The Desktop profile model and Tauri command can read and preserve an existing
Nostr name, but neither onboarding nor Profile settings lets a user create or
edit it. A new user therefore cannot represent the standard two-field profile:

{
  "name": "alice",
  "display_name": "Alice Example"
}

This affects new and existing Desktop users who want a short Nostr name and a
separate richer display name. It also teaches the user that they are choosing a
username when the emitted field has different semantics.

The canonical identity remains the public key. This issue is about profile
metadata and UI semantics, not account identity or authorization.

Evidence And Reproduction

Environment

• Observed release: Buzz Desktop v0.4.25
• Release commit:
  e8105d1446834f522c75d628bf1d9e77c9c077a4
• Observed OS: macOS
• Current main rechecked at:
  b8510ede1b52ebe87ed3cf18cf0b2590a86b2245
• Supported path: first-community onboarding followed by
  Settings → Profile

Minimal reproduction

1. Start first-community onboarding with an identity that has no profile event
   in that community.
2. At Build your profile, enter alice into the field labeled
   Your username.
3. Complete onboarding.
4. Open Settings → Profile.
5. Observe that the same value is labeled Display name, with no separate
   name or username control.
6. Inspect the current source or capture the signed kind-0 event. The onboarding
   payload supplies displayName: "alice"; it does not supply name.

Current result

• Onboarding labels the input as a username.
• The input is stored as display_name.
• Settings correctly labels the stored value as Display name.
• A pre-existing kind-0 name is preserved by Desktop edits but cannot be
  created or changed through the supported Desktop UI.

Evidence classification

Observed

• On Buzz Desktop v0.4.25 for macOS, first-community onboarding requested a
  username.
• After onboarding, Profile settings displayed the resulting value as
  Display name and exposed no separate username/name field.

Code-proven

• desktop/src/features/onboarding/ui/CommunityOnboardingFlow.tsx labels the
  input Your username, uses username-oriented HTML attributes, and calls
  updateProfile({ displayName: ... }).
• desktop/src/features/settings/ui/ProfileSettingsCard.tsx edits only
  displayName, avatar, and about; it labels the field Display name.
• desktop/src/shared/api/types.ts::UpdateProfileInput has no name member.
• desktop/src-tauri/src/commands/profile.rs::update_profile accepts no name
  argument. It only carries forward name when one already exists in the
  current kind-0 content.
• The same behavior remains present on current main at the SHA above.

Documented

• NIP-01 defines name in kind-0 user metadata.
• NIP-24 defines display_name as a richer alternative to name, states that
  name should still be set, and deprecates the literal username key in favor
  of name.
• Review on PR Polish community profile onboarding UI #2088 rejected presenting the existing display-name field as a
  username unless a real username model was introduced separately.

Not yet runtime-proven in this report

• A redacted raw kind-0 capture from the observed production community has not
  been attached. The payload-to-field mismatch is code-proven on both the
  release commit and current main.

Expected Behavior

Buzz Desktop should represent Nostr profile metadata without conflating the two
fields:

• name is the short Nostr name/handle.
• display_name is the richer human-facing name.
• The supported Desktop profile flow allows a user to set and later edit both.
• UI labels describe the field that is actually signed and published.
• The public key remains the canonical identity; neither field is presented as
  globally unique.
• Editing either field preserves the other field and all unrelated kind-0
  metadata.

The exact layout is a product decision. The required outcome is semantic and
wire-level agreement between onboarding, settings, the update contract, and the
signed kind-0 event.

Scope

• Buzz Desktop first-community profile onboarding.
• Buzz Desktop Profile settings.
• Shared Desktop profile/update types and Tauri command wiring needed to carry
  name.
• Signed kind-0 profile construction for the current user's supported Desktop
  path.
• Focused unit/integration/E2E coverage for the two-field round trip.

Owner boundary: block/buzz Desktop and its local Tauri profile command.

Non-Goals

• NIP-05 domain provisioning or verification UI.
• Making name globally or community-wide unique.
• Changing public-key identity, community owner/admin roles, authentication, or
  signing.
• Publishing profiles to additional public relays.
• Adding relay or database migrations.
• Modeling every optional kind-0 field.
• Reimplementing the general metadata-preservation work tracked by kind:0 profile republish drops every field outside a 5-key allowlist — silently deletes bot: true, nip05 and website #2534 and
  its open PRs.
• Changing managed-agent profile semantics.
• Broad profile-page redesign, unrelated onboarding polish, or cleanup.

Acceptance Criteria

• A user can set both name and display_name through supported Buzz
  Desktop profile flows.
• A profile saved as name = "alice" and
  display_name = "Alice Example" emits a signed kind-0 containing those
  exact fields.
• Reopening Profile settings displays both values in controls with
  semantically correct labels.
• Editing only name preserves display_name, picture, about, NIP-05, and
  unmodeled kind-0 fields.
• Editing only display_name preserves name and the same unrelated
  metadata.
• An existing profile containing only display_name continues to load and
  can be upgraded without silent data loss.
• An existing profile containing both fields round-trips without one field
  being promoted into or replacing the other.
• Repeated saves with unchanged values are idempotent at the profile-content
  level and do not delete unrelated metadata.
• Validation errors fail without publishing a partial replacement event or
  showing unsaved values as canonical.
• The UI does not imply that name is globally unique or authoritative
  over the public key.
• Existing avatar, about, key import, community onboarding, and profile
  navigation behavior remains compatible.

Validation Plan

• Add focused tests for Desktop profile update serialization with independent
  name and display_name inputs.
• Add a regression test proving that updating either field preserves the other
  and unmodeled kind-0 metadata.
• Add Desktop E2E coverage for:
  • first-community onboarding;
  • Profile settings edit/readback;
  • exact raw kind-0 content after each supported path;
  • returning profiles with only display_name;
  • returning profiles with both fields.
• Run the repository-required Desktop checks and focused E2E tests.
• Run just ci before proposing implementation for merge.
• Record exact-head test evidence in the implementation PR. Auto-review belongs
  to that PR and is not pre-claimed by this issue.

Security And Compatibility

• No private key export or new signer is required; the existing local signer
  remains authoritative.
• No auth scopes, permissions, community roles, secrets, network exposure, or
  relay admission rules should change.
• No database migration should be necessary because the source of truth is the
  signed kind-0 event.
• Existing profiles must remain readable without forced migration.
• The implementation must coordinate with the resolution of kind:0 profile republish drops every field outside a 5-key allowlist — silently deletes bot: true, nip05 and website #2534 so a new
  field editor does not reintroduce destructive whole-profile rewrites.
• No personal names, public keys, private community content, credentials, or
  unredacted production event payloads are required in tests or issue evidence.

References

• NIP-01 — Basic protocol flow and kind-0 metadata:
  https://github.com/nostr-protocol/nips/blob/master/01.md
• NIP-24 — Extra metadata fields:
  https://github.com/nostr-protocol/nips/blob/master/24.md
• Buzz issue kind:0 profile republish drops every field outside a 5-key allowlist — silently deletes bot: true, nip05 and website #2534 — destructive kind-0 rewrite and unexposed name:
  kind:0 profile republish drops every field outside a 5-key allowlist — silently deletes bot: true, nip05 and website #2534
• Buzz PR fix(profile): preserve unmodeled metadata on update #2545 — metadata-preservation implementation:
  fix(profile): preserve unmodeled metadata on update #2545
• Buzz PR fix(profile): read-merge-write kind:0 so republish stops deleting unmodeled fields #2606 — competing metadata-preservation implementation; explicitly
  leaves exposing --name out of scope:
  fix(profile): read-merge-write kind:0 so republish stops deleting unmodeled fields #2606
• Buzz PR Polish community profile onboarding UI #2088 review — distinguishes display name from a real username model:
  Polish community profile onboarding UI #2088 (review)
• Buzz PR Polish onboarding avatar capture #2118 — later onboarding change that reintroduced username copy while
  retaining the display-name persistence path:
  Polish onboarding avatar capture #2118