Relais des canaux geohash : mise à jour des listes sur iOS et Android

État au 26/10/2026, d'après les sources publiques de BitChat (dépôts permissionlesstech/bitchat, bitchat-android et georelays) et des mesures faites avec examples/geohash_map.rs.

En bref

• Les messages d'un canal geohash ne vont que sur les 5 relais les plus proches du centre de la cellule. Ces relais sont pris dans une liste de relais géolocalisés.
• iOS et Android ne lisent pas la même liste. iOS lit une copie relue à la main, mise à jour irrégulièrement. Android lit la liste brute, régénérée chaque jour.
• Les deux apps peuvent donc choisir des relais différents pour le même canal. Un message posté depuis Android peut ne jamais atteindre un utilisateur iOS du même canal, et inversement.
• La liste d'iOS garde aussi des relais morts que la liste brute a déjà retirés.

1. D'où vient la liste : le dépôt georelays

Le dépôt permissionlesstech/georelays produit le fichier nostr_relays.csv (une ligne hôte,latitude,longitude par relais). Une GitHub Action le régénère chaque jour, en trois étapes :

Deux limites découlent de cette méthode :

• Positions approximatives. La géolocalisation par IP renvoie souvent le centre d'une ville. Beaucoup de relais partagent donc exactement les mêmes coordonnées : par exemple 6 relais au même point de Londres (51.5072, -0.1276) et plusieurs au centre de Paris. Cela crée des égalités dans le classement par distance.
• Relais inutilisables par l'app. Le filtre s'authentifie (NIP-42), mais l'app ne le fait pas. Un relais qui exige l'authentification passe donc le filtre tout en restant inutilisable par l'app.

2. iOS : une copie relue, mise à jour par PR

Le dépôt de l'app iOS garde sa propre copie, relays/online_relays_gps.csv.

• Le workflow fetch_georelays.yml tourne chaque dimanche à 06:00 UTC. Il récupère nostr_relays.csv en amont (à un commit figé), puis le fait vérifier par scripts/validate_georelays.py : encodage, schéma, taille, hôtes en wss, coordonnées, doublons, ampleur de l'écart avec la version précédente.
• S'il y a des changements, le workflow ouvre une PR qui n'est pas fusionnée automatiquement. Elle n'entre en vigueur que lorsqu'un mainteneur la relit et la fusionne.
• Dernière mise à jour fusionnée : 26/07/2026. Au 26/10/2026, la liste iOS a donc environ trois mois de retard sur la liste en amont.

Dans l'app (GeoRelayDirectory.swift, TransportConfig.swift) :

3. Android : la liste brute, directement

Dans RelayDirectory.kt :

4. Récapitulatif

5. Conséquences pour les canaux

5.1 Les deux apps ne se retrouvent pas toujours sur les mêmes relais

Chaque app prend les 5 relais les plus proches dans sa propre liste. Dès que les deux listes diffèrent près d'une cellule, les deux sélections diffèrent aussi. Un canal n'est alors réellement partagé que par les relais communs aux deux sélections.

Mesures du 26/10/2026 (geohash_map, colonne « rang iOS / rang Android », - = non choisi) :

#u09tv (Paris) : 8 relais au total, 2 seulement communs aux deux apps.

Ce qu'on en tire :

• iOS publie sur 2 relais morts, qui ont déjà disparu de la liste en amont.
• Il ne reste à iOS qu'un seul relais commun et opérationnel avec Android (wild-vibes).
• Le seul relais où le canal est actif n'est choisi que par Android.

#u1 (Pays-Bas) : 9 relais au total, 3 communs. Les relais les plus actifs (nostr.stakey.net avec 104 événements, relay.mccormick.cx avec 123, test.relays.nuts.cash avec 98) sont choisis surtout, ou uniquement, par Android.

5.2 Effets visibles pour les utilisateurs

• Messages qui n'arrivent pas d'une plateforme à l'autre : un message ne passe que par les relais choisis par les deux apps. S'ils sont en panne ou inexistants, le canal est coupé en deux.
• Présence incomplète : les signaux de présence (kind 20001) suivent le même chemin. La liste « people » d'un utilisateur iOS peut ne pas montrer certains utilisateurs Android, et inversement.
• Variation dans le temps : la liste Android change chaque jour, celle d'iOS par à-coups. La partie commune aux deux sélections change donc sans que les utilisateurs touchent à rien.
• Pas de rattrapage : les kinds 20000/20001 sont éphémères. Les relais ne les stockent généralement pas, donc un message qui n'a pas atteint un relais au moment de l'envoi est perdu pour ceux qui lisent ce relais.

5.3 Effets aggravants

• Égalités de distance : avec des coordonnées identiques, iOS et Android départagent différemment la 5ᵉ place. Les sélections peuvent donc différer même avec la même liste.
• Relais exigeant NIP-42 : présents dans la liste, mais inutilisables par l'app (voir §1).
• Pas de remplacement : une app ne remplace pas un relais mort par le suivant. Un relais mort réduit donc directement le nombre de relais effectifs du canal.

6. Ce que font nos outils

• examples/geohash_map.rs affiche, pour un geohash, la sélection iOS et la sélection Android, avec le rang de chaque relais dans chacune et le résultat d'un test de lecture du canal. Le mode overlay produit une carte. Les relais en panne durable (certificat, DNS, connexion refusée, HTTP 4xx) sont écartés par défaut ; --no-drop-dead les garde.
• examples/geohash_bot.rs lit les deux listes (--relays-csv, --android-csv) et utilise l'union des deux sélections, pour atteindre les utilisateurs des deux plateformes. Il écarte aussi par défaut les relais en panne durable.

Pour reproduire les mesures :

curl -sLO https://raw.githubusercontent.com/permissionlesstech/bitchat/main/relays/online_relays_gps.csv
curl -sLO https://raw.githubusercontent.com/permissionlesstech/georelays/main/nostr_relays.csv
cargo run --example geohash_map -- u09tv overlay

7. Pistes (pour BitChat, hors de ce crate)

• Faire lire la même liste aux deux apps : soit Android passe sur la copie relue, soit iOS accepte la liste en amont validée automatiquement.
• Fusionner plus souvent les PR hebdomadaires, ou les fusionner automatiquement quand le validateur ne signale qu'un écart faible.
• Aligner les deux apps sur la même règle de départage des égalités.
• Retirer de la liste les relais qui exigent NIP-42, puisque l'app ne fait pas d'authentification. Le filtre en amont pourrait tester sans authentification.

Sources

• iOS : bitchat/Nostr/GeoRelayDirectory.swift, bitchat/Services/TransportConfig.swift, .github/workflows/fetch_georelays.yml, .github/workflows/validate_georelays.yml (dépôt permissionlesstech/bitchat). Historique de relays/online_relays_gps.csv : derniers commits le 31/05, 07/06, 14/06, 21/06 et 26/07/2026.
• Android : app/src/main/java/com/bitchat/android/nostr/RelayDirectory.kt (dépôt permissionlesstech/bitchat-android).
• Liste en amont : README et scripts du dépôt permissionlesstech/georelays (dernière mise à jour le 25/10/2026).
• Mesures : geohash_map, le 26/10/2026. L'état des relais change d'un jour à l'autre.