Démo web

Consulter Ğchange dans le navigateur — aucune installation.

Contenu généré par IA. Cette page a été rédigée avec l’aide d’une IA et n’a pas encore été entièrement relue — elle peut comporter des imprécisions.

La démo web permet de chercher et consulter les annonces et profils, et de voir la carte des membres, directement dans le navigateur. Il n’y a rien à installer et aucun compte à créer.

Ce que c’est vraiment : un client p2p dans un onglet

La page n’est pas une vue sur un serveur : c’est un nœud complet. Le cœur (compilé en WebAssembly) tourne dans l’onglet, garde ses données dans le stockage du navigateur, et exécute le moteur SQL en local — les recherches, tris et filtres se calculent sur votre machine.

Les données arrivent par synchronisation pair-à-pair, depuis un nœud d’amorçage. Comme un navigateur ne peut pas ouvrir de socket UDP, le transport passe par un relai iroh en WebSocket (wss://) : le relai ne fait que faire passer le canal chiffré, il ne sert pas les données lui-même.

Trois conséquences, qui sont le rôle produit de cette démo :

elle ne consomme pas de serveur : pas de backend, pas de base de données à héberger, un simple dossier de fichiers statiques ;
elle fonctionne hors-ligne : ce qui a été reçu est rangé en IndexedDB et relu au chargement suivant, qui ne synchronise plus qu’un diff ;
elle donne envie d’installer l’app : c’est une vitrine, la version native fait le reste (publication, clés, connectivité directe).

Pourquoi lecture seule

Publier suppose de signer ses données avec sa clé privée. Manipuler une clé privée dans une page web est risqué, et il n’y a donc pas de comptes ici : la démo est un client de consultation. Pour publier, passer par l’app desktop.

Construire et servir

git clone https://git.duniter.org/HugoTrentesaux/datapod
cd datapod
nix run .#build-web
# → app/build/web/ : dossier statique, servable par n'importe quel serveur HTTP

Le build web est impur (toolchain Flutter nightly + wasm-pack + réseau, hors sandbox Nix) — nix run .#build-web orchestre ces outils sur la machine hôte plutôt qu’un flutter build web manuel, pour rester reproductible (la flavor flavors/geopod.json est celle utilisée par défaut). app/build/web/ peut être déposé tel quel sur n’importe quel hébergement statique (pas de backend, pas de base de données à installer côté serveur).

Alimenter la démo en données réelles

Au premier chargement la page démarre vide (ou reprend ce qu’une visite précédente avait déjà reçu, gardé en IndexedDB), puis elle se synchronise. Deux valeurs suffisent, et elles disent la même chose de deux façons :

# Dev — relai et ticket passés au runtime, en une variable :
flutter build web --release -t lib/main_web.dart \
  --dart-define=GC_SYNC=<url-du-relais>|<ticket-du-noeud>

# Build publiée — via un fichier de flavor (TRAME_RELAY + TRAME_BOOTSTRAP),
# que l'app recombine en <relais>|<ticket>.
nix run .#build-web

Prérequis côté serveur, sans quoi la page reste vide :

le relai est joignable en wss:// depuis l’extérieur (TLS terminé par le reverse-proxy, Upgrade: websocket laissé passer) ;
TRAME_RELAY est écrit en https:// — pas wss:// : le client dérive lui-même le schéma WebSocket, et interroge <relai>/ping en HTTP ;
le nœud d’amorçage tourne avec ce même relai (--relay <url>), et TRAME_BOOTSTRAP est le ticket qu’il a écrit une fois en ligne sur le relai (un ticket produit hors relai ne contient que des adresses IP, inutilisables depuis un navigateur).

Le repli par passerelle HTTP (option, non activée)

Le code sait aussi s’alimenter par une passerelle HTTP (trame-gateway) : adoption d’un root creux puis rapatriement des blocs à la demande en GET /ipfs/<cid>?format=raw (TRAME_GATEWAY_URL de la flavor). Cette option n’est pas activée — TRAME_GATEWAY_URL est vide dans les flavors publiées, et la renseigner détourne le boot vers ce chemin au lieu du p2p. Elle est conservée comme repli (réseau où le WebSocket du relai est bloqué) ; l’activer exige une passerelle déployée renvoyant Access-Control-Allow-Origin.

La mise en production de la démo publique (relai et nœud à vérifier, flavor, build, critère de succès) est décrite pas à pas côté opérateur : Déploiement serveur → Remettre la démo web en route.