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

55
5
mar.
2014
Internet

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

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

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

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

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

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

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

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 :
use case table

Bitcloud

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

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

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

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

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 :)

  • # Tox

    Posté par (page perso) . Évalué à 10.

    Merci pour cette dépêche très intéressante, on attend la suite avec impatience !

    Je me permettrais une petite suggestion d’ajout : la bibliothèque de messagerie instantanée Tox, et les clients qui l’utilisent.

    • [^] # Re: Tox

      Posté par (page perso) . Évalué à 9.

      Merci pour la piste, je n'en avais jamais entendu parler, malgré la popularité que le github du projet laisse deviner.

      Au passage, je commence une todolist à laquelle j'ajoute les suggestions données en commentaire.

      Je vais regarder Tox, merci !

  • # GNUNet

    Posté par . Évalué à 2.

    La décentralisation est effectivement un sujet chaud dernièrement.
    Peut-être GNUNet est-il également une piste à explorer ?

    • [^] # Re: GNUNet

      Posté par (page perso) . Évalué à 5.

      Tout à fait, on ne peut pas parler de pair-à-pair sans GNUNet. Je connais, c'est un vieux projet pour du P2P, mais effectivement il est toujours actif et ça serait intéressant de faire une passe dessus.

      Il n’apparaît pas dans ce premier état de l'art car je le considère comme une brique technologique plus que comme un service. Mais c'est sûr qu'il faudra en parler un jours :)

      Je rajoute à la todolist, merci !

  • # Partage

    Posté par (page perso) . Évalué à 2.

    Bonjour,

    Je suis surpris de voir assez peu de référence au partage de fichiers par p2p comme le protocole .torrent ou .p2p dans la section "Partage/Stockage distribué".

    Je te dirigerai aussi vers "SyncNet, navigateur peer-to-peer" sur lequel un article est paru. Un projet en développement intéressant.

    Cordialement,

    • [^] # Re: Partage

      Posté par (page perso) . Évalué à 3.

      SyncNet est dans la section « partage », mais j'ai zappé l'article LinuxFr.org.

      Merci pour cette précision !

      Pour Bittorent, on a eut une discussion avec Sinma pour expliquer pourquoi les gens de p2p-hacker, plutôt proches de Bram Cohen et de ses travaux, n'ont pas cité Bittorent. En fait Bittorrent sait faire du décentralisé avec « trackerless Bittorent », mais ce n'est pas le cas d'usage courant.

      Bref, le cas Bittorent m'a paru trop compliqué à aborder pour une première dépêche. Quant aux autres protocoles de partage, si tu en connais, je peux les ajouter à la liste des choses à étudier.

  • # github‽

    Posté par . Évalué à 3.

    C'est moi, ou il y a une petite contradiction à héberger une initiative sur «internet décentralisé» sur nsa.govgithub ? En termes de centralisation mercantile et inutile d'internet, github est quand même pas mal.

    • [^] # Re: github‽

      Posté par (page perso) . Évalué à 3.

      C'est une question pragmatique avant tout. Si d'autres joignent le projet, je serais prêt à considérer d'autres solutions d'hébergement.

      Dans l'idéal, oui il faudrait changer d'hébergeur !

      • [^] # Re: github‽

        Posté par (page perso) . Évalué à -8.

        Ce qui est pragmatique, c'est d'urtiliser les outils de Google, gratuits et simples. Refuser cette centralisation c'est tout sauf pragmatique.

      • [^] # Re: github‽

        Posté par (page perso) . Évalué à 2.

        Dans l'idéal, oui il faudrait changer d'hébergeur !

        tu peux héberger ce qui est sur gitorious.org chez toi ou sinon profiter de http://tuxfamily.org qui te permettra d'avoir git et un site web où installer le wiki de ton choix.

  • # teapotnet

    Posté par (page perso) . Évalué à 5.

  • # Petite précision

    Posté par . Évalué à 6.

    C'est une initiative excellente, Stéphane Bortzmeyer déplore souvent le fait que de nombreux projets lié au p2p se lancent sans jamais se préoccuper de ce qui a été fait avant, regrouper ces informations est un pas dans la bonne direction !

    Pour ce qui est des différents types de centralisation, il serait intéressant de développer un peu la partie technique en mentionnant par exemple qu'il y a, parmi les systèmes centralisé, des système qui sont également réparti (comme le DNS).
    Parfois un système centralisé et réparti est préférable à un système décentralisé, c'est le cas quand on cherche la tolérance aux pannes mais que l'ont veut des identificateurs à la fois unique et parlants (c.f. cet excellent article)

    Dans la partie où tu parles de la « Robustesse aux pannes et aux attaques » des ces réseaux, si cette robustesse est évidente pour ce qui est des pannes ou des attaques par déni de service, ça l'est beaucoup moins pour d'autres type d'attaque si le protocole n'a pas été pensé dès le départ pour les éviter, ainsi si il n'y avait pas de vérification des condensats des morceaux des fichiers téléchargés via bittorrent, un seul client malicieux pourrait faire de gros dommage, c'est l'occasion de mentionner le problème des généraux byzantins.

    • [^] # Re: Petite précision

      Posté par (page perso) . Évalué à 8.

      C'est une initiative excellente, Stéphane Bortzmeyer déplore souvent le fait que de nombreux projets lié au p2p se lancent sans jamais se préoccuper de ce qui a été fait avant, regrouper ces informations est un pas dans la bonne direction !

      C'est exactement ce qui me motive :)

      Pour ce qui est des différents types de centralisation, il serait intéressant de développer un peu la partie technique en mentionnant par exemple qu'il y a, parmi les systèmes centralisé, des système qui sont également réparti (comme le DNS).
      Parfois un système centralisé et réparti est préférable à un système décentralisé, c'est le cas quand on cherche la tolérance aux pannes mais que l'ont veut des identificateurs à la fois unique et parlants (c.f. cet excellent article)

      Tout à fait d'accord, je pense par contre manquer de compétences sur les protocoles classiques type DNS, …etc. Mais bon, je prendrai déjà en compte ta remarque.

      Dans la partie où tu parles de la « Robustesse aux pannes et aux attaques » des ces réseaux, si cette robustesse est évidente pour ce qui est des pannes ou des attaques par déni de service, ça l'est beaucoup moins pour d'autres type d'attaque si le protocole n'a pas été pensé dès le départ pour les éviter, ainsi si il n'y avait pas de vérification des condensats des morceaux des fichiers téléchargés via bittorrent, un seul client malicieux pourrait faire de gros dommage, c'est l'occasion de mentionner le problème des généraux byzantins.

      La dessus je suis d'accord, à vrai dire c'est mon domaine d'expertise :) Il existe beaucoup plus de failles que celles dont tu parles, et dans les protocoles pair-à-pair on parle de modèle « BAR » pour « Byzantin, Altruistic, Relational » :

      • Byzantin : comportement arbitraire, sans limite de ressources et de malice.
      • Altruiste : comportement dans l'intérêt du bien commun, est généralement prêt à fournir plus de ressources que nécessaire pour faire fonctionner le système, et ce, sans contre-partie.
      • Rationnel : ne donne que le minimum pour bénéficier du service. On va même jusqu'à parler de comportement « égoïste », et ce type de pair pose beaucoup de problèmes dans les service p2p.

      Bref, largement de quoi faire une dépêche dédiée à la sécurité en décentralisé :)

  • # Centre de documentation / Wiki

    Posté par (page perso) . Évalué à 5.

    Je n'ai lu que l'intro de l'article mais je me permets déjà le commentaire.

    Si tu as envie de faire un tour d'horizon de ces solutions, on peut collaborer.
    http://wiki.p2pfr.com/p2p

    Les pages concernant les P2P chiffrés n'ont pas été particulièrement soignées, mais il y a au moins quelques notes et des références. C'est un wiki, et pas beaucoup de contributeurs donc normal que ce soit à l'arrache.

    En tout cas tu peux être sûr que je vais relire attentivement les infos que tu donnes ici, et les reprendre là bas. De plus on est dans la même logique: les solutions proprios sont très secondaires pour moi, et je me cogne de la paternité de ce que j'écris.

    Yabon non ?

    • [^] # Re: Centre de documentation / Wiki

      Posté par (page perso) . Évalué à 4.

      Je viens de faire un petit tour du site p2pfr et je dois avouer que je ne connaissais pas du tout. C'est sûr que vous avez fait un gros boulot au niveau documentation et que ça serait dommage de ne pas collaborer là dessus. Je vais m'en servir comme source et faudra qu'on prenne contact pour voir comment on peut bosser ensemble.

      J'avoue que je ce qui m'intéresse le plus est de fournir de la doc pour des hacker/développeurs et comme il a été dit dans les précédents commentaires : fournir un état de l'art permettant de ne pas réinventer la roue.

      En bref, je n'ai pas vocation à vendre les services existants aux utilisateurs (du moins pas en objectif principal). De plus, j'ai toujours du mal à me positionner sur le partage de fichier, auquel je suis parfaitement agnostique (c'est bien et mal à la fois), et sur Bitcoin qui est pour moi un chef d'œuvre technologique détourné de façon pitoyable pour faire de l'argent. Il y a aussi le thème de la censure avec lequel j'ai du mal et qui est souvent maladroitement vendu avec le pair-à-pair. Une absence totale de censure est dérangeante (comme dans Freenet par exemple), alors qu'une auto-censure par la communauté (genre karma LinuxFr.org) peut être démocratique (avec ses limites tout de même) et plus intéressante et souvent manquante dans les services pair-à-pair. Alors, pour toutes ces raisons, j'essaie d'être le plus neutre possible sur l'utilisation des services décentralisés et pair-à-pair.

      Pour finir, un de mes objectifs, commun avec la communauté p2p-hacker internationale, serait de développer un mail 2.0 sûr et décentralisé. On en est pas très loin quand on voit des protocoles comme Bitmessage et Twister, mais pour convaincre les administrations et le quidam lambda, il faut pousser la chose plus loin, notamment avec des bases théoriques fortes et une facilité d'utilisation plus poussée (c'est dur de faire utiliser du GPG à madame Michu).

      J'espère que cela t'en dis un peu plus sur ma position.

  • # Mesh network.

    Posté par (page perso) . Évalué à 3.

    En effet, internet est centralisé à son cœur, puisque IP, le protocole de base de internet, est centralisé. (La manière dont sont distribuée les addresses, et la manière dont les table de routage sont établie). Sans même parler de DNS.

    Je suis assez interressé par les réseau maillés. Je me demande si ça va passer à l'échelle. Je demande à voir ce que va devenir cjdns.

    Une idée intéressante: http://www.openlibernet.org : un réseau basé sur cjdns, mais qui utilise un système basé sur bitcoin pour rétribué les nodes, et ainsi donner une incitation financière aux FIA décentralisés. (Pas de code là, juste un white paper)

    Un autre projet qui essaye de promouvoir namecoin pour le DNS et l'échange des certificats: http://okturtles.com/

    • [^] # Re: Mesh network.

      Posté par (page perso) . Évalué à 2.

      Je suis assez interressé par les réseau maillés. Je me demande si ça va passer à l'échelle. Je demande à voir ce que va devenir cjdns.

      Dans la théorie déjà c'est dur de tenir les débits fournis pur l'infrastructure d'Internet actuelle (gros routeurs, gros tuyaux), alors dans la pratique on verra… Mais je pense que cela à de la valeur en tant que réseau alternatif et démonstration qu'un Internet plus décentralisé est possible !

      Une idée intéressante: http://www.openlibernet.org : un réseau basé sur cjdns, mais qui utilise un système basé sur bitcoin pour rétribué les nodes, et ainsi donner une incitation financière aux FIA décentralisés. (Pas de code là, juste un white paper)

      FIA > FAI non ?

      Sinon je trouve le principe super, mais je n'ai pas approfondi. En particulier je me demande : leur monnaie ils en font quoi pour le moment ? Je veux dire, si je suis client, je fais comment pour obtenir de la monnaie et payer mon accès à Internet ?

      Pour « okturtle » je garde ça dans un coin, j'étudierai aussi. Merci !

      • [^] # Re: Mesh network.

        Posté par (page perso) . Évalué à 4.

        Je résume ici ce que j'ai compris avec ma propre interprétation:

        L'idée c'est que chaque paquet aurait un coût, payé par l'expéditeur du paquet, et reçu par chacune des nodes qui aident à faire transiter un paquet. Les nodes maintiennent des balances entre leur voisins, et les payement sont effectués à partir d'une monaie virtuelle de type bitcoin.

        Exemple: je veux envoyer 1 packet à un ordinateur X, et le paquet va passer par A, B, C, et C. Alors je vais payer 100¤ à A pour qu'il transfert mon paquet. A transfert le baquet à B et lui donne 75¤. lui même le donne à C avec 50¤, qui donne 25¤ à D. Au final j'ai dépensé 100¤ et toutes les nodes intermédiaire ont recu 25¤.

        ¤ est une unité de monnaie imaginaire qui pourrait être très petite (10-10€) de sorte que le coût de transfer d'un mégabyte de donnée soit raisonable.

        Le ¤ peut être obtenu en payant une vrai monaie. Pour pouvoir utiliser le réseau on dois d'abbort acheter des crédits.

        • [^] # Re: Mesh network.

          Posté par (page perso) . Évalué à 3. Dernière modification le 05/03/14 à 19:33.

          OK, si c'est comme ça ça peut être sympa de vois si ça marche.

          On va formaliser tout ça dans un document pour la postérité :)

          Merci.

    • [^] # Re: Mesh network.

      Posté par (page perso) . Évalué à 4.

      Hmmmm, ce commentaire utilise un vocabulaire très approximatif. D'abord, les adresses IP : leur distribution n'est pas centralisée (je viens d'allouer 2a01:e35:8bd9:8bb0::bad:dcaf tout seul sans demander à personne). Elle est arborescente, ce qui n'a pas du tout les mêmes conséquences. Ensuite, le routage, lui, non seulement n'est pas centralisé mais il n'est même pas arborescent. La phrase « la manière dont les table [sic] de routage sont établie [sic] » est donc incompréhensible.

      Quant au DNS, lui aussi est arborescent et non centralisé (Benoit peut créer foobar.linuxfr.org comme il veut sans rien demander à personne).

      Quant à « essaye de promouvoir namecoin pour le DNS », cela n'a pas non plus de sens puisqu'il s'agit de deux protocoles différents. C'est comme écrire « essaye de promouvoir Linux pour Windows ».

      Je précise ces points car je pense qu'une des raisons du peu de succès des techniques « alternatives » est justement le manque de rigueur technique de leurs promoteurs.

      • [^] # Re: Mesh network.

        Posté par (page perso) . Évalué à 2.

        Merci pour ton commentaire.

        Je prétends que une structure en arborescence est une forme de centralisation. Il y a toujours la racine qui est centralisée. C'est vrai que c'est le moins pire.

        Le problème est que par example, imagine que tu sois connecté à la foi via wifi et via 3G. Tu as donc deux fournisseurs différents et deux addresses IP différentes. Mais dans un monde parfait, tu n'aurait que une seule addresse IP, et les paquets prennent la meilleure route automatiquement.

        essaye de promouvoir namecoin pour le DNS

        Si j'ai bien compris, ils ont un serveur DNS qui rajoute des peudo tld .bit et .dns

        • [^] # Re: Mesh network.

          Posté par (page perso) . Évalué à 3.

          On peut en effet toujours redéfinir le vocabulaire comme on veut et appeler centralisé ce qui ne l'est pas. C'est comme si Microsoft décidait tout à coup que Windows est du logiciel libre, en argumentant qu'on peut lancer Word ou IE, au choix, on est libre.

          N'avoir qu'une adresse IP en ayant deux connexions (ce qui, au passage, aurait des conséquences pas forcément agréables pour la vie privée) est l'idée de séparation de l'identificateur et du localisateur. Vieux projet, mis en œuvre dans des techniques comme ILNP, HIP ou LISP, mais qui n'a rien à voir avec le caractère centralisé ou pas.

          .dns, c'est les gens d'okTurtles.

      • [^] # Re: Mesh network.

        Posté par (page perso) . Évalué à 3.

        Quant à « essaye de promouvoir namecoin pour le DNS », cela n'a pas non plus de sens puisqu'il s'agit de deux protocoles différents. C'est comme écrire « essaye de promouvoir Linux pour Windows ».

        Vrai, et j'ajoute que Namecoin n'est pas « vendu » pour ça : c'est une table d'association clef/valeurs distribuée, qui peut notamment être utilisée en tant qu'annuaire de noms. Certes, les objectifs sont proches et le diable est dans le détail. C'est pour ça qu'il y a des confusions et un besoin de documentation de « vulgarisation ».

        Je précise ces points car je pense qu'une des raisons du peu de succès des techniques « alternatives » est justement le manque de rigueur technique de leurs promoteurs.

        Excellent point ! On y vient :)

        Je pense que l'objectif des solutions « alternatives » est de combattre la structure arborescente qui implique une racine et donc, au moins dans le cas de DNS, une centralisation de l'autorité qui administre cette racine. C'est le seul avantage que je vois à une solution non-arborescente (il y en a peut être d'autres qui m'échappent). Je ne crois pas à l'argument de la sécurité, qui vise à dire que décentralisé c'est plus robuste (mais c'est une autre histoire qui nécessite au moins une autre dépêche pour être développée).

        Sinon, c'est pour cette raison de manque de compréhension des enjeux techniques liés aux solutions décentralisées que je fais cet état de l'art. Et il y a du boulot ! :)

  • # Je préfère la communauté Redecentralize

    Posté par . Évalué à 2.

    Je préfère la communauté Redecentralize et en voici l'état de l'art : https://github.com/redecentralize/alternative-internet

    1751 stars sur GitHub. Bref, l'efficacité de cette communauté est indéniable. #troll

    Un petit fil Twitter pour suivre ces libristes : https://twitter.com/redecentralize

  • # Fautes de frappe

    Posté par (page perso) . Évalué à 2.

    (C++/QT)

    Je ne savais pas que Namecoin était fait avec avec QuickTime!

    (Python)(MIT)

    Il manque une espace.

    Écrit en Bépo selon l’orthographe de 1990

  • # BitMessage et Bitcoin

    Posté par (page perso) . Évalué à 2.

    Non, contrairement à ce qui est écrit dans le journal, les deux systèmes n'ont aucun rapport. Certains promoteurs de BitMessage ont juste malhonnètement tenté de profiter de la notoriété de Bitcoin.

    • [^] # Re: BitMessage et Bitcoin

      Posté par . Évalué à 2.

      Le protocole n'est pas le même (même si les réseaux différents) ?
      C'est en tout cas ce que j'avais compris en effet

    • [^] # Re: BitMessage et Bitcoin

      Posté par (page perso) . Évalué à 2.

      Non, contrairement à ce qui est écrit dans le journal, les deux systèmes n'ont aucun rapport. Certains promoteurs de BitMessage ont juste malhonnètement tenté de profiter de la notoriété de Bitcoin.

      Je ne comprend pas du tout cette remarque, de plus je n'ai pas eut vent de cette histoire de malhonnêteté, donc si tu as des sources (ou des arguments), cela m'intéresse. Je n'ai pas trop creusé BitMessage, mais ce dont je suis sûr c'est que les auteurs de BitMessage se revendiquent d'avoir été inspirés par Bitcoin, que ça soit pour l'idée ou pour le code (qui est libre rappelons le). Source :

      The protocol, loosely based off of Bitcoin, uses your computer’s processing power to process messages. Each message requires a proof of work that is designed to take around four minutes.

      Il ont pompé l'idée, donc il n'y a pas « aucun rapport », et on peut dire que BitMessage n'aurait jamais vu le jours sans BitCoin. La formulation du journal est :

      Bitmessage est basé sur la cryptodevise Bitcoin

      Ce qui est faux, j'en conviens. Mais je maintiens que BitMessage s'inspire de Bitcoin. Je changerai la formulation dans le source de l'état de l'art.

      Merci pour la remarque, et si tu as des arguments pour étayer cette histoire de malhonnêteté, que j'ai du mal à projeter sur du logiciel libre, je suis très intéressé !

      • [^] # Re: BitMessage et Bitcoin

        Posté par (page perso) . Évalué à 1.

        Il n'y a rien de Bitcoin dans Bitmessage. Pas le code, mais aucune idée non plus (personne n'a jamais pu me citer un concept de Bitcoin qu'on retrouve dans Bitmessage). Donc, se réclamer de Bitcoin (qui est très connu et très populaire), ce n'est pas honnête.

        • [^] # Re: BitMessage et Bitcoin

          Posté par (page perso) . Évalué à 2.

          personne n'a jamais pu me citer un concept de Bitcoin qu'on retrouve dans Bitmessage

          Il faut que je corrige cela alors : « la preuve de travail » !

          La révolution apporté par Bitcoin, techniquement dans le domaine p2p et décentralisé, c'est la « preuve de travail ». Le principe est simple, quand un pair demande un service au réseau (aux autres pairs), il doit fournir une preuve de travail (typiquement le calcul d'une fonction de hachage). Ce principe résout un des problèmes les plus difficiles en décentralisé : le spam, avec sa variante pair-à-pair : l'inondation (profiter d'une faille du protocole pour créer un nombre de messages que le réseau ne pourrait pas supporter).

          Dans Bitcoin ce mécanisme permet de générer les blocs de transaction, donc de réguler le rythme de validation des transactions (diminuer la probabilité de validations multiples, voire volontairement fausses, qui foutraient le système par terre par inondation) et de réguler le rythme de production des Bitcoins.

          Dans BitMessage le même principe est appliqué pour lutter contre le spam (grossièrement, l'émetteur calcule une transaction pour chaque envoie de message), ce qui me paraît quand même être indispensable pour un protocole de messagerie.

          Voilà le lien entre BitMessage et Bitcoin : lutter contre le spam en faisant payer les transactions par le calcul.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.