Et si nos sentiers n’appartenaient à aucune plateforme ?
Manifeste pour un réseau outdoor libre, communautaire et construit sur Nostr
Nous sommes des millions à marcher, courir, rouler, explorer des vallées, des forêts, des crêtes et des chemins oubliés.
Nous utilisons des cartes issues d’OpenStreetMap. Nous enregistrons des traces GPS. Nous publions des photos. Nous décrivons des itinéraires. Nous signalons un arbre tombé, une passerelle cassée, un sentier fermé ou une source asséchée.
Nous créons collectivement une masse considérable d’informations utiles.
Pourtant, la plupart de ces données finissent enfermées dans des plateformes privées.
Les utilisateurs produisent les contenus. Les plateformes les possèdent, les organisent, les monétisent et décident de leur visibilité. Elles peuvent modifier leurs tarifs, supprimer des fonctionnalités, fermer des comptes, imposer de la publicité ou revendre l’entreprise avec toute sa communauté.
Ce modèle a produit des services utiles. Mais il n’est ni inévitable, ni satisfaisant.
Nous pouvons construire autre chose.
Un réseau où les parcours appartiennent à leurs auteurs.
Un réseau où l’identité ne dépend pas d’un serveur.
Un réseau où les données peuvent être copiées, vérifiées, sauvegardées et partagées.
Un réseau où les communautés locales peuvent héberger leurs propres infrastructures sans se couper des autres.
Un réseau où les contributeurs peuvent être soutenus directement, en Bitcoin, sans intermédiaire obligatoire.
Ce réseau pourrait être construit sur OpenStreetMap, Nostr et Bitcoin.
Le problème n’est pas la carte
Les outils cartographiques libres existent déjà.
OpenStreetMap fournit une base géographique mondiale construite par ses contributeurs. OsmAnd permet de télécharger des cartes, de suivre des traces, de naviguer hors ligne et de préparer des itinéraires.
Le problème n’est donc pas seulement de savoir où passe un chemin.
Le vrai besoin est ailleurs :
- découvrir une randonnée pertinente ;
- comprendre son intérêt ;
- connaître sa difficulté réelle ;
- voir des photos récentes ;
- lire les retours de personnes qui l’ont parcourue ;
- connaître l’état actuel du terrain ;
- identifier les variantes ;
- recevoir une alerte lorsqu’un passage devient dangereux ;
- savoir qui a vérifié l’information ;
- conserver ses favoris, ses traces et ses publications.
C’est cette couche communautaire et éditoriale qui reste aujourd’hui largement centralisée.
L’idée : un protocole ouvert pour les parcours outdoor
Le projet ne serait pas seulement une nouvelle application.
Il s’agirait d’un protocole ouvert décrivant les parcours, leurs versions, leurs médias, leurs commentaires, leurs validations et leurs signalements.
Une randonnée pourrait être publiée comme un événement signé contenant :
- son titre ;
- sa description ;
- sa position ;
- sa distance ;
- son dénivelé ;
- sa difficulté ;
- son activité ;
- son fichier GPX ;
- ses photographies ;
- sa licence ;
- son auteur ;
- son historique de modifications.
D’autres utilisateurs pourraient ensuite publier des événements liés :
- commentaire ;
- correction ;
- variante ;
- photographie ;
- signalement ;
- validation ;
- recommandation ;
- compte rendu récent ;
- récompense en sats.
Chaque élément serait signé cryptographiquement.
La donnée ne serait plus une ligne opaque dans la base privée d’une plateforme. Elle deviendrait un objet portable, vérifiable et réutilisable par plusieurs applications.
Pourquoi Nostr ?
Nostr apporte une propriété essentielle : l’identité appartient à l’utilisateur, pas au serveur.
Sur une plateforme classique, votre compte existe parce qu’une entreprise accepte de l’héberger. Votre nom, vos abonnements, votre réputation et vos publications dépendent de cette entreprise.
Sur Nostr, l’identité repose sur une paire de clés cryptographiques.
Vous pouvez publier depuis une application, changer d’application, utiliser plusieurs relais ou héberger votre propre infrastructure sans changer d’identité.
Appliqué à un réseau de randonnée, cela signifie qu’un contributeur pourrait :
- publier un parcours depuis une application ;
- le répliquer sur plusieurs relais ;
- changer d’hébergeur ;
- conserver son identité ;
- conserver sa réputation ;
- sauvegarder ses contenus ;
- utiliser une autre interface ;
- migrer vers son propre serveur.
Le compte ne serait plus prisonnier du service.
Le service deviendrait remplaçable.
Mutualiser sans centraliser
Tout le monde ne veut pas administrer un serveur. Et heureusement.
Le réseau pourrait proposer plusieurs instances publiques ou communautaires prêtes à l’emploi :
- une instance généraliste ;
- une instance dédiée aux Alpes ;
- une instance associative ;
- une instance exploitée par un parc naturel ;
- une instance spécialisée dans le trail ;
- une instance pour les itinéraires accessibles en famille.
L’utilisateur pourrait simplement installer l’application, créer son profil et commencer à explorer.
Mais une association, un club, une collectivité ou un particulier pourrait aussi installer sa propre infrastructure.
Son serveur pourrait conserver :
- ses propres publications ;
- les parcours de sa région ;
- les médias de ses membres ;
- les contenus qu’il souhaite garantir dans le temps ;
- les données des auteurs qu’il suit.
Les instances pourraient échanger les informations entre elles grâce à Nostr.
L’objectif n’est donc pas de créer une multitude de silos isolés. Il est de permettre une mutualisation choisie, avec une véritable porte de sortie.
Une communauté peut profiter des infrastructures existantes aujourd’hui et devenir autonome demain, sans reconstruire tout son réseau ni perdre ses données.
Les cartes restent ouvertes
OpenStreetMap constituerait le socle géographique.
Les chemins, routes, refuges, parkings, points d’eau, barrières, surfaces et itinéraires balisés continueraient à être maintenus dans OSM.
Le réseau Nostr apporterait la couche sociale :
- parcours proposés ;
- sélections ;
- récits ;
- commentaires ;
- photographies ;
- état du terrain ;
- validations ;
- recommandations ;
- réputation.
Il ne s’agit pas de concurrencer OpenStreetMap ou de dupliquer inutilement sa base.
Il s’agit de construire au-dessus d’elle un réseau communautaire libre, spécialisé dans la pratique outdoor.
Les photos et les GPX ne doivent pas saturer les relais
Nostr ne doit pas devenir un entrepôt de fichiers lourds.
Les événements pourraient contenir les métadonnées et les références vers :
- des fichiers GPX ;
- des photographies ;
- des vidéos courtes ;
- des miniatures ;
- des documents complémentaires.
Ces fichiers pourraient être stockés sur des serveurs compatibles avec un protocole comme Blossom.
Chaque fichier serait identifié par son empreinte cryptographique. Plusieurs serveurs pourraient conserver une copie du même contenu.
Un parcours important pourrait ainsi être répliqué :
- sur le serveur de son auteur ;
- sur celui d’une association ;
- sur celui d’un territoire ;
- sur une instance publique.
La disparition d’un hébergeur ne signifierait plus nécessairement la disparition du contenu.
Bitcoin comme outil natif de contribution
Bitcoin ne serait pas ajouté comme un gadget marketing.
Il pourrait jouer un rôle structurel.
Chaque parcours, photographie, correction ou signalement pourrait recevoir des paiements Lightning.
Un utilisateur pourrait envoyer quelques centaines de sats à une personne ayant :
- décrit une randonnée remarquable ;
- corrigé une erreur ;
- signalé un danger ;
- vérifié un itinéraire après une tempête ;
- publié des photos utiles ;
- entretenu une instance communautaire.
Une association pourrait lancer une prime :
«21 000 sats pour vérifier l’état de ce parcours après un éboulement.»
Une collectivité pourrait financer des campagnes de vérification.
Une communauté pourrait récompenser ses meilleurs contributeurs.
Un serveur pourrait facturer quelques sats pour :
- garantir le stockage de médias ;
- fournir un archivage longue durée ;
- télécharger des cartes volumineuses ;
- lutter contre le spam ;
- financer son fonctionnement.
Le modèle économique ne reposerait pas nécessairement sur la publicité, la surveillance ou la vente de données.
La valeur pourrait circuler directement entre utilisateurs, contributeurs et opérateurs d’infrastructure.
Une réputation portable et pluraliste
Toutes les informations ne se valent pas.
Le signalement d’un accompagnateur local n’a pas la même valeur qu’un commentaire anonyme publié depuis son canapé.
Mais la solution ne doit pas être un score central attribué par une plateforme.
La réputation pourrait être multidimensionnelle :
- nombre de parcours réellement effectués ;
- ancienneté ;
- signalements confirmés ;
- corrections acceptées ;
- connaissance d’une région ;
- validations par des clubs ;
- confiance accordée par d’autres utilisateurs ;
- soutien reçu en sats.
Chaque utilisateur pourrait choisir ses propres sources de confiance :
- clubs locaux ;
- amis ;
- guides ;
- associations ;
- parcs naturels ;
- contributeurs reconnus ;
- listes communautaires.
Il n’y aurait pas une vérité algorithmique unique.
Il y aurait plusieurs graphes de confiance, transparents et sélectionnables.
Plusieurs politiques de modération peuvent coexister
Un réseau décentralisé ne signifie pas l’absence de règles.
Une instance familiale pourrait masquer les itinéraires dangereux.
Un club alpin pourrait publier uniquement des parcours vérifiés.
Une communauté trail pourrait accepter des itinéraires plus techniques.
Un parc naturel pourrait mettre en avant les chemins officiels et signaler les zones protégées.
Une instance généraliste pourrait accepter plus largement les contributions.
Les contenus restent signés. Les politiques de sélection et de modération peuvent différer.
L’utilisateur choisit les communautés, les relais et les autorités auxquelles il souhaite faire confiance.
La modération ne disparaît pas. Elle cesse simplement d’être monopolisée par une seule entreprise.
L’application doit rester simple
Le grand public ne devrait pas avoir à comprendre les clés publiques, les relais, les événements ou les protocoles de stockage.
L’expérience doit rester évidente :
- ouvrir l’application ;
- chercher une randonnée ;
- consulter la carte et les photos ;
- télécharger le parcours ;
- suivre la trace hors ligne ;
- publier un retour ;
- envoyer éventuellement quelques sats.
Les fonctions avancées pourraient rester accessibles à ceux qui les souhaitent :
- choix des relais ;
- serveur personnel ;
- synchronisation locale ;
- signataire distant ;
- portefeuille Lightning ;
- réplication des médias ;
- sélection des indexeurs.
La souveraineté doit être disponible, pas imposée sous forme de parcours du combattant technique.
Ne pas tout reconstruire dès le premier jour
La première version n’a pas besoin de remplacer OsmAnd.
Un produit minimal pourrait déjà permettre :
- de découvrir des itinéraires ;
- de publier un parcours ;
- de consulter les photos ;
- de lire les commentaires ;
- de signaler l’état du terrain ;
- de télécharger le fichier GPX ;
- d’ouvrir le parcours dans OsmAnd ;
- de soutenir un contributeur en Lightning.
Cette première version permettrait de tester le protocole, l’usage communautaire et la qualité des données.
La navigation complète, les cartes vectorielles hors ligne et l’enregistrement GPS pourraient venir ensuite.
Le cœur du projet n’est pas le bouton de navigation.
Le cœur du projet est la propriété des données et la capacité de plusieurs applications à utiliser le même réseau.
Un laboratoire local avant un réseau mondial
Il serait inutile de lancer une plateforme vide couvrant toute la planète.
Le projet pourrait commencer sur un territoire limité, par exemple les Alpes françaises.
Une première communauté pourrait réunir :
- randonneurs ;
- traileurs ;
- vététistes ;
- cartographes OpenStreetMap ;
- clubs ;
- accompagnateurs ;
- refuges ;
- associations ;
- développeurs ;
- opérateurs de relais Nostr ;
- utilisateurs de Bitcoin.
L’objectif initial pourrait être simple :
- publier quelques centaines de parcours de qualité ;
- définir un format ouvert ;
- créer un premier client Android ;
- exploiter quelques relais communautaires ;
- tester le stockage distribué des médias ;
- intégrer les paiements Lightning ;
- documenter une installation auto-hébergée.
Une couverture excellente d’un territoire vaut mieux qu’un catalogue mondial vide ou médiocre.
Principes fondateurs proposés
Le projet pourrait s’appuyer sur quelques principes non négociables.
- L’identité appartient à l’utilisateur
Aucune instance ne doit pouvoir confisquer l’identité ou la réputation d’un contributeur.
- Les données doivent être portables
Parcours, commentaires, listes, photos et fichiers doivent pouvoir être exportés et répliqués.
- Le protocole doit être ouvert
Plusieurs applications doivent pouvoir lire et publier les mêmes objets.
- L’auto-hébergement doit être réaliste
Une installation personnelle ou associative doit être documentée et maintenable.
- Les instances doivent pouvoir coopérer
L’autonomie ne doit pas recréer des silos fermés.
- Les contributions doivent pouvoir être rémunérées
Les utilisateurs doivent pouvoir soutenir directement les personnes qui produisent de la valeur.
- La vie privée doit être respectée
Les positions personnelles, historiques de déplacement et données sensibles ne doivent pas être publics par défaut.
- OpenStreetMap doit rester le socle cartographique
Le projet doit contribuer à l’écosystème existant plutôt que le fragmenter.
- Le code doit être libre
L’infrastructure critique, le client et les formats doivent être auditables et réutilisables.
- Le réseau doit fonctionner sans autorité centrale obligatoire
Des services communs peuvent exister. Aucun ne doit devenir indispensable.
Ce projet n’existe pas encore
Il existe des briques.
Il existe des applications cartographiques libres.
Il existe OpenStreetMap.
Il existe Nostr.
Il existe Lightning.
Il existe des relais, des serveurs de fichiers, des indexeurs et des solutions auto-hébergées.
Mais l’assemblage cohérent de ces technologies autour d’un réseau outdoor communautaire reste largement à construire.
La difficulté ne sera pas seulement technique.
Il faudra aussi travailler sur :
- le format des événements ;
- les licences de données ;
- la modération ;
- la réputation ;
- la protection de la vie privée ;
- l’ergonomie ;
- la réplication ;
- la gouvernance ;
- le financement ;
- l’animation de la communauté.
C’est précisément pour cela que le projet mérite une discussion collective.
Qui serait intéressé pour participer ?
Nous cherchons des personnes intéressées par l’idée, qu’elles soient déjà prêtes à coder ou simplement à réfléchir.
Profils recherchés :
- développeurs Android ;
- développeurs web ;
- développeurs Nostr ;
- spécialistes SIG, PostGIS ou cartographie ;
- contributeurs OpenStreetMap ;
- administrateurs de relais ;
- concepteurs UX et UI ;
- randonneurs et pratiquants outdoor ;
- photographes ;
- clubs et associations ;
- spécialistes Lightning ;
- juristes des licences libres ;
- opérateurs d’infrastructures ;
- collectivités ou territoires intéressés par les communs numériques.
Il ne s’agit pas encore de vendre une application ou d’annoncer une feuille de route gravée dans le granit.
Il s’agit de répondre à quelques questions simples :
- Cette idée répond-elle à un besoin réel ?
- Quelles briques existent déjà ?
- Quel serait le meilleur prototype ?
- Quels événements Nostr faudrait-il définir ?
- Comment protéger les données de localisation sensibles ?
- Comment amorcer une communauté locale ?
- Qui aurait envie de participer à sa conception ou à sa construction ?
Construire les chemins numériques comme nous construisons les chemins réels
Un sentier ne naît pas parce qu’une plateforme l’a ajouté à son catalogue.
Il existe parce que des personnes l’ont parcouru, entretenu, cartographié, décrit, transmis et parfois réparé.
Nos infrastructures numériques pourraient fonctionner de la même manière.
Comme des communs.
Avec des contributeurs identifiables.
Avec des règles ouvertes.
Avec plusieurs chemins possibles.
Avec la possibilité de partir, de bifurquer, de copier, de reconstruire.
Avec une économie directe entre ceux qui produisent de la valeur et ceux qui en bénéficient.
Nous avons déjà les cartes.
Nous avons déjà les protocoles.
Nous avons déjà les moyens de paiement.
Il reste à relier les points.
Qui serait intéressé pour explorer cette piste, contribuer à la réflexion ou construire un premier prototype ?
#nostrfr #rando #trek #trail #app #dev #osmand #openstreetmap
Write a comment