p2p-hacker-fr : « premier état de l'art sur la décentralisation »

Cette dépêche présente un projet d'état de l'art (en français) des solutions pair-à-pair œuvrant pour un objectif de décentralisation d'Internet. Elle se base sur la démarche de la communauté anglophone « p2p-hacker » (liste de disccusion anglophone) (cf. reddit). Un tel projet est voué à contenir beaucoup plus d'informations qu'il ne peut en tenir raisonnablement en une seule dépêche, aussi considérez cette dépêche comme une présentation du projet, accompagnée d'un échantillon de l'état de l'art en question. Cet échantillon contient une présentation du projet « p2p-hacker-fr », une introduction à la décentralisation et au modèle « pair-à-pair », ainsi que les présentations de services totalement décentralisés, basés sur Bitcoin 1.0 pour la première partie, fournissant un service de stockage pour la seconde, et implémentant un protocole de routage pour la dernière.

À noter que ces présentations sont de « haut niveau », c'est-à-dire qu'elles présentent le service rendu et non pas les détails des protocoles sous-jacents, lesquels pourraient faire l'objet d'une dépêche par protocole étant donné leur richesse technique. Seuls les projets libres accompagnés d'une implémentation de référence libre sont répertoriés ici. Plus que par conviction, cette sélection permet de limiter le nombre de citations (les projets non-libres sont très nombreux) et de fournir les informations sur le code source, telle que la licence choisie ou encore le langage de programmation principal.

Remerciements : je remercie tous ceux qui ont participé à la rédaction de cette dépêche, et en particulier baud, palm123 et Sinma pour leurs corrections.

Sommaire

• Le projet p2p-hacker-fr
• Décentralisation de quoi ?
  • Internet, Web et les différentes « centralisations »
  • Qu'est-ce que le pair-à-pair ?
• Systèmes basés sur Bitcoin 1.0
  • Bitcoin
  • BitMessage
  • Namecoin
  • Twister
• Partage/Stockage distribué
  • Freenet
  • Tahoe-LAFS
  • Bitcloud
  • SyncNet
• Protocoles de routage
  • Babel
  • IPOP
  • CJDNS
• Suite de l'état de l'art

Le projet p2p-hacker-fr

Mon idée est de faire un état de l'art aussi riche que possible sur les solutions pair-à-pair et décentralisées. État de l'art qui sera distribué librement (CC by, CC by-sa ou encore CC0). Idéalement, ce projet serait collaboratif (sauf si je suis le seul que ça intéresse). Je commence aujourd'hui par une dépêche sur LinuxFr.org, car je sais que le sujet intéresse de nombreux lecteurs, mais je n'ai pas d'idée précise sur la forme, le but étant de produire de la documentation, voire des cours, libres, en français dans en premier temps, et éditables (un format Wiki, voire directement travailler avec Wikipédia serait peut-être adapté).

Je suis super ouvert à toutes les suggestions potentielles sur ce projet, je l'ai initié car le résultat m'intéresse (j'ai découvert plein de choses sympas en le faisant), mais je n'ai aucune prétention de paternité.

Pour le moment, j'ai créé un petit dépôt github pour sauvegarder le source de la dépêche et sûrement commencer à élaborer un nouveau mode de rédaction (j'imagine par exemple des sections par type de solution, des outils pour la conversion markdown, etc.). La tribune de rédaction de LinuxFr.org étant un excellent outil, mais ne fournissant pas toutes les fonctionnalités dont on aura besoin (archivage/historisation dans un espace dédié, modification après publication, etc.).

Si l'aventure vous tente, vous pouvez me contacter par courriel, vous enregistrer sur le github ou encore venir rédiger les prochaines dépêches (s'il y en a) sur la tribune de rédaction de LinuxFr.org.

Décentralisation de quoi ?

Dans ce premier chapitre, je vais essayer de clarifier certains concepts clés (en expliquant comment je les comprends), comme la « décentralisation » et le domaine « pair-à-pair ».

Internet, Web et les différentes « centralisations »

Tout d'abord, c'est bien beau de parler de « décentralisation », mais constatons d'abord ce que l'on appelle « centralisation ». Voici une liste incomplète des inconvénients que l'on attribue généralement à « la centralisation » :

