Problem
Buzz Desktop currently models and displays only part of a kind:0 profile. The standard NIP-24 website and banner fields are not exposed in Profile settings or rendered in the member profile panel.
That leaves profiles less useful for community members who want to share a primary website and visually distinguish their identity without introducing a Buzz-specific metadata format.
Proposed scope
Add first-class Desktop support for the standard NIP-24 fields:
- parse
website and banner from kind:0 metadata
- allow users to edit their website in Profile settings
- allow users to upload, replace, and remove a banner using the existing media-upload path
- render the banner and website in the existing member profile panel
- accept only valid HTTP/HTTPS URLs, reject embedded credentials, and fall back cleanly when a banner cannot load
- preserve existing avatar, profile-cache, deferred-avatar, and profile animation behavior
This would remain within the existing kind:0 profile, Tauri profile command, media upload, and profile UI architecture. It would not add a dependency, endpoint, event kind, or parallel profile model.
Relationship to existing profile-preservation work
This feature should integrate with the resolution of #2534 rather than silently rebuilding a new fixed allowlist.
Two open PRs currently address preservation of unmodeled kind:0 fields:
The implementation should be rebased onto whichever preservation approach maintainers select so profile edits retain bot, lud16, future NIP fields, and other unmodeled metadata.
Explicitly out of scope
- custom social-link arrays or provider-specific metadata
- banner positioning/cropping metadata
- joined dates or community-role changes
- CLI profile flags
- mobile profile editing
- unrelated profile refactors
Those can be discussed separately after the standard fields are supported.
Acceptance criteria
- existing NIP-24 website/banner metadata is parsed and displayed
- website edits and banner upload/removal round-trip through kind:0
- unsafe website schemes are rejected
- unavailable banner images do not break the profile panel
- existing profile fields and unmodeled kind:0 metadata remain intact
- existing profile tests remain green, with focused Rust, frontend, and Desktop E2E coverage added
Is this focused Desktop scope acceptable once the #2534 preservation work is resolved?
Problem
Buzz Desktop currently models and displays only part of a kind:0 profile. The standard NIP-24
websiteandbannerfields are not exposed in Profile settings or rendered in the member profile panel.That leaves profiles less useful for community members who want to share a primary website and visually distinguish their identity without introducing a Buzz-specific metadata format.
Proposed scope
Add first-class Desktop support for the standard NIP-24 fields:
websiteandbannerfrom kind:0 metadataThis would remain within the existing kind:0 profile, Tauri profile command, media upload, and profile UI architecture. It would not add a dependency, endpoint, event kind, or parallel profile model.
Relationship to existing profile-preservation work
This feature should integrate with the resolution of #2534 rather than silently rebuilding a new fixed allowlist.
Two open PRs currently address preservation of unmodeled kind:0 fields:
The implementation should be rebased onto whichever preservation approach maintainers select so profile edits retain
bot,lud16, future NIP fields, and other unmodeled metadata.Explicitly out of scope
Those can be discussed separately after the standard fields are supported.
Acceptance criteria
Is this focused Desktop scope acceptable once the #2534 preservation work is resolved?