Mobile: let buzz://message links name their community (optional relay= parameter) #8292

Motivation

People who belong to several communities can't open a buzz://message link from outside the app unless Buzz happens to be on the right community already. I'm in four, so most links fail.

Today a message link carries only channel, id and thread. parseMessageDeepLink (mobile/lib/shared/deeplink/deep_link.dart) rejects any other query parameter. DeepLinkDispatcher then looks the channel up in the active community, and otherwise shows "Channel not found in this workspace". The communityId on MessageDeepLink can't help, because community ids are device local and only the app's own push path sets one.

Where I hit it: my relays are self hosted, so they can't use the NIP-PL push gateway. I bridge the relay's operator listener mention deliveries to ntfy on my phone. Each notification's tap target is a buzz://message link. When Buzz is on the mention's community, the tap opens the message inside its thread, and it works very well. When it isn't, the tap dead ends.

Proposed solution

Accept an optional relay parameter on message links, for example:

buzz://message?relay=wss://buzz.example.com&channel=<uuid>&id=<event id>&thread=<root id>

When relay is present, find the joined community whose relay URL matches it, normalized the same way invite links are. Switch to that community, then open the message as today. If no joined community matches, show the existing "community is no longer available" style message. Links without relay behave exactly as now.

Most of the pieces already exist:

• parseInviteDeepLink already validates and normalizes a relay parameter (ws or wss, no credentials or fragment).
• InviteJoinNotifier.prepare already finds an existing community by relay URL and calls switchCommunity.
• PendingDeepLinkNotifier.prepareCommunity already switches communities and parks a message link until the community subtree remounts.

So the change is mostly: allow relay in parseMessageDeepLink, then in prepareCommunity resolve it to a community id when communityId is null. Desktop's deep-link.ts would need the same optional parameter so links stay round trippable across clients.

Alternatives considered

• Carrying the community id in the link doesn't work, because ids are device local.
• My current workaround: each notification also carries a buzz://join?relay=<relay>&code=switch action button. For a community the app already has, prepare() switches without redeeming the code. It works, but it takes two taps and depends on join link behaviour that isn't meant for this.
• Native Android push would also carry the community: feat(push): add a UnifiedPush transport profile to the NIP-PL push gateway (Google-free Android, self-host friendly) #7482 (UnifiedPush transport) and feat(mobile/android): end-to-end push notifications — FCM registration, POST_NOTIFICATIONS, and banner display #6092 (FCM). Those cover notifications from the app's own push path, but not links opened from anywhere else.

Additional context

Duplicate search: none found. Closest related are #7482, #6092 and #2570.

Note: this issue was drafted by Claude, an AI assistant, working on behalf of Brian Bouterse and in collaboration with him. It is AI generated and human reviewed.