• la centralisation économique : soit la centralisation des infrastructures d'Internet autour du modèle « datacenter ». En effet, même si l'infrastructure des réseaux est par nature décentralisée, les services disponibles sur Internet sont en majorité fournis par des ressources de calcul et de stockage qui sont concentrées dans les « datacenters ». La raison de cette centralisation est économique (mutualisation du refroidissement et de la distribution d'électricité), cependant une infrastructure décentralisée présente aussi des avantages, techniques et économiques (notamment l'utilisation des ressources existantes et sous-exploitées). Sur ce thème, j'invite les anglophones à lire l'excellent article « On Delivering Embarrassingly Distributed Cloud Services ».
• la centralisation administrative et politique : soit la centralisation des services Web autour d'un petit nombre de prestataires (services Google, Facebook, Twitter, etc.). Ce qui pose les problèmes d'enfermement propriétaire, de censure, et de protection de la vie privée lorsqu'il s'agit du stockage de données, des systèmes de communication, ou plus généralement de la maîtrise des informations que l'on diffuse via Internet.
• la centralisation technique : soit la présence de points de centralisation dans certains protocoles (serveurs DNS primaires, serveurs d'authentification, serveurs HTTP, etc.), qui peut poser des problèmes de contention sur le réseau ou tout simplement fragiliser un service, l'attaque par déni de service étant le plus connu des exemples.

Qu'est-ce que le pair-à-pair ?

On entend beaucoup parler de « protocoles pair-à-pair », « services pair-à-pair » ou encore « partage pair-à-pair », sans forcément avoir une image claire de ce à quoi cet adjectif « pair-à-pair » se rapporte. Je vous propose la définition que je préfère, compilée à partir de plusieurs cours de référence dans le domaine :

L'adjectif « pair-à-pair » qualifie un modèle d'architecture de système distribué. Il est né en opposition au modèle traditionnel « client/serveur », traduisant l'idée qu'un système distribué peut être constitué de « pairs », dont aucun n'a de rôle particulier. Chaque machine, généralement appelée « pair » ou « nœud », joue à la fois les rôles de client et de serveur.

D’après la synthèse proposée par Rodrigues et Druschel en 2010 les systèmes pair-à-pair sont des systèmes distribués qui présentent les propriétés suivantes :

• Haut degré de décentralisation : les pairs prennent le rôle de client et de serveur,
  et la majeure partie de l’état du système et des tâches sont dynamiquement distribués
  parmi les pairs. Il existe peu de nœuds, voire aucun, possédant un état centralisé.
  L’ensemble des besoins de calcul, de stockage et de communication liés à l’exécution du
  système est alors fourni de façon collaborative par les membres du système pair-à-pair.

• Organisation automatique :
  une fois qu’un nœud est introduit au sein du système
  (typiquement en lui fournissant l’adresse IP d’un des membres), aucune configuration
  manuelle n’est nécessaire pour maintenir l’exécution du système pair-à-pair.

• Entités administratives multiples :
  les nœuds participant au système pair-à-pair
  dépendent rarement d’une seule entité administrative. Dans la plupart des cas, chaque
  nœud appartient à un contributeur particulier souhaitant participer à la vie du système.

• Faible coût de déploiement :
  n’utilisant pas — ou peu — d’infrastructure dédiée, le coût de déploiement initial d’un service pair-à-pair est généralement faible en comparaison du coût de déploiement des services utilisant une architecture de type client/serveur.

• Croissance organique :
  étant donné que la majeure partie des ressources exécutant
  le système est fournie par les pairs, c’est-à-dire les clients du service, la croissance d’un système pair-à-pair ne nécessite pas de mises à jour franches de l’infrastructure hôte, par exemple le remplacement d’un serveur par un matériel plus puissant.

• Robustesse aux pannes et aux attaques :
  les systèmes pair-à-pair sont généralement résistants aux pannes, car il existe peu — ou pas — de nœud dont la présence est critique pour l’exécution du service associé. Pour attaquer ou rendre inaccessible un système pair-à-pair, un tiers malveillant doit prendre pour cible une grande partie des nœuds du système simultanément.

• Abondance et hétérogénéité des ressources :
  les systèmes pair-à-pair les plus
  populaires rassemblent une quantité de ressources informatiques que peu d’entreprises
  peuvent prétendre acquérir individuellement. Les ressources sont hétérogènes en terme
  d’architecture matérielle et logicielle, de méthode d’accès à Internet, ou encore de situation géographique. Cette diversité contribue à réduire les pannes, les attaques et même la censure rencontrée dans ce type de système distribué.

• Le churn : le terme « churn » désigne la dynamique des environnements pair-à-pair, il caractérise l’arrivée et le départ continu d’une partie des membres du réseau au sein du système. On assimile généralement le départ d’un noeud à une panne et on considère qu’un noeud est en panne lorsqu’il cesse de communiquer avec le reste du système pendant une période prédéfinie, laquelle varie en fonction des besoins du système. Aussi, on ne sait pas quand un noeud décidera de quitter le réseau et on ne peut pas contraindre un pair à rester connecté au système contre sa volonté. En conséquence, un environnement pair-à-pair est un réseau composé d’un nombre de noeuds potentiellement grand, dont on ne maîtrise ni le comportement, ni la disponibilité.

Pour conclure, le « modèle pair-à-pair » permet d'architecturer un système, un service distribué, avec une optique de décentralisation. Cette décentralisation peut être partielle (présence d'un serveur centralisé), importante (présence de nœuds particuliers, par exemple des « trackers ») ou totale (absence de tout point de centralisation).

