[johnmatthewtennant]

Fixes #2449.

Problem

Joining a self-hosted community (Helm chart, buzz:0.2.1) by address or invite link says "No community is set up at this address", even though the relay has a community and has just minted the invite.

The pre-join lookup (#1815) treats a Buzz NIP-11 document with none of read_state_snapshot, buzz_v1 or icon as an unmapped host. The released relay, relay-v0.2.1, never serves the first two, and serves icon only after an admin sets one. So every community on it without an icon is refused.

A current relay signals an unmapped host differently: NIP-11 answers 404 with relay: no community is configured for this host. The app shows that as "This address isn't a Buzz community".

Solution

findCommunity classifies no-community from the relay's unmapped-host 404, and accepts any other Buzz NIP-11 document. A relay that answers 200 for a host it doesn't map now gets past the lookup and fails at the invite claim, since its NIP-11 can't tell the two apart. That covers relay-v0.2.1 and relay main builds from 6a86531ac (2026-09-21) until block/buzz#8988 (64d12e297, 2026-11-04). Staging already answers an unmapped host with the 404.

Screenshots

Invite link to a relay-v0.2.1 community finds it

Joined through the invite

Validation

• find-community.test.ts: a relay-v0.2.1 NIP-11 document (no read_state_snapshot, buzz_v1 or icon) is found, and the relay's unmapped-host 404 is no-community. FindCommunity.test.tsx shows "No community is set up at this address" for that 404. All three fail before the change and pass after.
• Native, at ecea41e42, against relay-v0.2.1 built from source behind TLS (no seed-local-community.sh): an invite minted through POST /api/invites and pasted under Other options reaches "Connect to your community" for localhost:3444. Use an existing key, Join and a display name land in the community's Messages view, and the relay records the new member.

[kalvinnchau]

🤖 One compatibility documentation and rollout concern; no implementation change requested.

[wpfleger96]

🤖 Reviewed at ecea41e4274c0082f4c94540012e53896c9f5d38. No CRITICAL or IMPORTANT source findings; one optional error-copy follow-up inline. The change fits #2449: accept the released relay's valid NIP-11 rather than infer tenant binding from optional fields, and recognize the current relay's exact unmapped-host 404. Downstream relay host binding and admission enforcement remain intact.

Review included independent security/reliability, design, functionality/testing, and external-contract lanes. Hosted CI is green. The mutation check reversed only production while retaining the PR tests: the three affected assertions failed and passed again when restored. The local full-suite baseline itself was not clean under heavy host load, so that is regression-sensitivity evidence, not a clean local-suite claim.

Verification limitation — Comment, not approval: independent live HTTP/parser checks covered a mapped modern relay, but not the released relay's native invite/join or the current relay's unmapped-host 404. Cloudflare intercepted the negative-host probe; no local relay was available and Docker required organization sign-in. The PR's exact-head native TLS join/member-readback evidence remains author-reported, not independently reproduced. Completing that independent check needs an available isolated relay or an unmapped hostname already routed to one. Windows acceptance for the originating issue is also unverified. No implementation blocker is inferred from those limits.

[wpfleger96]

🤖 Approved at ecea41e4274c0082f4c94540012e53896c9f5d38 following Will’s explicit direction to approve with no blockers. No CRITICAL or IMPORTANT findings. The optional legacy error-copy comment remains non-blocking. Source review, green hosted CI and the mutation check support this fix. The independent native/negative-host live-verification and Windows acceptance limitations recorded in my preceding review remain unchanged; this approval does not claim those checks were completed.