Connexion
Depuis ce printemps, sachez qu'un git clone ordinaire peut maintenant récupérer un dépôt qui n'existe sur aucun serveur spécifique. En fait, le code est stocké dans Freenet, le réseau pair-à-pair qu'Ian Clarke a relancé en mars. Et comme y'a plus d'hébergeur, bah y'a plus personne pour fermer un compte ou shooter le dépôt.
Car Git est décentralisé depuis toujours et fonctionne très bien comme ça, puisque chaque clone contient l'historique complet, ce qui permet à 2 clones de se synchroniser directement. Ce qui lui manquait par contre, c'était l'hébergement, et c'est là-dessus que les forges que nous connaissons, Github en tête, sont venues capitaliser. Y'a bien des initiatives comme
Grasp qui essaie d'en sortir grâce au protocole Nostr
mais
freenet-git
lui range carrément le dépôt dans un contrat que les nœuds recopient, et se publie lui-même à l'adresse freenet::99TmCayXn6Tm/freenet-git.
Cloner ou publier du code exige donc le paquet freenet-git et un nœud qui tourne sur votre machine, ce qui fait qu'on ne supprime pas vraiment le serveur, mais on le ramène juste chez soi.
Le socle compte plus que l'application dans cette présentation. Les contrats et les delegates forment la couche où une app tourne sans backend, et quatre tournent déjà dessus : River pour le chat de groupe, Delta pour les sites, Atlas pour la recherche, et freenet-git pour le code. Mail, Raven et Harvest existent aussi, à un stade plus jeune.
L'adresse du dépôt sort des 12 premiers caractères de la clé publique de son propriétaire, et à ce stade expérimental, lui seul peut pousser dedans. Y'a pas non plus de pull requests, ni d'issues puisque c'est le modèle du noyau Linux d'avant les forges, où chacun publie son clone et le mainteneur vient y piocher ce qui l'intéresse.
Reste le plus dur maintenant, retrouver un dépôt.
Car sans annuaire, un nœud doit deviner lequel de ses voisins mettra le moins de temps à trouver ce qu'on lui demande. Le réseau traite ça comme un problème d'apprentissage et parie sur le bon voisin à partir des requêtes passées grâce à Renegade, une bibliothèque open source sortie en 2021, capable de faire ce calcul.
Il faut une chaîne Rust, et ~/.cargo/bin doit être dans votre PATH. Les installeurs du nœud sont sur freenet.org/quickstart.
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Rust n'entre dans le PATH qu'au shell suivant, donc ouvrez un nouveau terminal avant la commande d'après. Elle dépose deux binaires, freenet-git et le remote helper que Git appellera tout seul.
cargo install freenet-git
Aucune identité n'est nécessaire pour lire. La bibliothèque standard de Freenet fait un bon test, elle porte son historique complet et ses tags.
git clone freenet::96rknpy1GYhZ/freenet-stdlib
C'est create qui publie réellement le contrat. Il affiche PUT confirmed by host et l'adresse du dépôt, dont le préfixe se recopie dans le remote. La phrase de passe voyage par une variable d'environnement parce que Git garde la main sur l'entrée standard durant le push.
freenet-git init-identity --name "Votre Nom" --email vous@example.com
cd ~/code/mon-projet
freenet-git create --name mon-projet
# -> URL: freenet:VOTRE_PREFIXE/mon-projet
git remote add freenet freenet::VOTRE_PREFIXE/mon-projet
export FREENET_GIT_PASSPHRASE='votre-phrase-de-passe'
git push freenet main
Et voilà ! Avec ça vous pouvez faire du vrai git décentralisé même si la vraie limite est ailleurs...
En effet, les nœuds gardent en cache ce qu'on leur réclame et évacuent le reste, donc un dépôt que personne ne clone finit au bout d'un moment par ne plus être clonable. Et ça c'est dommage... C'est pourquoi une commande (rescue), le remet en circulation depuis une machine qui a encore les données. Le projet ne présente toutefois pas ça comme un bug, mais comme son modèle de durabilité actuel.
Mais autant le savoir avant d'y déposer votre code.
eMule ? Sérieusement ?
Hé bien oui les amis, le célèbre mulet du P2P n'est pas encore mort de sa belle mort et en ce moment y'a un petit revival de cette bestiole du début des années 2000. C'est logique car les abonnements de streaming se fragmentent de plus en plus et coûtent un bras, les forums de torrents ferment les uns derrière les autres, alors c'est tout naturellement que certains dinosaures du partage de fichiers s'offrent un petit lifting.
Prenez aMule , le célèbre clone multiplateforme d'eMule. Hé bien le projet vient de sortir en version 3.0.0 après 5 ans de silence radio. Et c'est pas une petite mise à jour esthétique puisque les développeurs ont réécrit entre autres toute la gestion des entrées/sorties sur le disque pour sortir ça du thread principal. Résultat, sur un Mac Studio Apple Silicon, le débit de téléchargement P2P explose !
Côté Windows, le client d'origine bouge encore lui aussi, puisque la communauté maintient le navire avec des versions comme eMule 0.70b Community et prépare la suite avec la bêta 0.72a. Ces moutures corrigent la compatibilité avec Windows 11, intègrent TLS 1.3 pour l'interface d'administration et supportent l'architecture ARM64. J'ai testé, ça trace mais la vraie nouveauté qui va vous plaire les fans d'eMule, c'est Mularr .
Ce projet open-source qui s'installe via Docker permet de "supercharger" le mulet. Ça permet d'avoir une interface web responsive au look nostalgique très Windows XP (ou Windows 11 pour les p'tits jeunes), tout en proposant des APIs compatibles qBittorrent et des indexeurs Torznab. Du coup, vous pouvez connecter l'âne directement à vos outils d'automatisation comme Sonarr ou Radarr. Il gère même les notifications de fin de téléchargement via Telegram et s'intègre avec le VPN Gluetun. C'est la classe à Arras comme disent les ch'ti.
Je sens que j'ai touché votre corde sensible avec tout ça. Je vous rassure, à moi aussi parce j'ai commencé ce blog justement parce que j'étais à fond dans le milieu du P2P à l'époque.
Alors si vous voulez relancer la machine (les nostalgiques apprécieront également macMule ), quelques règles de sécurité s'imposent.
Tout d'abord, les listes de serveurs par défaut sont souvent blindées de mouchards et de faux serveurs malveillants qui vous balancent des contenus bourrés de virus. Pensez donc à nettoyer tout ça et à récupérer un fichier de serveurs server.met propre chez
emule-security.org
ou
peerates.net
. Activez aussi Kademlia, le fameux réseau décentralisé Kad, pour vous passer de serveurs centralisés. Ah et puis gaffe à Hadopi hein...
lol, ça va, j'rigole !
Et même après tout ce temps, la règle d'or reste la même : ne lancez jamais un fichier suspect de 700 Mo qui prétend être un film mais se termine par une extension d'exécutable genre un bon vieux .exe ou .scr, hein ^^. Pensez aussi à configurer un IP filter (comme celui d'emule-security ) pour bloquer les serveurs hostiles et tout ira bien.
Voilà, si vous cherchiez des fichiers rares introuvables sur Torrent, c'est le moment de relancer l'âne car au pire, vous choperez de vieux fichiers nostalgiques et au mieux, vous monterez une Seedbox de l'espace.
Amusez-vous bien et bon courage avec votre Low-ID ^^.
Cult of the Dead Cow , un des plus vieux collectifs hacktivistes encore en activité, ne se contente pas que de balancer des manifestes politiques depuis 1984. Ils codent. Et leur dernier bébé en date s'appelle Veilid , et c'est un framework P2P qui veut faire à vos apps ce que Tor a fait à votre navigateur.
Histoire de vous expliquer, vous prenez Veilid, vous l'intégrez dans votre app mobile ou web, et d'un coup tout votre trafic passe par un réseau pair-à-pair (P2P) chiffré de bout en bout. Cela veut dire qu'il n'y a pas de serveur central qui stocke vos messages.
Concernant votre IP, celle-ci n'apparaît alors plus au niveau applicatif (le routage privé l'obfusque entre pairs), et chaque nœud est identifié par une clé publique Ed25519 256-bit. Donc autant dire un truc carrément impossible à brute-force.
Le projet a été annoncé à DEF CON 31 en août 2023 par Christien "DilDog" Rioux et Katelyn "Medus4" Bowden, 2 membres historiques de cDc, et près de trois ans plus tard, ça continue d'évoluer toujours à un rythme régulier.
L'idée technique vous la connaissez si vous avez déjà touché à du décentralisé : Une table de hachage distribuée (DHT, en fait un annuaire éclaté entre tous les nœuds du réseau) gère le routage, chaque nœud relaie du trafic chiffré qu'il ne peut pas lire, et les pairs s'échangent des données sans jamais révéler leur IP.
Perso, c'est l'approche qui me semble vachement plus saine pour faire du social sans Mark Zuckerberg dans la boucle. C'est dans le même esprit que Tor et qu' IPFS , sauf que Veilid est pensé dès le départ pour les développeurs d'applications. Donc c'est pas fait pour anonymiser de la navigation web ou stocker des fichiers. C'est un Tor des applications si vous préférez...
Le framework est codé en Rust avec des bindings Flutter et Dart pour le mobile ainsi qu'une cible WebAssembly pour le navigateur. Vous pouvez donc carrément déployer une app Veilid sur Linux, macOS, Windows, Android, iOS, et même directement dans Chrome ou Firefox via WASM.
Le code, lui, est découpé en plusieurs composants : veilid-core pour le moteur, veilid-tools pour les utilitaires, veilid-flutter pour le mobile, veilid-wasm pour le navigateur et veilid-server qu'on installe sur un VPS Debian ou Fedora pour faire tourner un nœud public. Voilà, et le tout est sous licence Mozilla Public License 2.0, donc copyleft mais compatible si vous y ajoutez du code propriétaire par dessus.
L'app phare qui tourne déjà sur ce framework, c'est VeilidChat , une messagerie type Signal mais sans aucun serveur, sans numéro de téléphone et sans annuaire centralisé. Vous échangez votre clé publique avec un pote, et hop, c'est parti.
Si ça vous dit d'y jeter un oeil, sachez que le code de Veilid n'est pas sur GitHub mais sur GitLab . Après c'est encore assez nouveau, ce qui veut dire que ça bouge beaucoup de release en release. Donc si vous voulez coder votre prochaine app par dessus ce framework, va falloir vous accrocher car ça cassera souvent.
Mais si vous codez du décentralisé et que vous en avez franchement marre de bricoler libp2p à coup de colle forte Python, Veilid mérite un sérieux coup d'œil. Et même si vous codez pas, gardez l'œil sur VeilidChat car le jour où une appli grand public sortira là-dessus, ça va vraiment envoyer du lourd.
Beaucoup plus que Signal ou Telegram, je pense !
Utiliser une conversation WhatsApp pour partager un mot de passe à un pote, c'est un peu comme écrire son code de carte bleue au marker dans des chiottes publics. Sauf que les messages, eux, restent des années dans l'historique car y'a personne qui viendra nettoyer ça. Heureusement, Nullroom vient régler ce genre de bricole en mode radical, avec un chat P2P chiffré qui s'autodétruit au bout d'un quart d'heure, sans avoir à vous créer de compte et sans laisser de trace côté serveur.
Alors comment ça fonctionne ? Hé bien vous cliquez sur "CREATE SECURE ROOM", un lien apparaît, vous le balancez à votre correspondant par le canal de votre choix (Signal, SMS, pigeon voyageur...etc), et hop, une session chiffrée s'ouvre entre vos deux navigateurs. Vous pouvez alors discuter, échanger éventuellement des fichier (jusqu'à 16 Mo max en beta), et après 15 minutes, la room s'évaporera. Purement et simplement et aucun serveur n'aura vu passer vos échanges (mis à par quelques bouts de métadonnées pour établir la connexion).
Sous le capot, y'a un truc crypto assez chouette qui est une clé de chiffrement AES-GCM 256 bits, générée côté client via l'API Web Crypto du navigateur, qui vit dans le fragment de l'URL (c'est la partie qui vient après le #). Et comme les navigateurs n'envoient JAMAIS ce fragment au serveur, vu que c'est un standard HTTP, vous êtes tranquille.
Et voilà comment votre clé de session n'existe que chez vous et chez votre correspondant. Le serveur de Nullroom ne la voit pas, même pas une microseconde. C'est le même trick que celui qu'utilise PrivateBin pour les snippets chiffrés, mais appliqué à du chat en direct.
Le flux de données, lui, passe en direct d'un navigateur à l'autre via WebRTC et le serveur ne sert comme je vous le disais plus haut, qu'à la poignée de main initiale.
Ensuite, les messages et les fichiers circulent en peer-to-peer, relayés via les serveurs TURN de Cloudflare quand votre NAT coince. Donc au pire, Cloudflare voit passer du trafic 100% chiffré, et pas le contenu en clair. Les logs serveur sont également désactivés sur les chemins des rooms, et les UUIDs de sessions vivent dans un Redis totalement volatile qui est nettoyé au bout de ces fameuses 15 minutes.
Niveau limites, une room c'est deux personnes max donc si vous cherchiez un remplaçant à Signal ou à Briar, ce n'est pas le bon outil. C'est juste une messagerie pour un échange ponctuel entre 2 personnes.
Et l'équipe ou l'entreprise derrière n'est pas affichée côté site (pas de mentions légales, pas de juridiction précisée), donc attention ! Ça reste du "faites-vous votre opinion" mais comme le code est open source (licence MIT) sur GitHub vous pouvez quand même l'analyser et monter votre propre infra Nullroom.
Pour le quotidien, c'est un service qui est bien foutu, que ce soit pour un mot de passe à filer à un collègue en télétravail, un lien temporaire à partager pendant une réu, une confidence à un pote qui n'a rien à faire dans les archives iMessage, ou encore un numéro de compte à transmettre vite fait avant que l'autre ne parte en vacances... Tous ces cas d'usage existent et la friction est quasi nulle donc c'est plutôt une bonne approche je trouve.
Voilà, si vous voulez tester le concept d'une conversation qui n'aura jamais eu lieu, filez sur nullroom.io.