Systèmes basés sur Bitcoin 1.0

Les systèmes basés sur la crypto-monnaie Bitcoin ont la cote (notez la touche d'humour). Plus sérieusement, la base solide du code de Bitcoin a permis le développement de plusieurs projets sérieux et populaires. À noter qu'il existe de très nombreux projets autours des crypto-devises, qui ne seront pas cités ici, par souci de concision.

Bitcoin

• Site web du projet : bitcoin.org/
• Année de déploiement : 2009
• Implémentation de référence : github.com/bitcoin/bitcoin (C++) (MIT)

Il est difficile de faire mieux que le journal de Gof pour décrire Bitcoin :

Le but de Bitcoin est d'être une monnaie et un moyen de paiement sur Internet, décentralisé, hors du contrôle des gouvernements, des banques ou d'une seule société.

Le mot « Bitcoin » fait référence au protocole décrivant cette monnaie virtuelle ainsi qu'à son implémentation de référence. C'est aussi le nom de l'unité de cette monnaie.

Bitcoin est décentralisé. Quiconque le souhaite peut devenir un nœud du réseau, en installant le logiciel.

Je rajoute : le protocole Bitcoin est suffisamment modulaire pour servir de base à de nombreux autres projets.

BitMessage

• Site web du projet : https://bitmessage.org/wiki/Main_Page
• Année de déploiement : 2012
• Implémentation de référence : github.com/Bitmessage/PyBitmessage (Python) (MIT)

Bitmessage est un protocole pair-à-pair de communication, basé sur la crypto-devise « Bitcoin », et utilisé pour envoyer des messages chiffrés à une personne ciblée ou à un groupe d'abonnés. Ce protocole est décentralisé et ne demande aucune confiance dans une entité centralisée particulière, telle qu'une autorité de certification. Il utilise une authentification forte, ce qui signifie que l'identité de l'auteur d'un message ne peut théoriquement pas être usurpée. Bitmessage a pour objectif de cacher toutes les méta-données, telles que l'identité de l'auteur et du (ou des) destinataire(s), d'un espionnage potentiel de type « écoute téléphonique ».

Pour les détails techniques, il y a le journal de julmx (et les commentaires associés), ainsi que l'article de Stéphane Bortzmeyer, qui étudie notamment le protocole d'un point de vue écologique :)

Source supplémentaire : ce comparatif positionne de façon intéressante BitMessage par rapport aux autres logiciels de messagerie.

À noter l'existence d'un projet dérivé : BitGroup, qui a pour objectif de construire un réseau social au-dessus de BitMessage.

Namecoin

• Site web du projet : namecoin.info/
• Année de déploiement : 2011
• Implémentation de référence : https://github.com/namecoin/namecoin/tree/vQ.3.72 (C++/Qt) (MIT)

Namecoin est un service décentralisé et libre de transfert et d'enregistrement de type clef/valeur, basé sur la technologie Bitcoin. Il permet notamment d'enregistrer et de transférer des noms arbitraires (clefs), et d'associer des données (valeurs) à ces noms (520 octets pour le moment), le tout à l'abri de la censure. Les actions (enregistrement, transferts) se font grâce à une monnaie internationale propre au système : le « NMC ».

Pour approfondir Namecoin, il y a le journal de Khalahan et l'article de Stéphane Bortzmeyer, qui sont de bonnes ressources.

Twister

• Site web du projet : twister.net.co/
• Année de déploiement : 2013
• Implémentation : github.com/miguelfreitas/twister-core (C++) (MIT/BSD)

