iOS App Store 0.4.12 never opens a WebSocket after successful invite on self-hosted rela

[jhw367]

Describe the bug

On the current App Store release (0.4.12), Buzz successfully joins a self-hosted community but never establishes a WebSocket connection afterwards.

The invite is claimed successfully, the member is created on the relay, and independent testing confirms that HTTPS, TLS 1.3, WSS (HTTP 101), Caddy and the relay are all functioning correctly. However, the iOS app remains stuck alternating between "Connecting..." and "Reconnecting..." indefinitely.

During repeated packet captures, the app never attempts to open a TCP connection to the relay after the invite has been claimed. Therefore no TLS handshake, HTTP Upgrade, WebSocket session or NIP-42 authentication ever occurs. The server never receives a connection attempt from the iOS app after the invite has been claimed.

---

Steps to reproduce

1. Install Buzz from the iOS App Store (version 0.4.12).
2. Join a self-hosted community using an invite link.
3. The invite claim succeeds.
4. The community member is created successfully.
5. The app remains on "Connecting..." / "Reconnecting..." forever.

---

Server observations

• HTTPS works.
• Invite claim succeeds.
• Member is created.
• Community remains intact.
• WSS endpoint responds correctly (HTTP 101).
• Relay, PostgreSQL, Redis, MinIO and Caddy are healthy.
• During repeated packet captures:
  • no TCP connection is opened to port 443;
  • no TLS handshake occurs;
  • no HTTP Upgrade request arrives;
  • no WebSocket reaches the relay;
  • no NIP-42 authentication starts.

---

Expected behavior

After the invite is accepted, the app should establish a WebSocket connection to the relay, complete authentication, and open the community normally.

---

Version and platform

• Buzz version: 0.4.12 (App Store)
• OS: iOS (latest public release)

---

Logs / additional context

Self-hosted environment

• Official block/buzz relay
• Caddy reverse proxy
• TLS 1.3
• Custom DNS (buzz.home.arpa)
• Trusted local CA installed on iPhone
• HTTPS verified
• WSS verified (HTTP 101)
• PostgreSQL healthy
• Redis healthy
• MinIO healthy

Question

Is this a known issue in the current App Store build? If so, has it already been fixed in a newer internal/TestFlight build, or would you like additional diagnostics from the self-hosted environment?

[jhw367]

I traced this to an existing bug that appears to match this report exactly.

The affected code path in Buzz Mobile 0.4.12 is mobile/lib/shared/relay/relay_provider.dart in RelayConfig.wsUrl:

String get wsUrl {
  final uri = Uri.parse(baseUrl);
  final scheme = uri.scheme == 'https' ? 'wss' : 'ws';
  return uri.replace(scheme: scheme).toString();
}

For a community joined by invite, the stored relay URL is wss://buzz.home.arpa. Because uri.scheme == 'https' is false for wss, the getter rewrites it to ws://buzz.home.arpa, so the app attempts plaintext WebSocket on port 80 instead of WSS on 443. This explains why the HTTPS invite claim succeeds, the member is created, but no TCP/TLS/WebSocket connection ever reaches Caddy or the relay afterwards.

This was fixed in PR #3139, merged on 2026-07-29 as commit 047533c56c2a2d03f23ef3edb990e58405767aac (fix(mobile): keep TLS on relays joined by invite). The fix canonicalizes stored wss:// origins back to https:// before deriving the WebSocket URL, so wsUrl becomes wss://... again. It also repairs already-persisted communities on read, so no new invite or app reset should be required once a build containing that commit is installed.

Current main contains the corrected implementation in mobile/lib/shared/relay/relay_provider.dart; the App Store build 0.4.12 appears to predate the merged fix.

Could you confirm which public iOS release will include commit 047533c56c2a2d03f23ef3edb990e58405767aac?