Site et wiki existent. Ce qui manque le plus à mon avis c'est l'absence de mailing-list. En interne, ils ont d'autres produits pour remplacer ça, mais en externe il faut encore chercher une solution alternative.
Du coup au lieu de faire ça avec le compte email de l'utilisateur, il faut le faire avec son compte XMPP. Le contact est direct, les implémentations sont sécurisées (en plus tout est fait en ce moment pour que les échanges soient chiffrés).
il faut commencer par le papier « NAT-resilient Gossip Peer Sampling », malheureusement il n'est pas libre
Tu pourrais aussi le faire tomber par inadvertance, et il se trouverait qu'on le ramasserait, mais que ne retrouvant pas le propriétaire, on le lirait. Par pure curiosité scientifique.
Faut croire que je sais pas m'exprimer. Ce que tu cites est justement ce que sait faire Retroshare qui en fait une plateforme super intéressante et qui n'a pas l'air d'exister dans HoneyTeaPotNet
Effectivement, ça m'a tout l'air d’être du retroshare avec la capacité de se faire passer pour du HTTP pour passer les pare-feu nazis. L’énorme avantage que je vois a retroshare est qu'il ne s’arrête pas aux amis mais peut aller sur l'ensemble du réseau via les amis des amis des amis […] sans pour autant dévoiler son identité.
weboob, c'est d'abord et avant tout une librairie pour utiliser des services web dans une application. Le gros avantage c'est que pour des services web similaires (ma facture du mois precedent), il n'y a pas besoin de se retaper tous les sites dont tu as besoin un par un, qui chacun utilise une API différente et que tu dois donc réanalyser (ou pire, quand il n'y a pas d'API et que tu dois scraper les pages une par une).
Non, au lieu de faire ça, tu utilises une seule et unique capability, pour laquelle plusieurs backends peuvent être utilisés (voir les backends dispos pour tout ce qui concerne des factures). Au final tout ce que tu as besoin d'apprendre c'est l'API unique de la capability, et après tous les backends sont interchangeables (ou, encore mieux, utilisables en parallèle).
Les applications présentées sont surtout la pour montrer ce dont weboob la librairie est capable, avec des produits simples et censés être suffisamment alléchants pour que tu développes par-dessus (puisque t'es pas content, pourquoi ne proposes-tu pas tes améliorations ?)
Ça me rappelle des discussions récentes sur le fait que OSM est beaucoup moins bien utilisable que Google Maps pour des usages courants. C'est la même chose: OSM est d'abord et avant tout une base de données d'informations a caractère géographique. Le but est d'aider la création d'applications géographiques sans avoir a se soucier d'aller chercher les données, juste a les organiser comme il faut. Comme weboob.
J'ai une question pour des connaissances qui seraient potentiellement interessees par elementary (parce que c'est sexy): est-ce qu'on peut considérer ça comme suffisamment stable pour un usage bureautique ? Disons, aussi stable qu'Ubuntu ou Linux Mint ?
A moins que le namesquatting ne désigne l'enregistrement du nom de quelqu'un d'autre avant que ce dernier ne le fasse
C'est exactement ça. Rien ne m’empêche aujourd'hui de m'inscrire en tant que @google. L'avantage d'un système centralise dans ce cas de figure est qu'il fait autorité (bonne ou mauvaise est un détail politique; techniquement, c'est possible). A l'inverse, Bitcoin et dérivés ne permettent pas de régler ce genre de conflits.
Cela veut-il dire que les premières inscriptions seront faciles mais qu'il deviendra de plus en plus difficile de s'inscrire ?
Il faut voir plus en détail comment marchent les bitcoins. Ce que tu mines, ce sont des blocks virtuels qui contiennent des données arbitraires. Il est de plus en plus difficile de trouver (c'est a dire miner) un bloc, mais il sera toujours aussi trivial de vérifier un bloc. La ou ça nous intéresse pour Twister, c'est que ce qui compte n'est pas de trouver de plus en plus de blocks, mais que tout le monde soit d'accord sur l'ensemble des blocks (puisque c'est cet ensemble qui détermine qui est inscrit ou non). Dans l'utilisation classique des bitcoins et autres en tant que monnaie, c'est trouver un block qui est rémunérateur, d’où la course a l'armement (dans Twister, trouver un block donne droit a un message de spam que les pairs du réseau devraient afficher… c'est la manière de l'auteur a inciter tout le monde a continuer de miner)
Si la difficulté augmente, c'est que quelqu'un quelque part a une puissance de calcul plus élevée, et que c'est lui qui trouvera les blocs; pas de problème, a partir du moment ou il en trouve et que tout le monde le vérifie ça valide le block.
Quelles genres de données met-on dans les blocks ? Et bien tout simplement la liste des utilisateurs. Lorsqu'on veut s'inscrire, on envoie a tout le monde son nom avec sa clé publique et tout le monde essaie de miner le prochain block avec ce nouveau nom. Pour eviter que n'importe qui envoie des inscriptions pour flooder le reseau, il y a une deuxieme proof of work qui est censée ne durer que quelques minutes pour l'utilisateur "normal".
Dans la mesure ou c'est comme ça que se développent les Grands Logiciels du Libre (sauf qu'ils n'envoient pas les sources, mais les patchs), ça me fait rire un peu jaune …
Oh, ce FUD visible à des kilomètres. L'interface web n'est prévue que pour localhost; si la même personne a plusieurs machines différentes, il est prévu que chacune de ses machines recopie la clé privée, de manière à être totalement indépendantes les unes des autres.
Le web n'est utilisé que parce que c'est facile de faire des interfaces jolies et utilisables.
Quant aux mesures, je n'en ai aucune idée, mais je ne vois pas de raison à ce que ce soit aussi élevé que tu le croies. Et franchement, comparer à un serveur IRC, point de centralisation par excellence… À la limite un cluster de serveurs IRC, mais ça introduit d'autres problèmes :
- techniquement: le monde est coupé en deux quand un serveur tombe
- techniquement encore: les serveurs IRC passent leur temps à s'échanger des messages de statut, parce que tous les serveurs doivent savoir qui est dans quel salon… tu parles d'un gâchis de bande passante
- politiquement: qui a le droit de donner quels droits à qui
- fonctionnellement: le microblogging veut dire que l'attention est portée aux personnes. Dans un canal IRC, l'attention est portée sur le sujet général de la discussion. Pour se rapprocher de Twitter, il faudrait avoir un canal par utilisateur… J'aimerais bien voir ça, tiens.
À la limite, on pourrait imaginer un cluster de serveurs spéciaux où personne n'a plus de droits que les autres, qui ne s'échangent pas les nicks dans un chan mais uniquement les chans, et que chaque client se connecte à plusieurs serveurs "au cas où".
Non. On pourrait imaginer un service tiers, centralisé, a qui tu donnes ton mot de passe et qui peut te le renvoyer quand tu l'as perdu… mais rien dans Twister même.
Peut-on effacer un compte et les données associées ?
C'est la que l'analogie avec les systèmes centralisés devient fausse: il n'y a pas vraiment de "compte" (ce qui supposerait une instance centrale qui décide si elle t'accepte ou pas), mais plutôt une "participation".
- Si tu veux supprimer tes messages des autres nœuds, impossible. De la même manière qu'il est impossible de supprimer un tweet du cache de mon navigateur.
- Si tu veux supprimer tes messages de ton propre nœud, rien ne t'en empêche.
- Si tu veux supprimer tes informations, tu remplaces les actuelles par des vides: un avatar vide, une url vide, … De tout façon tout le monde aura déjà vu l'ancienne version, il est illusoire de croire qu'on peut la supprimer de la mémoire collective.
- Si tu veux dire publiquement que tu ne participes plus, rien n'est prévu, mais on pourrait imaginer que publier sa clé privée serait pris en compte par tout le monde comme une sortie du groupe.
Peut-on facilement faire une interface web […] découvrir le service avant de l'installer sur sa machine?
Si tu parles d'un site permettant de voir l'ensemble des messages sur le réseau, l'auteur y a pensé et ça "devrait être faisable" (d'ailleurs je te rejoins, ça serait vraiment intéressant… c'est ce qui fait la force des réseaux centralises).
Si tu parles d'un site ou on délègue la sécurité a un tiers en s'y inscrivant et en n'interagissant qu'avec l'interface web, non, rien n'existe et je ne pense même pas qu'il y ait quelque chose dans les cartons (puisque c'est contre l'esprit). Mais "ça reste faisable".
Twister en est encore a l’état "ça marchouille si t'as réussi a compiler", on est loin d'un truc grand public. Par contre, parmi l'ensemble des propositions de réseau libre décentralisé et cetera, c'est l'approche la plus simple que j'ai vue (elle réutilise des choses qui existent et qui ont prouve qu'elles fonctionnent) plutôt que de réinventer la roue.
Un produit incapable de gérer les emmerdeurs est voué à l'échec, par définition.
Justement, la DHT utilisée par bittorrent semble retisser pas mal aux emmerdeurs (Il y a un nombre pas possible de noeuds qui ne font rien mais qui s’insèrent quand même dans le réseau, et pourtant ça marche). En fait je pense surtout au point ou chaque utilisateur
la personne qui conclut que c'est complet/prêt pour que les gens puissent avoir l'idée de suivre
Ah non, c'est clairement pas prêt. Je dis juste que fonctionnellement (tweets, hashtags, mentions, direct messages), Twister a tous les éléments pour remplacer Twitter (modulo le namesquatting toujours, mais d'ailleurs est-ce que Twitter résout ça activement ?). Techniquement, il essaie de faire ça de manière décentralisée, et pour moi "ça a l'air de marcher". Mais en pratique on est loin, très loin d'avoir quelque chose d'utilisable comme Twitter.
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.
Les Japonnais utilisent couramment plusieurs alphabet, dont l'alphabet latin.
Ouais, mais pas pour tout non plus. Typiquement, pour le nom des villes ils utiliseront quasiment tout le temps 東京 (c'est a dire la version "caractères chinois"). Au pire du pire, トーキョー (c'est a dire la version "caractère japonais faits entre autres pour ce qui vient de l’étranger"), mais ça m’étonnerait beaucoup. De manière générale, pour les mots de la langue, tu as très peu de chance de tomber dessus en alphabet latin. Ils sauraient lire, mais ça n'aura du sens que pour toi (et c'est pour moi un début de francisation, ou en tout cas d'occidentalisation)
Je ne sais pas ce qu'il en est du Coréen et du Chinois, mais j'imagine que c'est pareil.
je trouve beaucoup plus respectueux de parler de Beijing ou de Seoul que de Pékin
idem, d'ailleurs Beijing a l'air de revenir plus a la mode en français, ce qui n'est pas pour me déplaire.
Je comprends l'envie, mais ça m'énerve quand même: ce sont des noms propres, est-ce qu'on francise les noms propres ? Est-ce que tu as vu le dernier Transformeurs par Michel Baie ? (non, ce n'est pas de la traduction, juste des bidouilles pour que ça sonne français).
Bon, en même temps je suis du genre à penser qu'il est stupide de franciser les noms de ville, parce qu'un nom ne se traduit pas/ne se francise pas.
WebPG marche bien. Il n'est pas spécifique aux webmails, il permet de chiffrer/déchiffrer/signer/vérifier tous les blocs qui ressemblent a des blocs PGP.
faire passer (potentiellement) des centaines de Mo par Internet une fois par semaine (par exemple) alors que (si ça se trouve) 3 Mo ont été modifiés, bof
rsync a été inventé justement pour résoudre ce problème, et le simple fait de chercher rsync dans ton moteur de recherche te retournera un nombre incroyable de solutions.
D'ailleurs, pour faire des sauvegardes sans (trop) te casser la tête, je te conseillerais rdiff-backup.
D'ailleurs, le réglage par défaut de BOSH passe par les ports 5280 et 5281, qui ont de grandes chances d’être bloqués en milieu hostile. Pas de pot, c'est là qu'on se sert le plus de BOSH en temps que contournement. Du coup il a fallu que je reverse-proxy depuis le bon vieux 443 vers mon serveur BOSH.
[^] # Re: Github, une référence ?
Posté par rakoo (site web personnel) . En réponse au journal La guerre des forges. Évalué à 4.
Site et wiki existent. Ce qui manque le plus à mon avis c'est l'absence de mailing-list. En interne, ils ont d'autres produits pour remplacer ça, mais en externe il faut encore chercher une solution alternative.
[^] # Re: Mon expérience
Posté par rakoo (site web personnel) . En réponse à la dépêche Twister, un microblog opensource P2P. Évalué à 2.
@rakoo, bien sûr.
# Plus sérieusement
Posté par rakoo (site web personnel) . En réponse au journal Firefox en GTK3. Évalué à 10.
Quand est-ce que Firefox passe en Qt ?
[^] # Re: pas de mot de passe?
Posté par rakoo (site web personnel) . En réponse au journal L'art de stocker des mots de passe. Évalué à 5.
Du coup au lieu de faire ça avec le compte email de l'utilisateur, il faut le faire avec son compte XMPP. Le contact est direct, les implémentations sont sécurisées (en plus tout est fait en ce moment pour que les échanges soient chiffrés).
[^] # Re: mea culpa
Posté par rakoo (site web personnel) . En réponse au journal Teapotnet, un réseau social privé pour l'échange de fichiers. Évalué à 5.
Tu pourrais aussi le faire tomber par inadvertance, et il se trouverait qu'on le ramasserait, mais que ne retrouvant pas le propriétaire, on le lirait. Par pure curiosité scientifique.
[^] # Re: RetroShare
Posté par rakoo (site web personnel) . En réponse au journal Teapotnet, un réseau social privé pour l'échange de fichiers. Évalué à 3.
Faut croire que je sais pas m'exprimer. Ce que tu cites est justement ce que sait faire Retroshare qui en fait une plateforme super intéressante et qui n'a pas l'air d'exister dans
HoneyTeaPotNet[^] # Re: RetroShare
Posté par rakoo (site web personnel) . En réponse au journal Teapotnet, un réseau social privé pour l'échange de fichiers. Évalué à 4.
Effectivement, ça m'a tout l'air d’être du retroshare avec la capacité de se faire passer pour du HTTP pour passer les pare-feu nazis. L’énorme avantage que je vois a retroshare est qu'il ne s’arrête pas aux amis mais peut aller sur l'ensemble du réseau via les amis des amis des amis […] sans pour autant dévoiler son identité.
[^] # Re: La nostalgie du minitel
Posté par rakoo (site web personnel) . En réponse à la dépêche 0.h un weboob. Évalué à 10.
weboob, c'est d'abord et avant tout une librairie pour utiliser des services web dans une application. Le gros avantage c'est que pour des services web similaires (ma facture du mois precedent), il n'y a pas besoin de se retaper tous les sites dont tu as besoin un par un, qui chacun utilise une API différente et que tu dois donc réanalyser (ou pire, quand il n'y a pas d'API et que tu dois scraper les pages une par une).
Non, au lieu de faire ça, tu utilises une seule et unique capability, pour laquelle plusieurs backends peuvent être utilisés (voir les backends dispos pour tout ce qui concerne des factures). Au final tout ce que tu as besoin d'apprendre c'est l'API unique de la capability, et après tous les backends sont interchangeables (ou, encore mieux, utilisables en parallèle).
Les applications présentées sont surtout la pour montrer ce dont weboob la librairie est capable, avec des produits simples et censés être suffisamment alléchants pour que tu développes par-dessus (puisque t'es pas content, pourquoi ne proposes-tu pas tes améliorations ?)
Ça me rappelle des discussions récentes sur le fait que OSM est beaucoup moins bien utilisable que Google Maps pour des usages courants. C'est la même chose: OSM est d'abord et avant tout une base de données d'informations a caractère géographique. Le but est d'aider la création d'applications géographiques sans avoir a se soucier d'aller chercher les données, juste a les organiser comme il faut. Comme weboob.
[^] # Re: Elementary
Posté par rakoo (site web personnel) . En réponse au journal Nouvelle interface pour gedit. Évalué à 2.
J'ai une question pour des connaissances qui seraient potentiellement interessees par elementary (parce que c'est sexy): est-ce qu'on peut considérer ça comme suffisamment stable pour un usage bureautique ? Disons, aussi stable qu'Ubuntu ou Linux Mint ?
[^] # Re: Mouai
Posté par rakoo (site web personnel) . En réponse au journal Vie privée ? Connais pas. Évalué à 10.
Bon, bah ça sera le GPS de ton téléphone alors.
# Sources
Posté par rakoo (site web personnel) . En réponse au journal Vie privée ? Connais pas. Évalué à 3.
Les sources, bien sur:
Première annonce
"Non, c'est pas ça que je voulais dire"
[^] # Re: Namesquatting ? SPAM ?
Posté par rakoo (site web personnel) . En réponse à la dépêche Twister, un microblog opensource P2P. Évalué à 2.
C'est exactement ça. Rien ne m’empêche aujourd'hui de m'inscrire en tant que @google. L'avantage d'un système centralise dans ce cas de figure est qu'il fait autorité (bonne ou mauvaise est un détail politique; techniquement, c'est possible). A l'inverse, Bitcoin et dérivés ne permettent pas de régler ce genre de conflits.
use the source, luke.
Il faut voir plus en détail comment marchent les bitcoins. Ce que tu mines, ce sont des blocks virtuels qui contiennent des données arbitraires. Il est de plus en plus difficile de trouver (c'est a dire miner) un bloc, mais il sera toujours aussi trivial de vérifier un bloc. La ou ça nous intéresse pour Twister, c'est que ce qui compte n'est pas de trouver de plus en plus de blocks, mais que tout le monde soit d'accord sur l'ensemble des blocks (puisque c'est cet ensemble qui détermine qui est inscrit ou non). Dans l'utilisation classique des bitcoins et autres en tant que monnaie, c'est trouver un block qui est rémunérateur, d’où la course a l'armement (dans Twister, trouver un block donne droit a un message de spam que les pairs du réseau devraient afficher… c'est la manière de l'auteur a inciter tout le monde a continuer de miner)
Si la difficulté augmente, c'est que quelqu'un quelque part a une puissance de calcul plus élevée, et que c'est lui qui trouvera les blocs; pas de problème, a partir du moment ou il en trouve et que tout le monde le vérifie ça valide le block.
Quelles genres de données met-on dans les blocks ? Et bien tout simplement la liste des utilisateurs. Lorsqu'on veut s'inscrire, on envoie a tout le monde son nom avec sa clé publique et tout le monde essaie de miner le prochain block avec ce nouveau nom. Pour eviter que n'importe qui envoie des inscriptions pour flooder le reseau, il y a une deuxieme proof of work qui est censée ne durer que quelques minutes pour l'utilisateur "normal".
[^] # Re: git ou mercurial, le choix n'est pas important...
Posté par rakoo (site web personnel) . En réponse au journal "Scaling Mercurial at Facebook". Évalué à -4.
Dans la mesure ou c'est comme ça que se développent les Grands Logiciels du Libre (sauf qu'ils n'envoient pas les sources, mais les patchs), ça me fait rire un peu jaune …
[^] # Re: c'est une question de philosophie
Posté par rakoo (site web personnel) . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 3.
Ah ouais mais ça, ça n'a rien a voir avec un gestionnaire de version, je conçois tout a fait que git ne soit pas optimise pour ça.
# Ils ont surtout besoin de traducteurs
Posté par rakoo (site web personnel) . En réponse au journal Blague : Plouf le serveur. Évalué à 8. Dernière modification le 08 janvier 2014 à 14:16.
Les instructions sont la, le git du site web est la.
[^] # Re: J'ai rien compris, mais...
Posté par rakoo (site web personnel) . En réponse au journal Blague : Plouf le serveur. Évalué à 3.
J'imagine que tous les serveurs, même européens, peuvent servir les clients du monde entier. Tu recevrais donc du trafic d'ailleurs.
[^] # Re: Weberie malgré tout ?
Posté par rakoo (site web personnel) . En réponse au journal twister un microblog opensource P2P. Évalué à 6.
Oh, ce FUD visible à des kilomètres. L'interface web n'est prévue que pour localhost; si la même personne a plusieurs machines différentes, il est prévu que chacune de ses machines recopie la clé privée, de manière à être totalement indépendantes les unes des autres.
Le web n'est utilisé que parce que c'est facile de faire des interfaces jolies et utilisables.
Quant aux mesures, je n'en ai aucune idée, mais je ne vois pas de raison à ce que ce soit aussi élevé que tu le croies. Et franchement, comparer à un serveur IRC, point de centralisation par excellence… À la limite un cluster de serveurs IRC, mais ça introduit d'autres problèmes :
- techniquement: le monde est coupé en deux quand un serveur tombe
- techniquement encore: les serveurs IRC passent leur temps à s'échanger des messages de statut, parce que tous les serveurs doivent savoir qui est dans quel salon… tu parles d'un gâchis de bande passante
- politiquement: qui a le droit de donner quels droits à qui
- fonctionnellement: le microblogging veut dire que l'attention est portée aux personnes. Dans un canal IRC, l'attention est portée sur le sujet général de la discussion. Pour se rapprocher de Twitter, il faudrait avoir un canal par utilisateur… J'aimerais bien voir ça, tiens.
À la limite, on pourrait imaginer un cluster de serveurs spéciaux où personne n'a plus de droits que les autres, qui ne s'échangent pas les nicks dans un chan mais uniquement les chans, et que chaque client se connecte à plusieurs serveurs "au cas où".
[^] # Re: Petit compte-rendu du papier blanc
Posté par rakoo (site web personnel) . En réponse au journal twister un microblog opensource P2P. Évalué à 4.
Non. On pourrait imaginer un service tiers, centralisé, a qui tu donnes ton mot de passe et qui peut te le renvoyer quand tu l'as perdu… mais rien dans Twister même.
C'est la que l'analogie avec les systèmes centralisés devient fausse: il n'y a pas vraiment de "compte" (ce qui supposerait une instance centrale qui décide si elle t'accepte ou pas), mais plutôt une "participation".
- Si tu veux supprimer tes messages des autres nœuds, impossible. De la même manière qu'il est impossible de supprimer un tweet du cache de mon navigateur.
- Si tu veux supprimer tes messages de ton propre nœud, rien ne t'en empêche.
- Si tu veux supprimer tes informations, tu remplaces les actuelles par des vides: un avatar vide, une url vide, … De tout façon tout le monde aura déjà vu l'ancienne version, il est illusoire de croire qu'on peut la supprimer de la mémoire collective.
- Si tu veux dire publiquement que tu ne participes plus, rien n'est prévu, mais on pourrait imaginer que publier sa clé privée serait pris en compte par tout le monde comme une sortie du groupe.
Si tu parles d'un site permettant de voir l'ensemble des messages sur le réseau, l'auteur y a pensé et ça "devrait être faisable" (d'ailleurs je te rejoins, ça serait vraiment intéressant… c'est ce qui fait la force des réseaux centralises).
Si tu parles d'un site ou on délègue la sécurité a un tiers en s'y inscrivant et en n'interagissant qu'avec l'interface web, non, rien n'existe et je ne pense même pas qu'il y ait quelque chose dans les cartons (puisque c'est contre l'esprit). Mais "ça reste faisable".
Twister en est encore a l’état "ça marchouille si t'as réussi a compiler", on est loin d'un truc grand public. Par contre, parmi l'ensemble des propositions de réseau libre décentralisé et cetera, c'est l'approche la plus simple que j'ai vue (elle réutilise des choses qui existent et qui ont prouve qu'elles fonctionnent) plutôt que de réinventer la roue.
[^] # Re: Petit compte-rendu du papier blanc
Posté par rakoo (site web personnel) . En réponse au journal twister un microblog opensource P2P. Évalué à 3.
Justement, la DHT utilisée par bittorrent semble retisser pas mal aux emmerdeurs (Il y a un nombre pas possible de noeuds qui ne font rien mais qui s’insèrent quand même dans le réseau, et pourtant ça marche). En fait je pense surtout au point ou chaque utilisateur
Ah non, c'est clairement pas prêt. Je dis juste que fonctionnellement (tweets, hashtags, mentions, direct messages), Twister a tous les éléments pour remplacer Twitter (modulo le namesquatting toujours, mais d'ailleurs est-ce que Twitter résout ça activement ?). Techniquement, il essaie de faire ça de manière décentralisée, et pour moi "ça a l'air de marcher". Mais en pratique on est loin, très loin d'avoir quelque chose d'utilisable comme Twitter.
# 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.
[^] # Re: Android / androïde
Posté par rakoo (site web personnel) . En réponse à la dépêche CyanogenMod 10.2. Évalué à 3.
Ouais, mais pas pour tout non plus. Typiquement, pour le nom des villes ils utiliseront quasiment tout le temps 東京 (c'est a dire la version "caractères chinois"). Au pire du pire, トーキョー (c'est a dire la version "caractère japonais faits entre autres pour ce qui vient de l’étranger"), mais ça m’étonnerait beaucoup. De manière générale, pour les mots de la langue, tu as très peu de chance de tomber dessus en alphabet latin. Ils sauraient lire, mais ça n'aura du sens que pour toi (et c'est pour moi un début de francisation, ou en tout cas d'occidentalisation)
Je ne sais pas ce qu'il en est du Coréen et du Chinois, mais j'imagine que c'est pareil.
idem, d'ailleurs Beijing a l'air de revenir plus a la mode en français, ce qui n'est pas pour me déplaire.
[^] # Re: Android / androïde
Posté par rakoo (site web personnel) . En réponse à la dépêche CyanogenMod 10.2. Évalué à 1.
Je comprends l'envie, mais ça m'énerve quand même: ce sont des noms propres, est-ce qu'on francise les noms propres ? Est-ce que tu as vu le dernier Transformeurs par Michel Baie ? (non, ce n'est pas de la traduction, juste des bidouilles pour que ça sonne français).
Bon, en même temps je suis du genre à penser qu'il est stupide de franciser les noms de ville, parce qu'un nom ne se traduit pas/ne se francise pas.
[^] # Re: Résistance au changement… => email = peine perdue
Posté par rakoo (site web personnel) . En réponse au journal GnuPG peut encore avoir plus de sous. Évalué à 3.
WebPG marche bien. Il n'est pas spécifique aux webmails, il permet de chiffrer/déchiffrer/signer/vérifier tous les blocs qui ressemblent a des blocs PGP.
[^] # Re: sauvegarde / réplication
Posté par rakoo (site web personnel) . En réponse à la dépêche ownCloud 6. Évalué à 5.
rsync a été inventé justement pour résoudre ce problème, et le simple fait de chercher
rsyncdans ton moteur de recherche te retournera un nombre incroyable de solutions.D'ailleurs, pour faire des sauvegardes sans (trop) te casser la tête, je te conseillerais rdiff-backup.
[^] # Re: Quelques réponses en vrac
Posté par rakoo (site web personnel) . En réponse au journal Mon réseau social centralisé. Évalué à 2.
D'ailleurs, le réglage par défaut de BOSH passe par les ports 5280 et 5281, qui ont de grandes chances d’être bloqués en milieu hostile. Pas de pot, c'est là qu'on se sert le plus de BOSH en temps que contournement. Du coup il a fallu que je reverse-proxy depuis le bon vieux 443 vers mon serveur BOSH.