Twister est un service totalement décentralisé de « microblogging », qui met en avant les trois points suivants :

• Liberté d'expression : la nature décentralisée de Twister empêche la censure. De fait, il est impossible d'effacer un billet, de censurer son contenu, ou encore de désactiver le compte d'un utilisateur.

• Pas d'espionnage : les données et méta-données (identifiants auteur/destinataire) des communications privées sont protégées par le protocole, notamment en utilisant des méthodes de cryptographie.

• Préservation de l'anonymat : l'adresse IP utilisée pour communiquer via Twister n'est enregistrée par aucun serveur. Dans son utilisation normale (si vous n'êtes pas espionné), votre présence sur le réseau n'est pas surveillée.

Pour approfondir sur Twister il y a le journal de fredix (promu en dépêche), et aussi un billet de Stéphane Bortzmeyer.

Partage/Stockage distribué

Ce chapitre présente des services décentralisés axés autour du partage de contenu et du stockage de fichiers.

Freenet

• Site web du projet : freenetproject.org/
• Année de déploiement : 2000
• Implémentation de référence : github.com/freenet/ (Java) (GPL)

Freenet est un réseau pair-à-pair qui a vu le jour dans le cours de l'année 2000 et qui a été suivi par de (très) nombreuses entrées sur LinuxFr.org. Le service proposé est un « Internet dans l'Internet », qui fournit principalement du partage de contenu (fichiers et/ou sites web appelés « freesites ») et de la messagerie (type mail). L'hébergement des contenus est anonymisé, chiffré et distribué entre les pairs. Il en résulte une quasi-impossibilité de censurer les contenus, caractéristique du réseau Freenet. Son réseau est de type « Darknet » ou encore « smallworld », c'est-à-dire que la connexion entre les pairs est établie au cas par cas, selon un réseau de pairs de confiance, ou « amis » pour reprendre le terme des réseaux sociaux. La topologie résultante est donc « non structurée ».

Tahoe-LAFS

• Site web du projet : tahoe-lafs.org
• Année de déploiement : 2008
• Code source : github.com/tahoe-lafs/tahoe-lafs (Python) (GPL/TGPPL)

Tahoe-Least-Authority Filesystem (Tahoe-lafs) est un système de fichiers distribué « dans le Cloud ». Il sait distribuer les fichiers sur diverses topologies composées de serveurs potentiellement hétérogènes. Si un ou plusieurs de ces serveurs tombe en panne ou est compromis par une attaque, le système de fichiers continue de fonctionner correctement, tout en préservant l'intégrité, la sécurité et la confidentialité des fichiers de l'utilisateur.

Tahoe-LAFS est la première technologie de stockage basée sur des logiciels libres à proposer un stockage distribué dont la sécurité est indépendante des hébergeurs de données. Une sécurité indépendante des hébergeurs signifie que l'intégrité et la confidentialité de vos fichiers est garantie grâce à des opérations mathématiques (cryptographie, code de correction, etc.), qui sont calculées côté client et donc indépendamment des serveurs d'hébergement, lesquels sont potentiellement fournis par des tiers.

Pour avoir une idée de l'utilisation de Tahoe-LAFS, les cas d'usage suivant sont répertoriés :

Bitcloud

• Site web du projet : http://bitcloudproject.org
• Année de déploiement : 2014
• Implémentation de référence : github.com/wetube/bitcloud (C) (MIT)

Bitcloud est un service de stockage décentralisé et de « tenue de compte séquestre », qui permet à des clients appelés « éditeurs » de payer des nœuds volontaires pour y stocker et partager des données chiffrées. La nature décentralisée de Bitcloud permet à n'importe quel utilisateur de publier du contenu en tirant profit des infrastructures populaires (machines des utilisateurs et bénévoles) et sans utiliser de logiciel « propriétaire », le tout en étant protégé de la censure. L'idée du projet Bitcloud est de fournir les fondations technologiques pour des applications décentralisées basées sur les crypto-devises, et qui mettent en place des mécanismes « d'incitations économiques » (« economic incentives » étant un terme que je n'ai jamais réussi à traduire), notamment avec des transactions via des comptes séquestres et des services contractuels.

