mirror of
https://github.com/block/buzz.git
synced 2026-10-31 14:31:02 +00:00
047533c56c
## Summary Communities joined via an invite link never connect: the app dials `ws://` on port 80 instead of `wss://` on 443 and sits on "Reconnecting…" indefinitely. `RelayConfig.baseUrl` is documented as an HTTP origin, but the two onboarding flows disagree on what they persist: - **Device pairing** validates and stores `https://` — `pairing_provider.dart:657` throws on anything else. - **Invite join** stores the relay URL straight off the invite link, and `deep_link.dart:165` always emits `ws://` or `wss://`. `wsUrl` only special-cased `https://`, so a `wss://` base fell through to the plaintext branch: ```dart final scheme = uri.scheme == 'https' ? 'wss' : 'ws'; // 'wss' is not 'https' ``` The claim request itself succeeds, because `_claimUrlFromRelay` (`invite_join_provider.dart:242`) maps `wss → https` explicitly. Only the socket path is missing that conversion — which is why the community appears, correctly named, and then never loads. The same `baseUrl` also feeds `/query` (`relay_session.dart:136`), media upload (`media_upload.dart:765`), Blossom auth (`media_auth.dart:128`) and `relayClientProvider` (`relay_provider.dart:113`), so those requests were malformed too. Where port 80 *does* answer, it is additionally a silent TLS downgrade after `validateInviteRelayUri` insisted on `wss://`. This folds the websocket schemes back to their HTTP equivalents in `baseUrl` itself, so every consumer is correct by construction rather than needing a second getter remembered at each call site, and communities **already persisted** with `wss://` are repaired on read without a migration. `community_icon_provider.dart:46` already performs this same conversion locally. One subtlety worth flagging for review: the normalization is derived in the getter rather than applied in the constructor, so the constructor stays `const`. The compile-time fallback at `relay_provider.dart:77` relies on const canonicalization for a stable identity across rebuilds, and Riverpod's `defaultUpdateShouldNotify` is `previous != next` (`element.dart:361`), which falls back to identity for this class. A `factory` constructor here yields a fresh instance per rebuild, which tears down and resubscribes every listener — `channels_provider_test.dart` catches it as an unexpected unsubscribe during reconnect. ### Related issue Fixes #2662. ### Testing `flutter test` — **705 passed, 1 skipped, 0 failed** `flutter analyze` — No issues found `dart format --set-exit-if-changed .` — 249 files, 0 changed Run against the Hermit-pinned SDK (Flutter 3.41.7 / Dart 3.11.5), matching CI. 10 new unit tests in `mobile/test/shared/relay/relay_config_test.dart` covering both onboarding schemes, `http`/`https` passthrough, non-default ports, and agreement between the invite and pairing paths for the same relay. Verified end-to-end against a self-hosted relay behind `tailscale serve`, which terminates TLS on 443 and leaves port 80 closed. Relay logs show the invite claim succeeding over HTTPS at the moment of joining, while no WebSocket connection ever arrives — no `WebSocket connection established`, no NIP-42 auth, no `kind:0` profile, no push registration — across the relay's entire history, even though the member row is present and correct. Port-80 refusals are not logged by `tailscaled`'s netstack, which is why the retries leave no trace server-side. Reproduced on both iOS and Android. --------- Signed-off-by: Krishna C <github@kumb.uk>
51 lines
1.8 KiB
Dart
51 lines
1.8 KiB
Dart
import 'dart:async';
|
|
|
|
import 'package:shared_preferences/shared_preferences.dart';
|
|
|
|
/// Reads an identity-scoped preference, migrating values left under a
|
|
/// pre-canonicalization relay origin.
|
|
///
|
|
/// Identity-scoped keys embed the relay origin, and that origin used to be
|
|
/// whatever scheme the onboarding flow happened to persist — `wss://` for an
|
|
/// invite join, `https://` for device pairing. Now that [RelayConfig.baseUrl]
|
|
/// canonicalizes the scheme, an install that joined by invite would compute a
|
|
/// different key than the one its data was written under, leaving that data on
|
|
/// disk but unreachable.
|
|
///
|
|
/// The value under [canonicalKey] wins. Otherwise a value under [legacyKey] is
|
|
/// returned straight away and promoted onto the canonical key in the
|
|
/// background. The legacy entry is removed only once the copy reports success,
|
|
/// so a migration interrupted mid-flight leaves the original readable and the
|
|
/// next read simply retries.
|
|
///
|
|
/// Pass matching accessors for the stored type — `getString`/`setString`, or
|
|
/// `getStringList`/`setStringList`.
|
|
T? readMigratedPref<T>(
|
|
SharedPreferences prefs, {
|
|
required String canonicalKey,
|
|
required String legacyKey,
|
|
required T? Function(String key) read,
|
|
required Future<bool> Function(String key, T value) write,
|
|
}) {
|
|
final canonical = read(canonicalKey);
|
|
if (canonical != null) return canonical;
|
|
|
|
// Pairing-created communities already store an HTTP origin, so the two keys
|
|
// coincide and there is nothing to migrate.
|
|
if (canonicalKey == legacyKey) return null;
|
|
|
|
final legacy = read(legacyKey);
|
|
if (legacy == null) return null;
|
|
|
|
unawaited(_promote(prefs, legacyKey, write(canonicalKey, legacy)));
|
|
return legacy;
|
|
}
|
|
|
|
Future<void> _promote(
|
|
SharedPreferences prefs,
|
|
String legacyKey,
|
|
Future<bool> copy,
|
|
) async {
|
|
if (await copy) await prefs.remove(legacyKey);
|
|
}
|