Comme beaucoup, j’ai d’abord regardé ce qui existait. Il y a plein de logiciels P2P, c’est vrai. Mais après avoir creusé, je trouve qu’il leur manque systématiquement deux briques essentielles : une grille de clefs géographiques pour savoir où se trouve une offre, et une toile de confiance humaine pour savoir qui la propose réellement.
Sans ça, on se retrouve toujours avec des systèmes où il est impossible de filtrer par localité ou de s’assurer que le vendeur n’est pas un bot ou un compte jetable.
Naturellement, je me suis penché sur NOSTR pour voir si on pouvait bâtir dessus. J’ai fait le tour de la NIP-15 (pour les places de marché). Franchement ? C’est une usine à gaz. Tout pourri pour nos besoins : trop complexe, sur-optimisé pour les “Zaps” et l’écosystème Bitcoin, et surtout, ça ne résout aucun de nos problèmes fondamentaux. Aucune notion de localisation, ni de preuve d’humanité fiable des comptes. On tourne en rond.
Du coup, j’ai pris une autre direction, beaucoup plus simple et plus adaptée à notre écosystème. Plutôt que de tout réinventer, j’ai combiné quelques briques robustes :
- NOSTR pour l’Authentification (NIP-42) : Je garde NOSTR pour ce qu’il fait de mieux : l’authentification. C’est simple, c’est standard, ça marche.
- Un Moteur d’API comme “Douanier” : Le cœur du système est une API qui sert de point de passage obligé. Pour qu’un client ait le droit de lire et d’écrire des données (par exemple, poster une annonce), il doit prouver son identité via NOSTR et envoyer un message spécifique (
kind=22242) que l’API vérifie. C’est la clé qui ouvre la porte. Simple, efficace. - IPFS pour servir l’Application : Le gros avantage, c’est que l’application elle-même (l’interface de la place de marché) est un simple site statique (HTML/JS) diffusé sur IPFS. C’est léger, résilient et totalement décentralisé.
Pour un développeur, c’est un jeu d’enfant. Tu charges un seul fichier, nostr-bundle.js, et tu peux commencer à causer avec l’API ou directement avec NOSTR via des hashtags.
Le tout forme une architecture cohérente et facilement duplicable :
ipfs.ton-domaine.tldsert ton application.u.ton-domaine.tldest l’API qui contrôle les accès.wss://relay.ton-domaine.tldest ton relai NOSTR.
Cette structure facilite énormément le paiement en ligne et le développement rapide d’applis distribuées.
Pour vous donner un exemple concret, je suis en train de forker un projet pour référencer les arbres d’un quartier. C’est une “place de marché” de ressources naturelles.
Vous pouvez voir un snapshot du dev en cours :
https://ipfs.copylaradio.com/ipfs/QmYmP3P4qDhFxDqu8hPTbLaQQCuoJYKW6xFgMUKKKCP8KP
Mais là où ça devient vraiment puissant, c’est que cette architecture est pensée pour intégrer les deux briques qui manquent partout ailleurs : notre grille de clefs géographiques (les UMAPs) et la toile de confiance Ğ1 comme preuve d’humanité. On peut enfin imaginer une place de marché où tu peux chercher “des tomates dans un rayon de 1km” et être certain que les vendeurs sont des membres certifiés de la communauté.
On peut alors bâtir un consensus blockchain basé sur la géolocalisation des nœuds, et commencer à vraiment repousser les limites du Théorème de CAP.
Bref, je vous partage ça non pas comme une solution “finie”, mais comme une piste de réflexion sérieuse pour notre place de marché V2. Le code est ouvert, l’architecture est simple, et surtout, elle est conçue pour être souveraine, géolocalisée et basée sur la confiance que nous avons mis des années à construire.
Qu’en pensez-vous ?