[Bug] iOS invite join opens the community but remains stuck on “Connecting…”

[Rodribm10]

Summary

Opening a valid hosted-community invite on iPhone successfully hands off to the Buzz mobile app and selects the correct community, but the app then remains indefinitely on “Connecting…” with an empty Home screen.

This blocks a mobile-first rollout for employees who do not have a desktop computer.

Expected behavior

After the invite is opened and joined, the mobile app should connect to the community relay and render the available channels.

Actual behavior

The mobile app opens the correct hosted community, shows the correct hostname, and then stays on “Connecting…” forever. No channels or content load.

Reproduction

1. Create a hosted Buzz community at grupoinnova.communities.buzz.xyz.
2. Create an invite link from Community access.
3. On an iPhone with the Buzz mobile app installed, open that invite link.
4. The app opens and displays grupoinnova.communities.buzz.xyz.
5. It remains indefinitely on “Connecting…” with an empty Home screen.

Notes

• This is a hosted community, not a self-hosted relay.
• The deep-link handoff itself appears to work: the mobile app opens the intended community.
• Manual membership via npub and desktop-to-mobile pairing were tested separately. Pairing works for the same person's desktop/mobile identity, but it is not a viable onboarding path for employees without a computer because it copies the desktop identity.
• The failing path is specifically a new mobile user opening a community invite.

Impact

A company cannot invite mobile-only staff reliably: the person appears to enter the app/community but cannot load anything. This makes the invite flow unsuitable for normal employee onboarding.

A screenshot of the device state is available if maintainers need it.

[brennengilai]

Additional data point: the poisoned relay URL survives app deletion. I deleted the iOS app and reinstalled (no restore-from-backup) — the fresh install goes straight back into the same "Connecting…" loop before any invite or pairing step, so the stored relay config appears to persist in the iOS Keychain across reinstalls. There's no user-accessible way to clear it. This makes the repair/migration in #2726 load-bearing for existing installs — a parser fix alone won't heal devices already in this state. Happy to test a build.

[whotookmylogin]

We hit what looks like the same failure today on a self-hosted relay (ghcr.io/block/buzz:main, pulled 2026-07-28; iOS App Store app), and have server-side logs that narrow it down.

Symptom (identical): iOS user opens an invite, the app joins the community (the invite claim succeeds — the new identity is added to the relay roster), then the app sits on an empty/blank screen forever.

What the relay logs show: the client is in a tight reconnect loop, and every attempt dies at NIP-42 auth:

WARN NIP-42 auth failed  error="relay url mismatch"  (repeats every few seconds/minutes)

Relay-side mechanics (from reading the current source): the expected AUTH url is derived in nip42_expected_relay_url as scheme from the configured RELAY_URL + host from the connection's tenant, and normalize_relay_url keeps ws/wss as distinct families. So if the mobile app signs its AUTH event with any variant that doesn't normalize to wss://<host> — e.g. a stored ws:// scheme or a URL carrying the /invite/... path — auth fails on every reconnect, forever. The claim path (HTTPS) succeeds, which is why the member shows up on the roster while the websocket never authenticates: the user "joins" but can never load anything.

Two workarounds un-stuck our users, both of which implicate the invite flow's stored relay URL rather than the relay or network:

1. Remove the community entry in the app, then rejoin via "I'm a member or admin" entering just the bare host (buzz.example.com) — connects, auths, role restored from the roster.
2. Provisioning the identity via the legacy buzz:// base64 payload ({relayUrl, pubkey, nsec}) — connects and auths fine with the same relay.

Happy to provide full relay logs or run a diagnostic build if it helps.

[Rodribm10]

Retomando o relato original como dono da comunidade.

A issue foi fechada como concluída, mas a condição de entrega que importa para uma comunidade operacional ainda precisa de prova ponta a ponta em aparelho limpo. Não estou afirmando aqui que o bug continua reproduzível; estou registrando a validação necessária para confirmar o fechamento.

Por favor, validem em iPhone sem instalação/identidade Buzz anterior:

1. Criar um link de convite de comunidade.
2. Abrir o link no iPhone novo (incluindo a transição loja → app, se aplicável).
3. Garantir que o usuário obtenha uma identidade própria, sem parear ou copiar a identidade do administrador.
4. Confirmar que a comunidade e os canais autorizados carregam, que o usuário consegue enviar uma mensagem e que tudo continua disponível após fechar e reabrir o app.
5. Confirmar que convite inválido, expirado ou revogado falha com segurança.

Se qualquer etapa falhar ou terminar em Connecting…, esta issue deve ser reaberta. Parear o aparelho do colaborador com a conta do administrador não é alternativa aceitável, pois transfere a identidade errada.

Isso é o bloqueio para convidar equipes que têm somente celular.