Un scénario pour illustrer le principe de Bitcloud (source) : un éditeur choisit le nœud ou groupe de nœuds qui propose le service de stockage qui lui paraît le mieux adapté à ses besoins. En utilisant un client Bitcloud, cet éditeur pourra consulter toutes les offres proposées par les nœuds du réseau Bitcloud, ainsi que leur prix et la réputation des nœuds en question. Disons que notre éditeur a trouvé un groupe de nœuds proposant l'hébergement de 500 Go de données pour une somme de 10 mBTC (la crypto-devise du système Bitcloud) par mois. L'éditeur va envoyer un paiement de 10 mBTC à ce groupe de nœuds par l'intermédiaire du réseau Bitcloud. Le paiement sera alors placé sur un « compte séquestre » et lié à un contrat de service, en utilisant le réseau Bitcloud comme médiateur. Ce médiateur décentralisé va notamment s'assurer que le groupe de nœuds fournit bien le service stipulé par le contrat. Une fois le mois écoulé, le réseau Bitcloud valide le paiement pour le groupe de nœuds.

À noter qu'il existe le concept de grille de nœuds, qui regroupe plusieurs nœuds par affinité sociale ou économique et organise ce groupe pour fournir un service collaboratif, lequel se matérialise par une offre commune sur le marché Bitcloud. La grille organise aussi la répartition des gains, le tout en utilisant des mécanismes de consensus distribué.

Pour finir, l'application de référence construite au dessus de Bitcloud est WeTube. Cette application vise à concurrencer YouTube, mais son développement ne semble pas encore avoir commencé (Bitcloud semble être un projet très jeune, démarré début 2014).

SyncNet

• Site web du projet : jack.minardi.org/software/syncnet-a-decentralized-web-browser/
• Année de déploiement : 2013/2014
• Implémentation de référence : github.com/jminardi/syncnet (Python) (MIT)

SyncNet est un navigateur expérimental basé sur BitTorrent Sync et (bientôt) Colored Coins. Le principe est le suivant : à chaque fois que vous accédez à un site Web, vous stockez le contenu associé sur votre machine. Le prochain utilisateur à demander l'affichage de ce site peut obtenir le contenu du site depuis deux sources : votre machine et le serveur d'origine. Par conséquent, plus il y a de personnes accédant à une page donnée, plus le nombre de machines proposant son contenu augmente, ce qui réduit la charge du serveur d'origine.

Protocoles de routage

Bien que méconnus, les protocoles listés dans cette section permettent de créer des réseaux autonomes, décentralisés et souvent sécurisés, en reposant totalement, partiellement ou nullement sur l'infrastructure d'Internet.

Babel

• Site web du projet : www.pps.univ-paris-diderot.fr/~jch/software/babel/
• Année de déploiement : 2007
• Code source : git.wifi.pps.univ-paris-diderot.fr/babeld (C) (MIT)

Babel est un protocole de routage IP qui est conçu pour être fiable et efficace sur des réseaux filaires (disons quelques liaisons Ethernet connectées) et sur les réseaux sans-fil. Babel est particulièrement intéressant pour construire des réseaux hybrides, c'est-à-dire des réseaux composés de connexions filaires et de connexions sans-fil.

Nous passerons sur la description technique du protocole (voir cette présentation pour ceux que ça intéresse), et nous nous contenterons dans cette dépêche de citer les principales fonctionnalités :

• Le protocole est robuste et efficace aussi bien pour des réseaux maillés (« mesh networks »), que pour des réseaux filaires structurés.
• Babel gère les réseaux virtuels (« overlay networks »).
• Babel gère les réseaux double couche (IPv4 et IPv6).
• L'implémentation de Babel est petite et adaptée aux systèmes embarqués (Raspi :))

En gros, Babel permet de mettre en place des réseaux ad hoc locaux et étendus en incluant un mélange hétérogène de machines, connectées via Ethernet et/ou via Wifi.

Évidemment les plus optimistes penseront que Babel permet de se passer de FAI, à ceux-là je dis : « Tout doux Bijou ! Il faut les payer les gros tuyaux qui débitent du TeraOctet par seconde ! Sinon YouPrOn c'est fini ! ». Mais ceci est un autre problème.

IPOP

• Site web du projet : ipop-project.org/
• Année de déploiement : 2013
• Implémentation de référence : github.com/ipop-project (C++/Python) (MIT)

