Comme à chaque fois que je vois un n-ième réseau social libre décentralisé dansons-joyeusement-autour-du-feu apparait, la première chose qui m'intéresse est de voir ce qu'il y a à l'intérieur, j'ai adoré voir un papier sur le fonctionnement interne. Même qu'il est bien sourcé et plutôt compréhensible, ce qui se comprend vu que le bonhomme est chercheur.
Du coup, pour dissiper quelques fausses remarques (notamment, non, un utilisateur n'est pas seul à disposer de ses données) et parce que le design est sympa, je vous propose un petit récapitulatif.
Twister utilise les 3 technologies les plus en vogues dans le décentralisé: Bitcoin, DHT et Bittorrent.
Bitcoin
Bitcoin, pour ceux qui vivent sous un roc, permet d'enregistrer des données dans un registre public sans autorité centrale, à condition que la majorité des participants soient d'accord pour enregistrer cette donnée. Là où c'est intéressant, c'est que les participants ont intérêt à accepter les publications parce que ça leur procure un potentiel gain.
Ici, un utilisateur va enregistrer une association entre son nom (disons @rakoo) et sa clé publique qu'il se sera fabriquée avant. On ne présente plus les avantages que comportent le chiffrage par clés asymétriques (authentification, respect de l'intégrité: voir l'article Wikipedia pour plus d'infos), du coup tout est centré autour de cette clé publique; mais comme une empreinte de clé est impossible à retenir, l'association à un pseudonyme que tout le monde peut comprendre et qui ne nécessite pas d'autorité centrale fait plaisir. Cependant, à première vue, rien pour éviter le namesquatting...
DHT
Une Distributed Hash Table est une immense table de hachage, conçue pour être répartie sur un nombre potentiellement infini de machines. Le principe de base est que lorsque je cherche la valeur associée à une clé, je me baladerai de machine en machine jusqu'à en trouver une qui pourrait me donner la réponse. Les DHT sont faites pour s’accommoder des vulgaires machines de Mme Michu, qui s'éteignent et se rallument à tout bout de champ. Au final, on a un espace mémoire qu'on peut considérer comme infini et toujours accessible.
Ici la DHT est basée sur Kademlia, comme pour Bittorrent. Dans cette DHT, les utilisateurs se créent un deuxième ID, qui est différent de la clé publique utilisée précédemment, de manière à dissocier clé publique (i.e identité virtuelle) et adresse IP (i.e identité physique). Ici, le deuxième ID est un simple hash de l'IP publique et du port, ce qui aurait les vertus d'être suffisant pour éviter les attaques à la Sybil (cf. papier).
Dans Twister, on écrit des messages courts à caractère public (Twister est basé sur Twitter au niveau des fonctionnalités) que l'on va stocker dans la DHT. Pour stocker un message dans la DHT, on va calculer une clé (c'est à dire un hash qui aura une valeur unique dans l'espace de la DHT) qui dépend entre autres de l'utilisateur et du numéro de séquence du message, ce qui fait que chaque message aura une clé différente, de manière à bien répartir la charge. Du coup, tous ceux qui souhaitent récupérer le message k d'Edward Snowden peuvent aller le récupérer (rappel: les inscriptions sont publiquement accessibles, donc je peux savoir qui a quelle clé publique)
Bittorrent
En plus de la clé précédente basée sur l'utilisateur et le numéro du message, une autre clé est calculée, qui dépend cette fois de l'utilisateur uniquement. Cette deuxième clé va permettre de créer un swarm bittorrent, c'est à dire un ensemble de peers connectés directement les uns aux autres qui vont s'échanger les messages par flooding: dès que l'un deux reçoit un message, il se retrouve peu à peu disséminé partout (en réalité c'est un peu plus indirect que ça, mais l'idée est là)
Du coup, tous ceux qui sont intéressés par un utilisateur (i.e qui veulent le follow) vont entrer dans le swarm et recevoir directement tous les messages de l'utilisateur. Ça permet en même temps d'éviter le polling (tout le monde reçoit les infos en temps réel) et d'accéder plus rapidement à l'ensemble des messages d'un utilisateur. D'ailleurs, les membres du swarm sont identifiés par leur ID secondaires; impossible de savoir quel utilisateur (i.e clé publique) est intéressé par quoi, tout ce qu'on voit c'est quelle IP est intéressée par quoi.
Conclusion
Voilà le modèle de base de Twister. Il offre un certain anonymat (qui peut être augmenté en utilisant Tor), une excellente résilience et surtout la possibilité de suivre les choses en temps réel, ce qui est loin d'être facile avec un système aussi décentralisé. Twister a quelques autres atouts, comme la possibilité de faire des hashtags (et de rechercher dedans directement—de ce point de vue ils sont gérés techniquement comme des utilisateurs), des mentions (pour ça il faut en plus envoyer le paquet au concerné), des messages directs privés (le message sera chiffré avec la clé publique du destinataire; tout le monde verra un message chiffré venant de l'expéditeur passer, mais personne ne saura pour qui il est), et même la possibilité de chercher des mots (pour ça, on découpe chaque message et pour chacun de ses mots on va stocker un message avec le mot comme clé...). Le plus gros inconvénient que je vois, en plus du namesquatting difficile à éviter avec une architecture décentralisée, est de faire en sorte que tout le monde agisse à peu près correctement, ce qui n'est pas gagné.
Bref, tout pour se débarrasser de Twitter. Encore faut-il que les gens suivent.
# Petit compte-rendu du papier blanc
Posté par rakoo (site web personnel) . En réponse au journal twister un microblog opensource P2P. Évalué à 10.
Sommaire
Comme à chaque fois que je vois un n-ième réseau social libre décentralisé dansons-joyeusement-autour-du-feu apparait, la première chose qui m'intéresse est de voir ce qu'il y a à l'intérieur, j'ai adoré voir un papier sur le fonctionnement interne. Même qu'il est bien sourcé et plutôt compréhensible, ce qui se comprend vu que le bonhomme est chercheur.
Du coup, pour dissiper quelques fausses remarques (notamment, non, un utilisateur n'est pas seul à disposer de ses données) et parce que le design est sympa, je vous propose un petit récapitulatif.
Twister utilise les 3 technologies les plus en vogues dans le décentralisé: Bitcoin, DHT et Bittorrent.
Bitcoin
Bitcoin, pour ceux qui vivent sous un roc, permet d'enregistrer des données dans un registre public sans autorité centrale, à condition que la majorité des participants soient d'accord pour enregistrer cette donnée. Là où c'est intéressant, c'est que les participants ont intérêt à accepter les publications parce que ça leur procure un potentiel gain.
Ici, un utilisateur va enregistrer une association entre son nom (disons @rakoo) et sa clé publique qu'il se sera fabriquée avant. On ne présente plus les avantages que comportent le chiffrage par clés asymétriques (authentification, respect de l'intégrité: voir l'article Wikipedia pour plus d'infos), du coup tout est centré autour de cette clé publique; mais comme une empreinte de clé est impossible à retenir, l'association à un pseudonyme que tout le monde peut comprendre et qui ne nécessite pas d'autorité centrale fait plaisir. Cependant, à première vue, rien pour éviter le namesquatting...
DHT
Une Distributed Hash Table est une immense table de hachage, conçue pour être répartie sur un nombre potentiellement infini de machines. Le principe de base est que lorsque je cherche la valeur associée à une clé, je me baladerai de machine en machine jusqu'à en trouver une qui pourrait me donner la réponse. Les DHT sont faites pour s’accommoder des vulgaires machines de Mme Michu, qui s'éteignent et se rallument à tout bout de champ. Au final, on a un espace mémoire qu'on peut considérer comme infini et toujours accessible.
Ici la DHT est basée sur Kademlia, comme pour Bittorrent. Dans cette DHT, les utilisateurs se créent un deuxième ID, qui est différent de la clé publique utilisée précédemment, de manière à dissocier clé publique (i.e identité virtuelle) et adresse IP (i.e identité physique). Ici, le deuxième ID est un simple hash de l'IP publique et du port, ce qui aurait les vertus d'être suffisant pour éviter les attaques à la Sybil (cf. papier).
Dans Twister, on écrit des messages courts à caractère public (Twister est basé sur Twitter au niveau des fonctionnalités) que l'on va stocker dans la DHT. Pour stocker un message dans la DHT, on va calculer une clé (c'est à dire un hash qui aura une valeur unique dans l'espace de la DHT) qui dépend entre autres de l'utilisateur et du numéro de séquence du message, ce qui fait que chaque message aura une clé différente, de manière à bien répartir la charge. Du coup, tous ceux qui souhaitent récupérer le message k d'Edward Snowden peuvent aller le récupérer (rappel: les inscriptions sont publiquement accessibles, donc je peux savoir qui a quelle clé publique)
Bittorrent
En plus de la clé précédente basée sur l'utilisateur et le numéro du message, une autre clé est calculée, qui dépend cette fois de l'utilisateur uniquement. Cette deuxième clé va permettre de créer un swarm bittorrent, c'est à dire un ensemble de peers connectés directement les uns aux autres qui vont s'échanger les messages par flooding: dès que l'un deux reçoit un message, il se retrouve peu à peu disséminé partout (en réalité c'est un peu plus indirect que ça, mais l'idée est là)
Du coup, tous ceux qui sont intéressés par un utilisateur (i.e qui veulent le follow) vont entrer dans le swarm et recevoir directement tous les messages de l'utilisateur. Ça permet en même temps d'éviter le polling (tout le monde reçoit les infos en temps réel) et d'accéder plus rapidement à l'ensemble des messages d'un utilisateur. D'ailleurs, les membres du swarm sont identifiés par leur ID secondaires; impossible de savoir quel utilisateur (i.e clé publique) est intéressé par quoi, tout ce qu'on voit c'est quelle IP est intéressée par quoi.
Conclusion
Voilà le modèle de base de Twister. Il offre un certain anonymat (qui peut être augmenté en utilisant Tor), une excellente résilience et surtout la possibilité de suivre les choses en temps réel, ce qui est loin d'être facile avec un système aussi décentralisé. Twister a quelques autres atouts, comme la possibilité de faire des hashtags (et de rechercher dedans directement—de ce point de vue ils sont gérés techniquement comme des utilisateurs), des mentions (pour ça il faut en plus envoyer le paquet au concerné), des messages directs privés (le message sera chiffré avec la clé publique du destinataire; tout le monde verra un message chiffré venant de l'expéditeur passer, mais personne ne saura pour qui il est), et même la possibilité de chercher des mots (pour ça, on découpe chaque message et pour chacun de ses mots on va stocker un message avec le mot comme clé...). Le plus gros inconvénient que je vois, en plus du namesquatting difficile à éviter avec une architecture décentralisée, est de faire en sorte que tout le monde agisse à peu près correctement, ce qui n'est pas gagné.
Bref, tout pour se débarrasser de Twitter. Encore faut-il que les gens suivent.