MeshCore évolue, les réglages à surveiller

En ce début avril, 2 grosses évolutions sont en cours au niveau de MeshCore : le système de régions et le passage de l’indication des répéteurs dans les chemins à 2 (ou 3) octets. Rentrons un peu dans les détails :

Régions

Depuis déjà quelques versions, il est possible de restreindre la diffusion de messages à des régions. Avec l’agrandissement permanent du maillage, l’idée est d’éviter que quelqu’un qui poste un message sur le canal « Public » depuis la Pologne voit son message répété dans toute l’Europe, ce qui risque à terme de faire écrouler le réseau. Il est également peu pertinent qu’un canal local soit diffusé dans toutes la France.

La segmentation va se faire via l’utilisation conjointe de 2 paramétrages :

  • celui des répéteurs : pour chacun on va définir une granularité du lieu où il se trouve, par exemple son pays, sa région (au sens région française), son département.
  • celui des canaux : chaque utilisateur, dans son application définira dans quelles régions (au sens MeshCore) il veut que son message envoyé sur chaque canal soit relayé. Par exemple un canal hashtag nommé « #brest » pourrait être restreint à la région MeshCore associée au département du Finistère.

Problématique : pour être efficace il va être recommandé d’utiliser les mêmes principes pour toute la France. Les discussions vont bon train, les tests aussi, mais les outils pour supporter ces choix se contredisent un peu.

  • Historiquement nous utilisions les codes IATA des aéroports les plus proches. Ce principe reste d’actualité dans les analyseurs de paquets qui nous permettent de suivre l’évolution du maillage.
  • Liam Cottle, le créateur de l’application MeshCore (également très largement impliqué dans l’ensemble du projet) a créé une première version d’une carte de recommandation de nommage des régions, c’est automatiquement basé sur les nommages des « zones » openstreetmap : code iso à 2 lettres du pays (« fr » pour la France), code iso de la région (« fr-naq » pour Nouvelle-Aquitaine par exemple), département (district) en toutes lettres format du département non encore définitif (numéro ou nom en lettres).
    C’est donc une bonne première étape mais elle souffre actuellement de bugs et limites :
    • la carte recommande l’utilisation des majuscules pour les noms, notamment en proposant les commandes à taper pour paramétrer un répéteur, mais on peut également créer les régions directement via l’interface graphique de l’application MeshCore… qui elle convertit les majuscules en minuscules. Hors le système est sensible à la casse, et une région en minuscule n’est pas la même qu’une autre en majuscules. C’est bon tout est en minuscules désormais.
    • le choix du département en toutes lettres est discutable, c’est long (jusqu’à 20 caractères) et peut poser des problèmes lors de la saisie (pas d’accents autorisés). Il y a une norme ISO pour les départements français : « fr- » suivi les 2 ou 3 chiffres du département. C’est court, simple, unique, donc probablement plus intelligent à utiliser en France, mais pour l’instant Liam n’a pas encore intégré le nécessaire (l’info n’est pas accessible dans l’API qu’il utilise actuellement). Il a donc désactivé ce 3è niveau en attendant de trouver une solution adaptable en fonction des pays.
    • Liam Cottle indique lui-même que sa carte n’est qu’une première ébauche et non pas une recommandation à suivre, elle est donc susceptible d’évoluer.

Attention à ne pas mélanger canaux et régions :

  • les régions définissent des zones géographiques
  • les canaux définissent des usages

Si vous voulez faire un canal dédié aux Réserves Communales de Sécurité Civile par exemple, vous pouvez créer le canal #rcsc et dans les paramètres de ce canal définir vers quelles régions vous souhaitez que les messages soient relayés (votre département par exemple). Vous n’avez pas à créer de région « rcsc », ça n’a pas de sens.

Notre recommandation :

Il est avant tout urgent d’attendre, notamment pour ne pas bloquer la transmission de messages à cause de paramètres incompatibles entre eux. La région Lyonnaise essuie les plâtres car elle est d’ores-et-déjà reliée à la Suisse, l’Allemagne et indirectement toute l’Europe de l’est, le besoin de cloisonnement commence donc réellement à être nécessaire.

Nous ferons une recommandation officielle par la suite, le reste de la France n’ayant pas strictement encore besoin de restreindre la répétition des messages.

L’indicatif (en-tête) de 2 ou 3 octets

Lorsqu’un message voyage de répéteur en répéteur avant d’atteindre son destinataire, chaque répéteur ajoute à une liste, le premier octet de sa clé publique, ce qui correspond aux 2 premiers caractères hexadécimaux de son identifiant unique, par exemple e4 ou b9. Ainsi on peut facilement retrouver par où est passé un message, ce qui est très pratique pour comprendre le maillage et l’améliorer.

Problème : 2 caractères hexa, ça fait 256 valeurs possibles. Aujourd’hui nous avons largement dépassé 256 répéteurs sur la France et nous sommes connectés aux pays voisins. Les doublons sont donc nombreux, et il est fréquent de croire qu’un message est passé par l’autre bout de la France plutôt que par un répéteur beaucoup plus proche. Cela ne pose pas de souci dans l’acheminement des messages, mais leur suivi devient compliqué.

Solution : le protocole a évolué afin de permettre l’inclusion de 2 octets (4 caractères hexadécimaux, soit 65535 valeurs possibles) ou 3 octets (6 caractères hexa, soit 16,7 millions de valeurs).

La contrepartie c’est la diminution du nombre de sauts possibles : 32 (2 octets) ou 21 (3 octets) au lieu de 64. En pratique cela ne devrait pas déranger grand monde, sauf si vous aviez prévu de contacter une tante à l’autre bout du monde via MeshCore.

Notre recommandation :

Pour que la bascule puisse se faire il faut impérativement que tous les répéteurs concernés dans le maillage aient un firmware au moins en version 1.14 ! Assurez-vous avec les autres membres de votre communauté que les mises-à-jour sont bien effectuées avant d’activer toute notion d’en-tête à 2 octets. Ces mises-à-jour peuvent être effectuées sans souci sur plusieurs semaines si besoin. Même à jour, les répéteurs fonctionneront sans souci – comme avant – en continuant à utiliser des en-têtes de 1 octet.

Mettez également tous vos compagnons à jour à la dernière version disponible. Si vous utilisez des firmware exotiques (MeshOS, WhisperOS par exemple), assurez-vous qu’ils gèrent bien le passage à 2 octets.

Une fois toutes les mises-à-jour effectuées, vous pourrez :

  • activer à la section « paramètres expérimentaux » la taille d’en-tête à « 2 octets » dans l’application pour votre compagnon
  • saisir la commande suivante dans chacun de vos répéteurs (administration à distance, icône « ligne de commande » tout en bas) :
    set path.hash.mode 1
    Les valeurs possibles sont 0 pour 1 octet / 1 pour 2 octets / 2 pour 3 octets (oui c’est de la logique informatique 🤪)

Dans un premier temps Gaulix recommande l’utilisation du système sur 2 octets. Le passage à 3 octets ne se fera que si cela s’avère nécessaire par la suite.