IPOP (IP-over-P2P) est un réseau virtuel (logiciel) libre, centré utilisateur, qui permet à ses membres de créer leurs propres réseaux virtuels privés (VPN). Les réseaux virtuels d'IPOP proposent des tunnels IP via la mise en place de liens particuliers appelés « TinCan », lesquels peuvent être organisés par des « contrôleurs » pour créer des réseaux virtuels privés de types variés comme les « GroupVPN » ou les « SocialVPN ». Dans un réseau de type « GroupVPN », les machines du réseau virtuel sont toutes interconnectées (comme dans un LAN), tandis que dans un « SocialVPN » les liens sont construits un à un, par paire d'utilisateurs, en se reposant sur le protocole XMPP. Finalement, les réseaux virtuels privés créés avec IPOP prennent en compte les applications qui utilisent nativement les protocoles TCP/IP (comme un VPN classique, je dirais).

Dans les principaux cas d'utilisation on retrouve :

• Cloud computing : IPOP réunit des machines virtuelles provenant de divers hébergeurs dans un GroupVPN, ce qui fournit une grappe virtuelle privée de machines, qui peut faire tourner des plate-formes, applications et services non modifiés.

• Informatique nomade : IPOP peut interconnecter des mobiles Android avec des machines accessibles via Internet (éventuellement en traversant des NAT), pour partager des fichiers ou éventuellement utiliser leur puissance de calcul pour décharger celle du mobile.

• Réseautage social : grâce aux SocialVPN, IPOP peut connecter les mobiles, serveurs virtuels et toute autre type de machine connectée au sein d'un « réseau social ». Ce réseau permet de communiquer directement et de façon privée, avec ses « amis », mais aussi d'échanger des données, diffuser des média en flux, jouer à des jeux vidéos en réseau et probablement bien d'autres choses.

CJDNS

• Site web du projet : cjdns.info
• Année de déploiement : 2011/2012
• Implémentation de référence : github.com/cjdelisle/cjdns/ (C) (GPL)

CJDNS, comme son nom ne l'indique pas, est un système décentralisé qui implémente un réseau IPv6 chiffré, en utilisant la cryptographie asymétrique pour allouer les adresses, et une table de hachage distribuée (DHT) pour le routage. Cela permet une configuration du réseau quasi-nulle et protège le réseau de nombreux problèmes de sécurité et de passage à l'échelle (« scalabilité »), qui caractérisent les réseaux existants.

Cjdns garantit la confidentialité, l'authenticité et l'intégrité des données qui transitent sur le réseau, en utilisant une cryptographie moderne et non-intrusive. Ainsi, les informations transmises sur un réseau cjdns ne peuvent pas être altérées ou lues pendant leur transit entre l'émetteur et le destinataire. Certes, on peut créer plusieurs identités (cf. « Sybil attack »), mais il est impossible d'usurper l'identité des autres nœuds étant donné que leur adresse IPv6 est une empreinte de leur clé, rendant impossible les attaques de type « homme du milieu »).

Les réseaux traditionnels requièrent une configuration manuelle des adresses IP (sans parler des procédures administratives pour l'obtention d'une plage d'adresses). Les nœuds du réseau Cjdns génèrent leurs propres adresses en utilisant leurs clés, lorsque deux nœuds se rencontrent ils se connectent. Lorsque beaucoup de nœuds se rencontrent les uns les autres, ils forment un réseau. Une architecture globale du réseau est bien entendue nécessaire pour éviter les problèmes de contention, mais lorsqu'un nœud a trouvé sa place dans le réseau, il découvre automatiquement son rôle dans le protocole de routage. Sans rentrer dans le détail, Cjdns utilise une table de hachage distribuée (DHT) pour structurer le réseau et router les communications.

Cjdns est actuellement déployé dans le cadre du projet Meshnet, dont le but est de fournir un réseau alternatif à Internet 1.0, en tirant partie des infrastructures populaires. Le plus grand réseau de ce projet est hyperboria.

Suite de l'état de l'art

Cet état de l'art pourrait continuer sous forme de nouvelles dépêches sur LinuxFr.org, mon expérience ayant été agréable grâce à l'utilisation du format Markdown et surtout grâce au soutien des relecteurs (merci encore). Je pense détailler de façon plus technique certains protocoles, faire un peu de théorie (DHT, protocoles épidémiques, théories économique autour des protocoles pair-à-pair, sécurité, etc.). Aussi n'hésitez pas à vous manifester si certains sujets vous intéressent (cela pourrait me motiver à les traiter en priorité). Et encore une fois, toute collaboration est la bienvenue :)

Aller plus loin

• Abonnement à la liste p2p-hackers (97 clics)
• Reddit de l'Internet décentralisé (131 clics)
• p2p hacker francophone (585 clics)