J'ai récemment changé de système de chat pour mon site web pour une tribune. Avant, j'utilisais le protocole XMPP avec comme serveur ejabberd et comme client muckl_tribune, une variante de muckl que j'ai modifié pour émuler l'ergonomie d'une tribune, mais la complexité de la solution et le manque de temps m'ont conduit à adopter l'une des meilleures tribunes du marché, celle de Drupal. J'en ai aussi profité pour migrer mon blog dotclear.
Ces migrations m'ont conduit à m'intéresser de plus près au monde des tribunes.
Qu'est-ce qu'une tribune?
Voici la meilleure définition que j'ai trouvée :
Une tribune (parfois appelée "shoutbox") est une application Web permettant à plusieurs utilisateurs de discuter : il s'agit d'un chat Web caractérisé par l'utilisation des standards HTTP et XML. Ainsi, afin de mettre en œuvre un chat Web, une tribune expose une API HTTP permettant à plusieurs utilisateurs 1) de poster un message et 2) d'obtenir les derniers messages postés sous la forme d'un fichier XML appelé backend. devmoules
Les tribunes les plus célèbres sont dlfp et euromussels.
La centralisation
Contrairement à d'autres systèmes, tels que XMPP ou Retroshare, à l'heure actuelle les tribunes sont centralisées : elles sont toujours liées à un site web auquel il est parfois obligatoire de s'inscrire. C'est donc du pur Minitel 2.0 avec tous les abus possibles que cela implique (atteintes à la vie privée, censure…).
Note: la partie serveur s'appelle bouchot ou simplement tribune et la partie cliente coincoin.
La décentralisation
Le principe
J'ai essayé d'imaginer ce que pourrait être un système de tribune décentralisée : ce qui m'a semblé le plus simple, c'est de considérer que chaque utilisateur aurait sa propre base de données contenant les messages. Régulièrement, les utilisateurs amis synchronisent leurs bases, important les messages des autres, exportant les leurs.
Le prototype.
Définir et synchroniser des bases de données n'est pas une mince affaire ; heureusement, j'ai eu l'idée d'utiliser un système de bases synchronisées que je connais bien, puisque je m'en sers pour gérer tous mes projets : fossil, un logiciel basé sur sqlite qui combine gestionnaire de version, wiki et bugtracker.
Une fonctionnalité peu utilisée de fossil est la création d’événement. J'ai "hacké" ce système pour m'en servir de stockage de messages et réduire mon prototype à deux scripts : un pour transformer la liste des événements en backend xml, un autre pour recevoir un message et le transformer en événement.
Testé avec mon coincoin préféré (onlinecoincoin), le prototype est une tribune tout à fait fonctionnelle. En clonant le dépôt, j'ai pu voir que l'on peut gérer plusieurs tribunes indépendantes et les faire se synchroniser par fossil.
Conclusion
La centralisation des tribunes n'est pas une fatalité, le prototype le montre, même s'il a ses limites : il se base sur un "hack" de fossil, l'authentification n'est pas gérée, les norloges sont forcément UTC… Mais peut être qu'un jour un développeur de talent reprendra cette idée et deviendra riche et célèbre avec !
# Changement de système de chat
Posté par Dr BG (site web personnel) . Évalué à 1.
Comme ça ? http://www.youtube.com/watch?v=xbJn_yj6dls
[^] # Re: Changement de système de chat
Posté par gnumdk (site web personnel) . Évalué à 1.
Je préfère les canards…
# En fait...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6.
… J'ai vaguement l'impression que tu essayes de ré-inventer NNTP …
[^] # Re: En fait...
Posté par mansuetus (site web personnel) . Évalué à 4.
Ou plutôt irc, plus adapté au chat… surtout en temps réel
[^] # Re: En fait...
Posté par coïn . Évalué à 3.
plutot xmpp. c'est à dire un protocole de causerie décentralisé.
la force de la tribune, c'est
1) le suivi des conversations grâce au système des nhorloges. je sais que l'idée de créer un système équivalent à été cherché dans jabber, mais sans succès.
2) un protocole simple (à base de http pour la version centralisé)
[^] # Re: En fait...
Posté par Nÿco (site web personnel) . Évalué à 3.
Si, si, on l'avait fait dans OneTeam, en mieux. Pas faute de l'avoir dit.
[^] # Re: En fait...
Posté par MrLapinot (site web personnel) . Évalué à 4.
Il y a une raison pour laquelle ça n'a pas donné lieu à une XEP du coup ?
[^] # Re: En fait...
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
Tellement mieux que toutes les moules ont arrêté les tribunes pour installer OneTeam.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: En fait...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Par curiosité, j'ai testé oneteam.
Les bons points:
Les choses à améliorer
Enfin concernant le suivi des conversations, non ce n'est pas mieux que le système des norloges: c'est juste du threading et j'ai l'impression qu'il n'y a que deux niveaux possibles (conversation principale, conversations annexes).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: En fait...
Posté par ckyl . Évalué à 5.
Suivre des conversations dans un système décentralisé c'est juste des horloges de lamport.
[^] # Re: En fait...
Posté par vlamy (site web personnel) . Évalué à 8.
Pardon d'avance, mais pour une fois qu'on tombe dans mon domaine de compétence, je vais pinailler un peu :
Les horloges de Lamport (horloges scalaires) te permettent de re-séquencer (garder la causalité) les messages d' une source. Et encore, si tu fais de la diffusion tu peux avoir besoin d'horloges vectorielles.
Donc en gros, HL Lamport suffisent pour du dialogue à 2 participants. A N participants (N potentiellement grand) et avec des communications asynchrones, le problème se corse : tu dois garder des structures (vecteurs ou matrices) en O(N) et les faire transiter dans chaque message. J'ai étudié des protocoles pair à pair (théoriques) qui sont censés résoudre ce problème à large échelle et il semblerait que la meilleur des solutions, pour passer à l'échelle, est de se baser sur une synchronisation UTC des horloges (avec des erreurs de séquencement potentiellement selon la précision des horloges et de leur synchro). Bref, si vous voulez vraiment gardez des norloges en pair à pair je vous conseille la synchro UTC. Et je peux étayer mes dires avec des publications si besoin est :)
[^] # Re: En fait...
Posté par barmic . Évalué à 5.
Et encore tu n'a pas pris en compte que ce N est dynamique et peut grandir et réduire. Les horloges de Lamport sont bien pour des réplications de serveurs (tu garde un pool de serveurs synchronisés), mais pour un fonctionnement sur un réseau asynchrone avec un nombre variable de nœuds, je ne pense pas que ce soit une bonne idée.
Il faut aussi prendre en compte l'éventualité d'une attaque du réseau. De ce que je crois savoir les horloges de Lamport supportent très mal les pannes byzantines.
Ça m'intéresse. Je n'ai étudié que les grandes lignes des réseaux paire à paire (structuré ou non) avec comme problématique la recherche de ressources/documents. Comment fais-tu pour assurer le séquencement des messages ? À moins de s'amuser à modifier l'historique (te rendre compte que tu as un nouveau message qui est apparu 10min avant le dernier message que tu as délivré), je ne vois pas comment.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: En fait...
Posté par vlamy (site web personnel) . Évalué à 3.
Pour la réplication on utilise généralement une diffusion totalement ordonnée. Selon le protocole (séquenceur fixe, mobile ou à base d'historique) on a, ou pas, des horloges de Lamports.
Alors en pair-à-pair : je n'ai jamais vu d'études la dessus. Et à priori j'ai bien creusé le problème :) Par contre un truc tout con pour délivrer les messages dans le même ordre (en modifiant l'historique localement si message en retard, ce qui ne devrait pas poser de problème pour les norloges) : tu établis un ordre sur les estampilles horaires et tu résous le conflit, en cas d'égalité, en utilisant l'identifiant de l'émetteur (en général un hash de @IP+port qui est donc unique).
[^] # Re: En fait...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Il y a peut être une autre façon de faire, car dans une conversation, ce qui compte c'est l'intention de celui qui envoie un message plus que l'exactitude mathématique.
Un message pourrait par exemple avoir la structure suivante (pseudo syntaxe):
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: En fait...
Posté par vlamy (site web personnel) . Évalué à 1.
Je crois que j'ai compris, mais je suis pas sûr.
En fait tu dis que l'historique des messages n'a d'importance qu'entre un message et son prédécesseur (enfin la norloge auquel il répond, s'il y a lieu).
C'est bien ça?
[^] # Re: En fait...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Tout à fait!
L'heure à laquelle le message a été rédigé est aussi est utile, mais juste à titre informatif (tiens machin< qui poste une connerie à 5h du mat, il devait rentrer d'une soirée arrosée).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: En fait...
Posté par vlamy (site web personnel) . Évalué à 3.
Ok, donc effectivement le problème réside dans la décentralisation des bases de données.
A ce propos, j'ai une question : pour le moment le projet est de répliquer les bases de données à l'identique, non?
C'est déjà énorme comme projet, mais je n'appelle pas ça décentralisé, plutôt réparti. Effectivement, répliquer une base de données, pour moi ça ne passe pas à l'échelle : en gros avec plus de 1000 bases de données (voir bien avant), on commence à se poser des questions.
Enfin je ne dénigre pas du tout ton projet, je trouve déja énorme que tu ais réussi à faire un prototype qui tourne. C'est juste que pour avoir du vrai décentralisé, il faudrait taper dans une table de hachage distribuée (DHT), en guise de base de données, du style Chord, Pastry ou Kademlia (voir Dynamo pour un exemple d'implémentation, qui est à la base de S3 chez Amazon).
Et là, on perd le relationnel (fini SQL) et on se trouve avec une base de donnée clef/valeur (une table de hachage quoi).
Pour approfondir sur les BDs décentralisées, si ça intéresse quelqu'un, je vous propose de regarder Cassandra (un projet libre Apache). C'est ce qui à l'air de se rapprocher le plus d'une BD distribuée libre et largement utilisée.
[^] # Re: En fait...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ce n'est pas vraiment de la réplication de base de données, mais plutôt de l'échange et du stockage de messages avec des liens entre eux (les fameuses norloges).
Le fait que je détourne fossil pour cet usage créé sans doute beaucoup de confusion :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: En fait...
Posté par barmic . Évalué à 3.
Je comprends mal ton exemple. La partie content. On a l'utilisateur charlie qui dis « Bonjour Charlie » en réponse à un message de garspard qui dis « Bonjour Charlie » ? Pourquoi un coup l'identifiant est de la forme d'un email et la fois d'après c'est un username ?
Les 2 premiers identifiants identifient des messages alors que les deux de la partie content identifient des utilisateur, c'est ça ?
Que représente le $norloge ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: En fait...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
La conversation présenté sous la forme d'une tribune classique devrait être:
gaspard étant un multi de charlie que alice a grillé!
Je me suis gouré, ça devrait être la même chose.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: En fait...
Posté par barmic . Évalué à 2.
Quel esprit torturé… :) Tu prend toujours les exemples les plus tordus possibles pour illustrer tes idées sans explications ?
Ok donc si le message de bob se perd ou arrive après celui d'alice. Tu va l'ajouter dans l'historique (c'est spécial d'un point de vu utilisateur), maintenant si le message de charlie ou garspard se perd tu fait comment ?
Sinon c'est mignon de recréer un balisage dans du json. Ça permet de se fader deux parsers dont un à partir de 0 ^
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: En fait...
Posté par vlamy (site web personnel) . Évalué à 2.
L'avantage c'est qu'en recevant le message d'Alice, tu connaîtra l'existence de ces deux messages, donc soit tu les attends (quitte à demander une retransmission) avant d'afficher le message d'Alice, soit tu affiches le fait qu'il manque des messages.
Enfin c'est mieux que de ne pas savoir qu'il manque un ou des messages.
[^] # Re: En fait...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Non, j'ai l'habitude de me gourer et d'inventer des justifications ensuite :-)
Les messages qui n'arrivent pas dans l'ordre "logique" pour un utilisateur, ça arrive tout le temps avec olcc en mode multitribune, avec les mails, avec n'importe quelle messagerie en fait!
Chaque participant conservant les messages, pour qu'ils soient perdus, il y a peu de cas où ça peut arriver (Le disque dur Charlie meurt sans sauvegarde avant d'avoir pu envoyer le message par exemple).
En plus dans le cas de la messagerie instantané, un message n'est pertinent que pendant un laps de temps. "Salut on bouffe ensemble ce soir?" par exemple n'a plus de valeur le lendemain :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: En fait...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4.
Il ne peut pas y avoir de cycles dans un réseau
IRC.[^] # Re: En fait...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Le but c'est de décentraliser un système existant, pas d'en inventer un ou d'en utiliser un autre.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Newebe
Posté par rakoo (site web personnel) . Évalué à 4.
Tout ça me fait furieusement penser à Newebe, qui a l'avantage d'utiliser une base de données faite pour la synchronisation : Couchdb. HTTP, support de la notification, tout y est =]
[^] # Re: Newebe
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Sauf un chat.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Newebe
Posté par BAud (site web personnel) . Évalué à 4.
ça ferait fuir les noiseaux (leur logo…).
# pourquoi que la tribune
Posté par fredix . Évalué à 3.
Pourquoi se contenter de décentraliser une tribune et pas un site web complet ? Ainsi il pourrait y avoir des instances de linuxfr un peu partout et lorsqu'un article, journal, commentaire est posté sur l'une d'elle c'est synchronisé avec les autres.
[^] # Re: pourquoi que la tribune
Posté par Arthur Geek (site web personnel) . Évalué à 4.
Oui, le web2p, voire l'Internet2p. Chacun hébergerait ses propres commentaires, avec des miroirs éventuels. Et moins de peering à la clef (à terme). Cela dit, on se rapproche des GNUNet et consorts.
Prochainement, je vous proposerai peut-être un commentaire constructif.
[^] # Re: pourquoi que la tribune
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Le système d'évènements de Fossil est déjà un blog decentralisé. Il manque les commentaires…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pourquoi que la tribune
Posté par vlamy (site web personnel) . Évalué à 2.
Honnêtement, un projet comme ça , ça me fait fantasmer. J'ai eut fait une thèse dont le sujet se rapproche un peu (P2P et compagnie). S'il y a des gens sérieux pour tester quelque chose, je suis chaud bouillant :)
[^] # Re: pourquoi que la tribune
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Est-ce que ce n'est pas proche de ce que propose friendica ou newebe?
Il y aussi Retroshare qui propose du clavardage (ça vous apprendra à faire des blagues sur les chats) et des forums décentralisés.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pourquoi que la tribune
Posté par vlamy (site web personnel) . Évalué à 2.
J'avoue ne pas savoir comment marche friendica et newebe, je veux dire côté serveur.
Je vais faire remonter l'inspection de ces solutions dans ma todolist, mais elle a tendance à croître de façon exponentielle en ce moment :)
[^] # Re: pourquoi que la tribune
Posté par fredix . Évalué à 3.
Je travaille sur un projet libre et je voudrais atteindre cet objectif, mais j'ai pas fais de thèse :)
La plus grosse difficulté étant de développer un protocole de synchronisation entre des instances, sachant que certaines instances pourrait ne pas avoir suffisamment d'espace disque pour tout stocker.
[^] # Re: pourquoi que la tribune
Posté par vlamy (site web personnel) . Évalué à 1.
Si tu acceptes les contributions/remarques/relectures ça m'intéresse. Enfin si jamais je peux t'apporter quelque chose…
C'est tout à ton honneur :) En fait, je dis ça parce que j'ai bouffer 4 ans de théorie, ça fait 2 ans environ que je bosse sur autre chose (rien à voir avec le p2p) et j'aimerais bien essayer de coder un truc concret (et libre) un jour en p2p.
Je vois bien le problème, mais il y a peut être moyen de faire quelque chose quand même, avec des caches, de la hiérarchie ou encore des codes de compressions…etc
Bref, autant d'idées théoriques qui peuvent aussi être hors contexte tant qu'on a pas un truc concret devant les yeux.
[^] # Re: pourquoi que la tribune
Posté par fredix . Évalué à 2.
Je taff sur le projet nodecast qui est en gros un ordonnanceur générique de jobs asynchrone. L'idée est d'envoyer des payloads vers l'API HTTP qui seront traités par des workers selon un workflow défini. Les payloads peuvent être du JSON ou bien un binaire qui seront stockés dans GridFS.
De fait ces payloads peuvent être du texte, images, vidéos. L'intelligence est donc dans les workers qui seront quoi en faire. Ce principe permet de scaler facilement car on peut lancer un poll d'un même worker, nodecast se chargeant de loadbalancer sur le premier de libre.
En plus d'un serveur HTTP, nodecast embarque aussi un serveur XMPP et FTP et bientot un tracker bittorrent (donc un serveur HTTP dédié à cette tâche). Avec ce type d'outils il doit être possible de répondre à toutes sortes de besoins aussi bien pour des applications web que natives.
Par exemple je souhaite développer un outil de partage de fichier intégrant un réseau social. Le réseau social serait fourni par le serveur XMPP, le FTP permettrait d'uploader un gros fichier, générer un torrent par un worker, le transmettre à ses contacts via XMPP puis le seeder et mettre en liaison les peers via le tracker.
Pour un simple site web, l'API HTTP générique pourrait stocker ses données et lui fournir. Il resterait à savoir comment synchroniser des noeuds nodecast. Telehash semblait prometteur pour ça mais le code ne bouge plus. Il y a aussi LSD basé sur Zyre basé sur ZeroMQ.
Bref, beaucoup de rêves encore, mais si tu aimes le C++ .. :)
[^] # Re: pourquoi que la tribune
Posté par vlamy (site web personnel) . Évalué à 2.
Bon, déjà je suis une quiche en C++, mais bon ça c'est pas grave à la rigueur.
Et pour LSD : je suis payé pour développer un concurrent direct, libre et français, de ZeroMQ : Joram (quelqu'un connait?).
Juste pour dire que j'aurai du mal à partir sur LSD, même si la solution est très bien :)
Cela dit, pour moi zeroMQ n'a rien de réellement décentralisé, sans avoir étudié dans les détails non plus.
Je regarderais un peu plus en détail et je te dirai ce que j'en pense, mais quand je vois des trucs comme Kademlia dans Telehash, je commence à penser qu'on se rapproche du vrai décentralisé et non pas de ce que j'appellerai de la redondance (BD répliquée sur tous les nœuds à l'identique, par exemple). Mais c'est ambitieux, c'est sûr !
[^] # Re: pourquoi que la tribune
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Pour ma part, je ne connais pas mais je me dis que ça mériterait sûrement une dépêche sur LinuxFr.org ;-)
[^] # Re: pourquoi que la tribune
Posté par vlamy (site web personnel) . Évalué à 1.
Oui, je suis bien d'accord, je pense que ça va venir :)
[^] # Re: pourquoi que la tribune
Posté par fredix . Évalué à 2.
Ok pour java, perso je suis allergique :)
Pour le P2P le mieux est peut être d'utiliser une DHT, via une lib comme bitdht ou tomP2P
[^] # Re: pourquoi que la tribune
Posté par vlamy (site web personnel) . Évalué à 1.
Je suis loin d'avoir fait le tour, mais j'ai regardé telehash : ça à l'air pas mal !
Après as-tu une spec? ou un cahier des charges vite fait? Histoire de savoir sur quoi on part.
Car en fait, on peut mettre du p2p à plusieurs niveaux (stockage partiel ou total, caches, partage de bande passante, …etc) et avec plus ou moins de difficulté et de pertinence.
J'ai pas non plus les idées claires sur ce qui est fait et ce qui reste à faire :)
Mais ça va venir.
[^] # Re: pourquoi que la tribune
Posté par fredix . Évalué à 2.
Telehash ca me semble bien mort. Sinon j'ai pas de spec ni rien mais j'ai du code qui tourne en prod :)
Je pense que je me pencherais sur l'aspect P2P lorsque tout le reste sera stabilisé et documenté, donc pas pour demain …
[^] # Re: pourquoi que la tribune
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Soit ma grille de bizness-loto n'est pas à jour (peut-être normal, je suis en 10.04 LTS), soit je suis trop vieux pour les nouvelles technologies (peut-être normal, je suis en 10.04 LTS). De mon temps, on avait Usenet, le mail et IRC pour réseau-socialiser, c'était simple et facile. De nos jours, tout change trop vite.
Enfin, c'est le monde moderne, il faut faire avec :)
# Chemin inverse
Posté par Paul . Évalué à 3. Dernière modification le 26 janvier 2013 à 15:05.
Salut devnewton
Pour une communauté web d'environ beaucoup de gens, j'ai justement envie de passer d'une tribune à un système avec prosody et Candy. Pour alléger le serveur web et permettre aux gens de se connecter depuis des clients sur leurs PC/tablettes/smartphones.
Du coup je suis curieux de savoir quelles sont les raisons exactes qui te font partir de jabber ? C'est si compliqué que ça à administrer ? Je compte lier prosody à la BDD du forum pour l'authentification.
[^] # Re: Chemin inverse
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le problème de Jabber, c'est surtout les clients. Le clavardage de groupe y est souvent la cinquième roue du carrosse.
Pour alléger un serveur, je ne suis pas certain que ça marche si tout le monde se connecte via un client web. Le module tribune de Drupal propose du push via nodejs pour ça, mais je ne l'ai pas essayé.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Chemin inverse
Posté par Paul . Évalué à 2.
Candy est un javascript, sans PHP : tout se passe directement entre le navigateur et le serveur jabber configuré en Bosh.
OK pour les clients, j'avais pas pensé à ça. Je vais regarder quand même.
[^] # Re: Chemin inverse
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Il faudrait faire des tests pour comparer les performances d'une tribune via websocket et de XMPP via Bosh.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# mnesia
Posté par totof2000 . Évalué à 3.
mnesia le fait semble-t-il assez facilement.
Après, je ne sais pas si elle est limitée par rapport aux spécifications que tu donnes, mais quand on me parle base de données distribuées, je pesne de suite à ça.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.