En lisant d'un œil distrait le flux RSS de LWN je suis tombé sur un article sur un nouveau protocole nommé Matrix. Bon je suis moyennement convaincu par la pertinence du nom mais bon passons.
Donc l'idée est d'avoir un nouveau protocole de discussion de groupe (style IRC) fonctionnant avec une fédération de serveur.
Là normalement vous vous dites : "Encore un nouveau protocole de chat, pourquoi ne pas utiliser XMPP ou IRC ?". Bon déjà vous faites ce que vous voulez (et moi aussi), et les mecs peuvent bien créer un nouveau protocole si ça leur chante. Bon après je trouve qu'ils ont trouvé un concept qui enfonce les deux concurrents sus-cités. Si j'essaye de résumer ce que j'ai compris :
- il y a un ensemble de serveur qui communiquent entre eux, sans autorité centrale
- les utilisateurs sont enregistrés à un serveur donné (jusqu'ici c'est comme XMPP)
- la fonction de base c'est d'avoir desgroupes de discussion (un MUC/channel quoi)
- les serveurs gèrent de manière distribué l'historique (complet) des MUC sous la forme d'un graphe orienté acyclique de message (un peu comme git)
- quand un utilisateur envoie un message à son serveur, le message est inscrit dans le graphe, puis le graphe est fusionné entre les serveurs
- après la fusion des graphes, les serveurs envoient les nouveaux messages à leurs utilisateurs respectifs.
Du coup on se retrouve avec gestion vraiment décentralisé (sans single point of failure) de MUC avec historique. Et c'est une chose qui n'est pas faisable avec XMPP ou IRC (sans modification profonde de leurs fonctionnement actuel évidement). C'est plutôt utile : par exemple plus besoin de rester AFK dans un chan IRC juste pour savoir ce qu'il ci passe, pas de perte non plus quand il y a un problème technique quelconque , pas de netsplit entre les serveurs (enfin plus exactement on peut retomber sur un état fusionné), on peut monter son propre serveur (en authentifiant les employés de sa boite par exemple) mais quand même participer dans tout les autres serveur et pas besoin de se prendre la tête avec cette hydre à douze têtes qu'est XMPP avec son obligation de s'abonner entre utilisateur (qui n'est qu'une des multiple façon dont on peut vouloir fonctionner).
Pour troller un peu, je trouve l'approche beaucoup plus élégante qu'XMPP. Perso, ce qui me gène avec l'Extensible Messaging and Presence Protocol c'est justement son coté extensible : genre le système de MUC est complétement défini à coté du système de discussion normale. Alors que la discussion normale ne permet pas réunir plus de deux personnes, franchement ICQ le faisait déjà au millénaire précédent… Alors que si un protocole est conçu pour gérer la discussion à plusieurs de base, c'est trivial de rajouter une fonction de message privé sur la base définie. Mais là ils ont fait l'inverse et ça se sent quand on utilise les MUC. Et puis vraiment cette histoire de rendre le protocole extensible c'est gentil, mais au final on se retrouve avec une galaxie de logiciels client et serveur dont aucun ne gère proprement le même ensemble de fonctionnalités.
Après si on compare avec IRC, ben c'est simple dans IRC il n'y a pas de décentralisation, pas de gestion de l'identité et pas d'historique des channel. Alors évidement il y a des solutions pour pallier ça mais c'est toujours des fonctions rajoutées par dessus le protocole de base.
Voilà pour ce que j'en ai compris, perso je suis bien emballé par le concept de base. Reste à voir comment ça va prendre. D'ailleurs tout ça est encore en alpha.
# 2015, Usenet réinventé
Posté par lolop (site web personnel) . Évalué à 10.
:-)
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: 2015, Usenet réinventé
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6.
/me jette un 119 sur lolop.
[^] # Re: 2015, Usenet réinventé
Posté par Arathorn . Évalué à 1.
Je pense que tu veux plutôt dire un 8448 ;)
# Un peu plus sur la matrice...
Posté par Amandine . Évalué à 10.
Merci outs pour la présentation!
Pour répondre à Lolop c'est vrai que c'est très proche de usenet mais temps réel, encrypté de bout en bout (bientôt dispo), fédéré de manière ouverte (si c'est la bonne traduction française d'open federation), avec contrôle d'accès (ACLs) et APIs HTTP. On supporte aussi la VoIP en utilisant WebRTC: Matrix fait le signalling, et peut donc permettre à plusieurs services WebRTC de se parler entre eux si ils utilisent tous Matrix.
Donc avec un peu de chance on a réussi à améliorer usenet en le réinventant! :)
Un autre point intéressant est que le chat de group n'est qu'un cas d'usage de Matrix qui en fin de compte permet la synchronisation et persistance de n'importe que type de donnée JSON, un peu comme une grosse base de donnée distribuée et "eventually consistent" (qui finit toujours par être synchronisée?)… Comme une grande matrice!! :)
[^] # Re: Un peu plus sur la matrice...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'espère que le chiffrement est du niveau de cryptocat.
"La première sécurité est la liberté"
[^] # Re: Un peu plus sur la matrice...
Posté par Amandine . Évalué à 2.
Quand la crypto bout-en-bout existera, oui c'est le but: au moins aussi bon que cryptocat.
[^] # Re: Un peu plus sur la matrice...
Posté par rakoo (site web personnel) . Évalué à 4.
Je dois avouer que quand j'ai lu ça, je me suis mis à imaginer un système où chaque admin hébergerait un CouchDB, dans lequel les clients pousseraient leurs messages, et les différentes instances à travers le monde se synchroniseraient les unes aux autres; toute l'infrastructure étant déjà faite, il "suffirait" de rajouter les bouts d'authentification pour en faire un système de messagerie fonctionnelle…
… Et puis j'ai lu la spec, et je me suis dit que ça ne devait pas être aussi simple que ça. En tout cas, la combinaison HTTP+JSON est à mon avis un atout majeur face aux autres protocoles, parce que ça veut dire que des clients pourront plus facilement être écrits pour le navigateur. J'attends de voir ce que tout ça va donner !
[^] # Re: Un peu plus sur la matrice...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
C'est déja plus ou moins en chantier, mais avec une license un peu étrange : http://www.nemoweb.net/
# Fosdem
Posté par Benjamin Henrion (site web personnel) . Évalué à 3.
Le gars etait au Fosdem:
https://fosdem.org/2015/schedule/event/deviot04/
Sa demo sur le chat decentralise etait bluffante.
# Le Libre, c'est le choix, mais...
Posté par Maclag . Évalué à 10.
Aujourd'hui, XMPP est somme toute un succès. Malgré cette assertion, il reste encore beaucoup à faire: transformer l'essai sur les réseaux sociaux, convaincre les acteurs propriétaires d'ouvrir les communications entre serveurs, etc.
Bref, il reste encore beaucoup de boulot.
Là, on nous annonce un nouveau protocole qu'il va tout déchirer. Et je me dis que même s'il est vraiment bon, il n'arrive pas au bon moment: XMPP n'est pas encore assez obsolète pour qu'on lui cherche un remplaçant, et pas encore assez solide sur le marché pour ne pas souffrir de la concurrence d'un autre protocole ouvert dans l'écosystème du Libre.
Du coup quand je lis que Matrix fait des choses qu'il aurait été impossible de faire dans XMPP sans modif majeure, je me demande si les modifs auraient été plus majeures que:
Les protocoles, ce n'est pas comme les applis: 120 applis qui utilisent le même protocole contribuent plus ou moins dans la même direction.
Chaque nouveau protocole Libre réduit les chances d'adoption en masse d'un protocole Libre.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par rewind (Mastodon) . Évalué à 9.
Le fait de préciser «somme toute» montre bien qu'en fait, ce n'est pas vraiment le succès espéré. Ça reste une niche.
Ça fait à peu près 15 ans que XMPP (ou son ancêtre Jabber) existe. S'il reste des choses à faire, c'est qu'à un moment donné, il y a quelque chose qui ne tourne pas rond.
Est-on condamné à devoir utiliser XMPP parce que c'est libre ou alors est-ce qu'on peut inventer d'autres protocoles de 0 et qui seront tout aussi libre et qui ont des chances d'avoir plus de succès que XMPP ? Les défauts de XMPP sont connus et rien ne change pour les corriger, au contraire, on dirait presque des features maintenant. J'aurais été à leur place, j'aurais fait exactement pareil.
Imaginons qu'ils aient voulu implémenter leur protocole par dessus XMPP. Déjà il faut se farcir toutes les XEP pour voir s'il y a des choses qu'on peut réutiliser. Ensuite, il faut écrire sa propre XEP. Ensuite, si on est sérieux, il faut l'implémenter et donc se farcir toutes les couches basses de XMPP. Quel gain là dedans ? Quasiment aucun.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Une niche ? Cherche un peu des trucs comme ejabberd ou sametime pour voir si c'est une niche.
Je suppose donc que quelque chose ne tourne pas rond avec HTML, Javascript, Python, C, C++, Java, Perl, Linux, LibreOffice, Gimp, Apache… bon j'arrête là je crois.
Personne n'interdit qui que ce soit à faire autre chose. Il y a certes des défauts dans XMPP, on y travaille, mais ceux que je vois ne sont jamais cités.
Tu trouves ça mal de réutiliser des choses ? Tu n'utilises jamais une bibliothèque, un protocole standard, ou… un logiciel libre ?
Oui enfin ça c'est quand on veut faire un truc générique qu'il n'est pas encore possible de faire, c'est quand même assez rare (j'ai écrit ma première XEP cette année alors que je bosse avec XMPP depuis plus de 7 ans).
Bon aller je vais me coucher, je reviendrai troller demain :)
[^] # Re: Le Libre, c'est le choix, mais...
Posté par gnx . Évalué à 3.
Hum… s'il faut chercher, c'est que c'est bien une niche.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Maclag . Évalué à 6.
C'est un demi-échec qui a été utilisé par Google et qui est, à ma connaissance, toujours utilisé par Facebook.
On a vu pires, comme références.
Le "somme toute" tempère ces succès par le fait que Google l'a laché et que FB ne participe pas à la fédération.
On pourrait parler des moyens qui y sont consacrés par rapport à d'autres, de la lenteur du processus de standardisation, ou tout simplement se dire que Linux existe depuis plus longtemps et je n'ai pas l'impression qu'il ne reste rien à faire.
Il y a 15ans, la visioconf, c'était pas un requis, par exemple.
Sur un marché économique, on sait qu'une solution techniquement meilleure qui arrive un peu plus tard peut mourir simplement en raison de son retard sur le marché, pas de ses qualités techniques. Dans le Libre, ça peut simplement prendre plus de temps.
Encore une fois, je ne dis pas que Matrix est mal ou que c'est une mauvaise idée, je déplore qu'on invente un énième protocole.
Les défauts de XMPP sont connus et ce qu'on change pour les corriger c'est pondre un nouveau protocole qui aura lui aussi des défauts de jeunesse et qui aura besoin d'un bon bout de temps avant d'avoir un écosystème autour de lui.
J'ai du mal à croire que "se farcir toutes les XEP" soit plus long et compliqué que réécrire tout ce dont on a besoin de 0. Surtout qu'on parle ici d'un protocole qui pourrait utilisé des briques éprouvées plutôt que des nouvelles. Un bogue dans un protocole, ça me semble autrement plus chiant que dans une implémentation particulière.
Encore une fois: XMPP a ici l'avantage de son ancienneté.
De même, "se farcir toutes les couches basses de XMPP" est-il vraiment un chemin de plus grande résistance que d'inventer et implémenter de nouvelles couches basses?
Enfin, plus bas, il est écrit que Matrix est plutôt complémentaire que concurrent à XMPP, et que les 2 seront interopérables.
On verra bien, donc.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par barmic . Évalué à 4.
Ouai mais leur implémentation sont pourris (pas de fédération par exemple). Donc oui, ils l'utilisent mais on est loin d'un vrai succès pour XMPP.
Ça montre bien l'un des gros problèmes de XMPP : le protocole pars dans tous les sens et multiplie les XEP et ça produit un tas d'incompatibilités. Ça détruit tout l'intérêt d'un protocole ouvert et documenté.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le Libre, c'est le choix, mais...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Si Google implémente XMPP comme un pied, ce n'est pas vraiment la faute des XEP…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par barmic . Évalué à 3.
Le fait de devoir utiliser un fork précis de tel ou tel serveur pour pouvoir se servir de SàT et que coté client ça marche entre pas et mal avec pidgin et empathy par exemple c'est pas le propre de ce qu'on trouvait à l'époque d'MSN et des clients qui ne supportent que partiellement ce que fait le client officiel.
Sincèrement, il ne faut pas être surpris que les gens se foutent de ce protocole puisqu'ils se retrouvent à utiliser le sous ensemble de fonctionnalité qu'on retrouve à peu près partout. Cet ensemble de fonctionnalités, c'est envoyer et recevoir des messages en direct dans des conversations à 2 avec la possibilité de mettre en forme ses messages. Pas de quoi faire rêver…
Oui il y a pleins de trucs qui marchent lors des démo, mais il faut avoir les conf qui vont bien, les logiciels en dernière version, etc.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Tu te trompes. Certains clients ont choisi en effet de privilegier un fork de prosody, à savoir metronome, pour le microblogage; mais nous (SàT) avons décidé de faire notre propre service pubsub et avons proposé des XEP pour pouvoir les utiliser avec tous les serveurs. Je pense qu'une fois que les implémentations marcheront (c'est quasi certains qu'il y en aura au moins pour prosody et ejabberd, et ça ne m'étonnerait pas d'en voir dans OpenFire), il n'y aura aucun soucis pour utiliser n'importe quel serveur.
Mais ceci ne concerne que le microblogage, qui est en plein développement. Pour tout le reste, ça fonctionne à l'heure actuelle sans soucis avec n'importe quel serveur et n'importe quel client. Je communiquais jusqu'à la semaine dernière sans soucis avec gtalk par exemple, client et serveur différents des miens. Je ne sais pas où ça en est, ils ont annoncé la fermeture hier.
Oui il faut souvent activer les trucs pour des raisons de sécurité/performance. Par exemple les privacy list (extension qui permet de dire qu'on ne veut pas recevoir tel type de message, pas envoyer par exemple notre présence à telle personne) sont désactivées par défaut dans prosody pour des raisons de performances. C'est pareil sur ton serveur: tu n'as pas un serveur HTTP, FTP, SMTP, etc activés d'entrée de jeu.
Aussi en ce qui concerne SàT particulièrement, on répète à chaque fois que ce n'est pas encore une version « grand public », parce qu'on se concentre sur le dév et qu'on n'a pas encore arrondi les angles. Quand on sortira la version « grand public », on passera par une phase de beta avec tests sur les différents serveurs, avec le plus de clients possibles, etc. C'est long, oui. Mais il faut rappeler qu'on n'est que 2, qu'on a décidé de travailler sans actionnariat ou levée de fonds, qu'on refuse d'utiliser FB et Zozio pour communiquer, et qu'on doigt bosser sur plusieurs fronts en même temps (les standards, le service pubsub, parfois les serveurs, les différents frontaux, les rencontres et évènements, le site web, les trolls sur DLFP, etc).
[^] # Re: Le Libre, c'est le choix, mais...
Posté par rewind (Mastodon) . Évalué à 6.
En plein développement… pour XMPP. Twitter, le roi du microbloggage, va bientôt sur ses 10 ans quand même. XMPP arrive toujours après la guerre, c'est ça aussi qu'on peut lui reprocher. Déjà pour la messagerie instantanée, il a fallu attendre des plombes avant d'avoir quelque chose de fonctionnel et quand on l'a eu, MSN (et tous les réseaux IM) était en train de sombrer au profit de Facebook. XMPP est en retard chronique. Si j'étais très médisant, je dirai que SàT sera prêt quand Facebook sera en train de sombrer, remplacé par une autre techno plus à la mode.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
Twitter est centralisé. Si tu veux le comparer, compare le à Elgg. C'est autrement plus simple de faire un truc centralisé (sans renier le travail sur ces logiciels).
XMPP tu peux le comparer à Diaspora ou Gnu Social (Status Net), et je crois qu'il n'a pas trop à rougir de ce côté. Surtout que son évolution dans un sens dépend de l'intérêt des développeurs, et l'intérêt pour le microblogage est plus récent que celui pour la visio par exemple.
Autant pour XMPP je ne trouve pas que ça soit un problème que ça mette du temps, parce que c'est un truc fait pour durer et pas être un effet de mode, autant pour SàT c'est différent: effectivement on met beaucoup plus de temps que ce qu'on avait prévu. C'est une chose courante dans l'informatique, et ce n'est pas parce qu'on glandouille mais parce qu'on a des problèmes à résoudre au fur et à mesure, et que quand on a fait un truc à la va vite, on essaye de bien le refaire plus tard.
C'est plus gênant parce qu'on a 2 problèmes: ceux qui viennent tester en s'attendant à avoir un truc fonctionnel, et notre propre motivation. Ceux qui viennent tester en général ça va quand on explique le pourquoi du comment (et que ça pourrait aller plus vite avec des coups de mains), pour notre propre motivation il y a des haut et des bas. En ce moment on fait des trucs chiants: construire une base solide pour le microblogage. Je pense que c'est la dernière ligne droite avant de construire les trucs vraiment sympa, et que si on fait ça suffisamment bien ça va être super.
Mais c'est difficile de bosser régulièrement, d'expliquer à famille et amis pourquoi on fait ça, de ne pas se décourager quand on passe une semaine sur un truc qu'on pensait faire en une aprem, de ne pas vouloir faire trop de bruit trop tôt par risque de déception, mais pas trop tard non plus parce qu'on va avoir besoin d'en vivre et d'avoir une motivation extérieure.
Bref oui, pour SàT c'est gênant que ça mette du temps (surtout maintenant), je pense qu'on est vraiment proche d'une vraie version grand public (pas la prochaine version mais la suivante), qu'on n'a pas du tout à rougir par rapport à ce qui se fait à côté, mais on a besoin de bouger rapidement pour notre propre motivation.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Larry Cow . Évalué à 3.
Justement : Status Net, ça fait au moins 4 ou 5 ans que ça fait (faisait?) des trucs qu'XMPP a encore du mal à faire en matière de microbloggage. C'était tout sauf parfait (en termes de permissions notamment), mais ça juste-marchait.
Côté XMPP, on a eu des trucs très encourageants (Jappix à ses débuts est celui qui m'a le plus bluffé, mais d'aucuns citeraient Movim ou SàT). Et puis, alors qu'on aurait raisonnablement pu espérer que l'ensemble de l'écosystème profite de la dynamique et que tous les µblogs se parlent indépendamment des clients et des serveurs … ça reste très laborieux. Pas pire qu'il y a 4-5 ans, mais on ne sent pas vraiment arriver le moment où on pourra le conseiller à tata Michue.
Et ce n'est pas spécifique à SàT du tout (d'autant que si j'ai bonne mémoire tu n'es pas loin d'être le dernier arrivé).
C'est pareil pour la voix/vidéo. Il y a quelques années, avec Jingle, ça allait marcher. Toutes les implémentations allaient converger vers la même version du standard et tout le monde pourrait se parler. On a remis le couvert quand, poussé par Jitsi, est arrivé Jingle Nodes : Skype n'aurait plus qu'à bien se tenir. Et là, en 2015, quand je dois proposer une alternative au-dit Skype je suis bien emmerdé : c'est encore les solutions WebRTC qui s'en tirent le mieux (chapeau bas à SubRosa qui m'a donné de très bons résultats récemment, d'ailleurs).
Des super-clients comme OneTeam ont disparu des radars. Les serveurs XMPP les plus utilisés sont en train de changer de crèmerie. Jitsi, qui faisait partie des plus dynamiques des clients "génériques", ne bouge plus bien fort et sa dernière version vend vraiment du rêve : support d'IRC, support de Java 8, un nouveau codec et un splash screen (je caricature un peu, il y a beaucoup de boulot côté bugfix, mais ça n'est pas vraiment révélateur d'une phase d'expansion).
J'aime l'idée d'XMPP, j'ai joué le jeu longtemps, j'ai évangélisé comme j'ai pu. D'aucuns peuvent témoigner que j'étais même "grave chiant" avec ça, à pas vouloir faire comme tout le monde, et à vouloir en mettre partout. J'y croyais, et j'aimerais pouvoir dire que j'y crois encore. Sauf que, si je suis lucide, c'est de plus en plus difficile d'y croire.
Ce n'est que trop vrai, hélas.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Ils ont aussi un mode de fonctionnement différent: ils ont leur propre trucs, ils ne standardisent pas, et il y avait une boite derrière si je ne m'abuse, avec un certain nombre de dévs. Ils ont eu leur heure de gloire, mais j'ai l'impression que identi.ca a fait une belle erreur en passant à pump.io.
Le problème c'est toujours le même: on n'est pas beaucoup aidés. Donc on avance, mais lentement (enfin pas tant que ça vu le nombre de choses qu'on doit gérer). Movim c'est pareil, il y a 1 dev principal.
Jitsi ils étaient au Fosdem, y'avait une dizaine de personnes, c'est pas trop mal tout de même. Ils font des conférences à plusieurs avec vidéo, il n'y a pas beaucoup de logiciels qui permettent ça à ma connaissance.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Larry Cow . Évalué à 4.
Jusque-là, tout le monde a toujours un peu l'impression que ceux d'en face ne standardisent pas. Pour un développeur non-XMPP, une XEP c'est pas un standard (en tous cas pas plus que la spécification de StatusNet). Bon après, certains ont vraiment fait les gorets avec leurs spec', genre Diaspora à leurs débuts.
C'est vrai, mais c'est le cas aussi chez certains acteurs XMPP (OneTeam, IgniteRealtime, …). Et si tu veux du microbloggage tout seul et sans boîte, il y avait le Friendika de l'époque qui correspondait assez. Bref, ça existait.
J'ai l'impression qu'ils ont fait pas mal de belles erreurs, en fait. Pump en est peut-être une, je connais assez mal. En revanche, avoir voulu à tout prix intégrer de la confidentialité dans un modèle qui ne s'y prêtait pas (et qui ciblait Twitter qui n'en avait guère non plus de toutes manières), ça a probablement tué StatusNet.
C'est vrai, et je plaide coupable. Ceci étant, si on considère la raison pour laquelle on s'est mis à parler d'XMPP ici, il y a peut-être un élément de réponse dans le caractère extrèmement formel d'une contribution XMPP "utile" : je peux toujours faire un truc perso pas standard dans mon coin, mais si je veux être un bon citoyen XMPP il faut que je me farcisse une XEP, que je la défende, maintienne, etc.
Alors que si je veux contribuer à RedMatrix (pour en citer un que je connais), il me suffit d'aller discuter le bout de gras avec le développeur principal, de faire un pull request, et c'est parti : j'ai contribué et tout le monde en profite.
À vouloir être un standard et/ou un écosystème avant d'être un produit, XMPP tend à n'être qu'une solution pour développeurs, pas pour utilisateurs. Or, les développeurs libres sont très souvent d'abord des utilisateurs.
Matrix, le sujet de ce journal, ils ont eu la bonne idée de faire une implémentation de référence. Alors on sait comment ça se passe, il y a toutes les chances que celle-ci reste durablement la seule et unique implémentation, et que les contributeurs soient davantage contributeurs à cette implémentation qu'au standard. Certes. Mais fonctionnellement, ça ne sera qu'un demi-échec : Matrix évoluera quand même. Chez XMPP, il me faut choisir : soit je contribue à SàT, soit je contribue à Movim, soit je contribue à Jitsi… avec à chaque fois des technos radicalement différentes, et pas de "leader" qui se dégage. Et si je veux implémenter MES idées avec MA techno, la marche est considérable, sans garantie de pouvoir échanger plus avec l'écosystème que du chat texte et de la présence.
Fut un temps, j'ai cru que ça pourrait décoller. On voyait sortir des nouvelles librairies XMPP facilitant le boulot, et se lancer dans un nouveau client promettait de devenir "simple". On mettait du Web plein dans XMPP, et c'était cool. D'aucuns ont commencé à pousser XMPP (+BOSH) comme LE protocole pour remplacer AJAX. Là encore, la sauce n'a pas pris et WebSocket+WebRTC rendent les atouts d'XMPP-on-the-Web non-déterminants.
En libre, non, clairement. Il y a Subrosa, dont je parlais un peu plus haut. Mais le problème reste toujours le même : la connectivité coûte cher, et personne n'est prêt à en faire cadeau à des clients sans contrepartie.
Après, je vais être honnête : Jitsi, c'est probablement le "produit" le plus bandant pour un utilisateur lambda, et ce de tout l'écosystème XMPP. Notamment par son côté couteau suisse, dont le fait qu'il sache aussi parler le SIP. Tu vois où je veux en venir?
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Oui enfin XMPP ça passe par l'IETF, y'a des RFC, et le processus pour les XEPs est parfaitement décrit. La plupart des XEPs sont en expérimental ou deferred, et ça n'est pas standard dans ce cas. C'est pas tout à faire pareil qu'un bout de document (je ne sais pas ce qui est dispo pour status.net). Mais une documentation sur le protocole moi ça me suffit, même sans passer par les organismes, et ça déjà c'est très rare en dehors du monde XMPP.
Friendica est toujours là, ainsi que redmatrix, le projet lié.
Non, ça c'est si tu veux contribuer au standard, et c'est un cas plutôt rare
Ben c'est exactement pareil pour les projets XMPP. Il faut bien différencier standard et projets qui l'utilisent. Vient nous voir sur le salon de SàT par exemple (sat@chat.jabberfr.fr), on peut trouver des tas de choses à faire qui sont plus ou moins accessible, et dans beaucoup de domaines différents (dev web, plugin, chiffrement, transfert de fichier, outil en ligne de commande, etc). Surtout que notre archi est modulaire, donc on peut bosser sur des parties isolées.
Si tu veux un truc qui profite à plusieurs projets à la fois, contribue sur une bibliothèque ou sur un serveur.
XMPP est un standard et n'a jamais été autre chose. C'est les logiciels qui l'utilisent qui sont ce que voient (ou pas dans certains cas) l'utilisateur. Il y a des gens qui ne font que du standard, et d'autres que du logiciels (sans même forcément implémenter le standard, des fois il suffit d'utiliser une bibliothèque).
Ce sont des façons de faire différentes, c'est comme pour Kde et Gnome ou Vim et Emacs. Mais tu peux toujours aider les différents projets en même temps, comme dit plus haut.
Comme pour toute techno, il y a un ticket d'entrée, mais je pense qu'apprendre à lire des XEPs et repérer celles qui t'intéressent c'est pas hors de portée du tout. Et après ça s'adapte très très facilement à un cas particulier.
on n'est pas du tout au même niveau. XMPP peut très bien utiliser WebSocket et WebRTC (Movim le fait d'ailleurs).
Pas vraiment pour être honnête.
Enfin bref, vient sur les salons, j'aurais pu t'expliquer très facilement comment contribuer sans se taper des tonnes de docs à lire. En plus quelqu'un entrant dans le projet peut nous aider à documenter en fonction des problèmes qu'il rencontre…
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Larry Cow . Évalué à 5.
C'est aussi un aspect important de l'impopularité d'XMPP, à mon avis. Trop de XEP mort-nées. Ca décourage, et puis ça éclate un peu les efforts : tu sais aussi bien que moi que le fait d'être expérimental ou deferred n'empêche pas d'avoir une implémentation qui marche dans la nature. On a bien vu avec Jingle et Google ce que ça a pu donner.
Je sais bien, je les suis de près. Mais Friendica a changé (au moins) deux fois de noms, sans compter Red (qui a aussi eu son lot de dénominations variables), d'où ma remarque.
Oui et non. Si je m'emmerde à créer un client XMPP pour un besoin, ce n'est pas pour qu'il puisse ne parler qu'à lui (sinon, pour ça, on a des tas de manières plus simples de faire). Je peux me contenter du dénominateur commun d'XMPP (chat et présence), mais il est assez probable que j'ambitionne mieux (après tout, ICQ ça commence à dater un peu). Mais si je veux que mes améliorations soient un tant soit peu acceptées par d'autres clients, pas trop de choix : il faut passer par un XEP (sans garantie d'implémentation, d'ailleurs).
En caricaturant un peu (mais pas tant que ça), aujourd'hui le mec qui démarre un projet à base de XMPP, soit il a besoin d'une XEP, soit il n'avait pas besoin d'XMPP (voire de faire un nouveau projet).
C'est peut-être un problème de communication, mais pour quelqu'un d'extérieur à l'écosystème c'est loin d'être évident. Et même pour moi, qui ait suivi et évangélisé comme un cochon il y a quelques années, c'est parfois (un peu) nébuleux.
FreeDesktop a malheureusement montré les limites de la standardisation "volontaire". Même si XMPP est loin d'être aussi mal barré.
Il y a toujours un ticket d'entrée, mais avec la déferlante WebRTC le ticket d'entrée est cher pour ce qu'il apporte. Si je veux bricoler un truc rapide, je peux récupérer un Conversation.js et me démerder avec "juste" du Web (et un serveur de signaling, mais autrement plus simple que de devoir gérer un serveur XMPP). Si je veux mettre en œuvre du compliqué, l'historique des projets "compliqués" de l'écosystème n'est pas spécialement encourageant (oui, Buddycloud, c'est à toi que je pense).
Et c'est un des points qui me (re)donne un peu espoir. Mais ça reste encore peu répandu.
Alors là par contre, je me marre un peu : venant d'un projet qui préférait (et revendiquait) l'établissement de la connexion XMPP par le serveur, c'est drôle :)
Je ne sais pas comment ils ont évolué, du coup. Je vais aller me repencher dessus.
Simplement au fait qu'une des meilleurs vitrines "concrètes" pour XMPP est un logiciel qui ne se contente pas d'XMPP (pour raisons historiques, certes, mais la partie SIP est encore très correcte et très utilisée, surtout en entreprise).
Bref
Comme d'habitude, je me suis un peu dispersé. Désolé. Je vais essayer de préciser.
Quand Jabber a commencé à bouger, l'idée était très bonne. Proposer un standard qui corresponde à la base de la messagerie instantanée d'alors, avec une possibilité d'extension. Ça aurait pu séduire, et si MSN n'avait pas existé ça aurait probablement été le cas. Pouvoir implémenter des comportements "métiers" par dessus une base commune et compatible avec d'autres logiciels (éventuellement utilisés dans d'autres domaines), c'était de la grosse balle. Et sur le principe, c'est toujours de la grosse balle.
Sauf qu'aujourd'hui, la "base commune" a changé. Chat et présence, même avec la possibilité de salons, c'est très léger par rapport à la concurrence (notamment Skype). Du coup, le "cadre" XMPP n'apporte plus grand chose par rapport à - mettons - un TogetherJS, et ce pour un "coût" technique considérable.
C'est facile de critiquer de ma position de mec qui n'a pas foutu grand chose sur le sujet, je sais. Mais le coche a été raté il y a des années, à mon avis. Il avait été question de définir des profils XMPP, avec des ensembles croissants de XEP à supporter pour se conformer à tel ou tel profil. Je ne sais pas ce que ça a donné de concret, mais imposer un profil avec au moins voix/vidéo/filetransfer comme étant la base aurait pu sauver Jabber. Le simple fait que ces fonctions-là ne marchent pas entre tous les logiciels XMPP qui les implémentent, c'est très mauvais signe.
Et ça ne me réjouit pas, tu peux me croire.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Maclag . Évalué à 3.
Le protocole permet de faire tourner des serveurs hors fédération donc il est pourri?
Un bon protocole, c'est un protocole qui intègre des clauses interdisant de fermer son réseau? Ça c'est un problème de licence, pas de protocole. Excuse-moi de considérer que c'est totalement hors-sujet.
Quant aux XEP qui partent dans tous les sens, quelques messages plus haut, on reproche à XMPP de n'être "pas fini", et là, tu lui reproches d'en faire trop?
Pour moi au contraire, LE reproche qu'on devrait faire à XMPP, c'est la lenteur exaspérante de son procédé de standardisation, qui va toujours moins vite que le reste du monde (y'a qu'à voir la voix/vidéo, ou d'actualité, le microblogage).
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Oui ça c'est un problème, et on a besoin de jouer des coudes pour faire avancer où on veut: PubSub on s'est regroupé pour y arriver, mais clairement on avance maintenant.
Y'a vraiment des gens de tous les domaines (on ne voit déjà pas pareil quand on travail sur un serveur ou sur un client), certains qui font de la recherche, certains qui font de l'internet des objets (donc je ne suis pas fan du tout), certains du pubsub etc. Du coup il y a un gros niveau technique (y'a des sujets où on est facilement largués et on doit se mettre à niveau si on veut suivre).
Par exemple j'avais expliqué dans mon dernier journal que ma proposition de XEP (protoXEP) pour générer des permissions privilégiées avait été refusée parce que ça n'était pas l'état de l'art. On m'a parlé de contrôle basée sur les attributs (Attribute Based Access Control, ABAC) que je ne connaissais pas. J'ai dû me renseigner et lire de la doc technique pour me mettre à niveau et pouvoir discuter correctement, j'ai pu mieux comprendre le refus (même si je ne suis pas forcément d'accord, et d'ailleurs la discussion qui a suivi a été enflammée). Maintenant j'envisage de faire une XEP qui permet de faire de contrôle d'accès par attribut en XMPP, qui pourrait être utilisée comme système de contrôle générique pour les futures extensions. Ça a été beaucoup plus long au final que si j'avais fait le protocole mo même et dit « on fait comme ça point », mais il est possible qu'il en sorte (ou pas) une meilleure solution technique.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par barmic . Évalué à 3.
J'ai dis que c'est la manière dont ils l'ont déployé qui est pourri.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Gtalk est fédéré (enfin était, ils devaient couper hier je ne sais pas si ça a été fait réellement), c'est FB qui ne l'est pas (de ce que j'ai entendu, ça serait en fait une surcouche qui fait une passerelle XMPP - sans fédération -, en interne ça serait un truc maison).
Là où Gtalk avait des problèmes, c'était pour jingle: comme ils ont fait la première implémentation ils ont continué à l'utiliser même après la standardisation (la version standard a mis du temps à sortir, et a évolué pas mal a priori - enfin je n'ai pas encore touché à jingle, donc je ne vais pas trop m'avancer sur ce sujet que je connais mal -). Ensuite ils sont passé à la version standard il me semble.
Effectivement le protocole part dans tous les sens et multiplie les XEP, mais c'est une force et non un problème, et au contraire ça rend les choses compatibles. C'est un protocole de communication, la communication ça sert dans à peu près tous les domaines; une fois qu'on a une base on a 2 options:
chacun utilise la base et fait ça sauce dessus pour ses besoins spécifiques, et c'est la fête (un peu ce qui s'est passé avec HTTP/HTML/Javascript, et la situation s'améliore lentement avec ça)
ou alors quand on a besoin d'un truc dans un domaine, on cherche une solution qui est équilibrée entre facilité d'implémentation et généricité, et on fait une extension au standard en discutant avec les autres pour voir si ça leur convient, c'est ce que fait XMPP avec les XEP.
L'incompatibilité c'est dans le premier cas qu'on la trouve.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par barmic . Évalué à 3.
Excuse-moi mais quand on voit que pour avoir des fonctionnalités un peu différente de la base, il faut un client précis et un serveur précis, non on est plus compatible. Ça pourrait aussi bien être un protocole totalement différents.
Le problème c'est qu'on est arrivé au point où :
Ça ne veux plus dire grand chose. Concevoir ces choses comme des couches est bien plus simple à appréhender (c'est ce qui est fait avec HTTP, SAOP, REST,…). Ça n'empêche en rien de faire les choses de manière ouverte et ça permet à chaque type d'utilisation d'avoir son propre cycle de vie indépendant des autres.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
je t'ai répondu plus haut: c'est faux. Il ne faut pas un client précis et un serveur précis, et pour le microblogage j'ai bon espoir que les 2 dernières XEPs donnent un gros coup d'accélérateur.
C'est un choix des clients aussi. Gajim par exemple se concentre sur le messagerie et la visio, et j'avais discuté il y a un moment avec Asterix (le dév principal), il ne comptait pas faire de microblogage. Mais pour ce qu'il fait il le fait très bien, c'est une référence dans le domaine (je l'utilise en priorité pour tester nos implémentations par exemple). Et il fait tout de même messagerie chiffrée, messagerie de groupe, envoi de fichier et visio, c'est l'utilisation principale de la plupart des gens (j'avoue ne pas avoir trop testé la visio, je ne sais pas ce qu'elle donne).
L'intérêt d'avoir ça au sein du même protocole, c'est que tu as déjà la gestion du compte unique, de la fédération, des extensions, etc. Pas besoin de mettre des couches de colle parfois sales entre les différents protocole. Et d'ailleurs la philosophie d'XMPP est de réutiliser l'existant quand il convient à la tache (Atom est utilisé pour le microblogage par exemple).
[^] # Re: Le Libre, c'est le choix, mais...
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Est-ce que le microblogage ne risque pas de devenir ringard d'ici là?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Les extensions et leur nombre est une force. Il ne faut pas tout lire quand on veut implémenter quelque chose, les extensions sont utiles pour différents domaines et leur nom suffit en général à identifier ce dont on a besoin, + quelques unes qui sont indispensables comme discovery (qui permet de savoir quelles fonctionnalités sont disponibles, ou si on parle à un serveur, un client, un service MUC, un transport, etc) ou data forms (qui permet d'échanger des données de manière standardisées). Ces 2 dernières extensions sont simples à comprendre, et générique elle sont réutilisées partout. Ce qui fait qu'une fois implémentées, il suffit de réutiliser le code pour adapter à un cas particulier (par exemple discovery sert à savoir quelles commandes ad-hoc sont disponibles, ou plus concrètement ça me permet de savoir ce que je peux faire pour administrer mon serveur prosody depuis mon client XMPP).
Quand 2 extensions font la même chose, la meilleure est gardée et l'autre est dépréciée.
Bref, quelqu'un qui utilise XMPP pour commander un robot ne va pas utiliser la même chose que quelqu'un qui fait un logiciel de microblogage, ou que quelqu'un qui s'en sert pour faire du transfert de fichiers. L'intérêt d'avoir tous ces domaines dans des XEPs et qu'on parle la même langue, et du coup on est compatible, on a un seul compte, on peut changer de logiciel, etc. Comme je l'ai dit plus bas, on retrouve la philosophie Unix: chaque XEP fait 1 chose, et la fait bien (et du coup il en faut beaucoup).
Beaucoup d'entreprises utilises XMPP avec des trucs à eux qu'ils ne documentent pas, c'est possible aussi. Ils ont une base solides avec de nombreuses implémentation, et on juste à adapter l'existant à ce qu'il leur faut.
« les couches basses » c'est les RFC (6120, 6121, 6122), et ça n'est pas très compliqué à comprendre. En plus il ne doit pas y avoir beaucoup de langages où il n'existe pas de bibliothèque qui implémente ça.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Amandine . Évalué à 7.
Il faut noter que Matrix et XMPP résolvent différents problèmes. Matrix est dans les faits une base de donnée éventuellement synchronisée avec fédération ouverte et sémantique de pubsub : tout est question de synchronisation d’états.
XMPP est centré sur de la messagerie fédérée, envoyant des stanzas tout autour plutôt que de synchroniser l’historique de conversation. En fait Matrix n’a même pas le concept d’envoi de message dans la fédération en tant que tel, la seule chose que tu peux faire c’est synchroniser la structure de données de l’historique.
Donc pour nous Matrix n’est même pas une compétition de XMPP : tu veux un historique de conversation décentralisé? Utilise Matrix. Tu préfères du transfert de message rapide et « stateless »? Utilise XMPP.
On est aussi en train de développer, entres autres, un bridge XMPP<->Matrix, pour que XMPP puisse fédérer avec Matrix (ainsi qu’un bridge SIP et d’autres), donc ce n’est pas comme si on voulait à tout prix fragmenter encore plus l’écosystème, au contraire : l’idée de Matrix est de défragmenter tout ça et faire interopérer les protocoles qui existent!
# Cette roue roule vachement plus vite !
Posté par lepieru . Évalué à 6.
Le site explique bien le principe. Je vois pas trop l’intérêt de décentraliser une chat room, mais supposons ! Le MUC ne fonctionne pas de cette manière, mais rien empêche de créer une nouvelle extension à XMPP. Après, on peut rediscuter de la vitesse de standardisation du bouzin…
Tout ça pour dire que c'est techniquement intéressant, mais très dommage de devoir encore créer un nouveau compte sur une nouvelle plate-forme pour répondre à un nouveau besoin. XMPP est extensible et ce n'est pas « génant ».
PS: C'est tellement respectueux des standards qu'ils ont changé la manière d'écrire une adresse : @user:machine.net. Bien joué les gars ;)
[^] # Re: Cette roue roule vachement plus vite !
Posté par outs . Évalué à 3.
Ben j'ai vraiment du mal avec cette notion d'extensibilité. Imagine tu prend les principes de Matrix pour en faire une extension du protocole, appelons là XMPP/DistriMUC. Pour autant chacun devra mettre à jour son serveur et activer le sous-protocole XMPP/DistriMUC, fondamentalement c'est quoi la différence avec ajouter un service Matrix sur ton serveur et l'activer ? Si un logiciel client voit passer un message XMPP/DistriMUC et qu'il n'est pas programmé pour l'interpréter c'est exactement comme si il voyait passer un paquet TCP/IP sans savoir l'interpréter. Imaginons que tu ne soit intéressé que par la partie XMPP/DistriMUC, que gagne tu à t'être intégré à XMPP ? Si tu veux utiliser XMPP/DistriMUC tu ne pourrait pas envoyer des messages (sans utiliser de passerelle) dans les salons XMPP/MUC. Après si tu veux bien utiliser une passerelle alors tu peux aussi faire une passerelle avec n'importe quoi d'autre, XMPP ou pas.
Ça a l'air d'être dans l'esprit du standard IRC : dans IRC un login c'est @user donc ca devient @user:machine.net
En fait, on peut toujours dire : oui XMPP c'est extensible donc tu peux faire ce que tu veux avec. Mais ça c'est vrai avec n'importe quel protocole, même si il n'y a pas marqué extensible dans le nom. Il faudra dans tous les cas programmer et distribuer tout les serveur et les client si tu veux que ton extension fonctionne, XMPP ne résout rien à ça. Et le problème c'est bien ça, suffit de regarder une grille de compatibilité d'extension des serveur et client XMPP pour s'en convaincre.
En plus je trouve que la grande question c'est de trouver un protocole qui résout efficacement nos besoin, une fois qu'on pense qu'on a trouvé ce protocole il faut abandonner les protocoles qu'on juge moins bien. Avec un mode de fonctionnement comme XMPP on est condamner à garder le choix initiaux dans le protocole, plus tout un tas d'extension intermédiaire utiles ou pas. Je pense qu'il vaut mieux fonctionner avec un modèle de couche comme dans le modèle OSI ou le modèle TCP/IP car tu peux effectivement remplacer un protocole par un autre.
[^] # Re: Cette roue roule vachement plus vite !
Posté par lepieru . Évalué à -2.
Si tu n'as comme besoin en communication que le chat distribué, je comprends que ça te satisfasse. Perso, je mail, je discute en instantané, je suis des flux, etc. Et j'aime pouvoir faire ça avec le même compte. J'espère vraiment que XMPP s'améliore et se démocratise. Quand on voit des projets comme Movim, cela semble être en bonne voie.
XMPP est vraiment construit de manière à être extensible tout en se permettant d'imposer certaines règles.
Si Matrix évolue, les possibles multiples clients et serveurs vont se patcher tout seuls ? :)
Si tout le monde choisit ses divers protocoles pour ses divers besoins de communication, on vit de moins en moins sur le même Internet.
[^] # Re: Cette roue roule vachement plus vite !
Posté par Frank-N-Furter . Évalué à 10. Dernière modification le 16 février 2015 à 17:16.
WTF? Internet c'est SMTP, IMAP, POP, HTTP, FTP, SSH, XMPP, NNTP, Gopher, etc…
Depending on the time of day, the French go either way.
[^] # Re: Cette roue roule vachement plus vite !
Posté par lepieru . Évalué à -3.
Effectivement, il impose ce XMPP !
C'est un protocole de diffusion décentralisé de message. J'aimerai juste ne pas en utiliser 36 qui fasse le même job :)
[^] # Re: Cette roue roule vachement plus vite !
Posté par outs . Évalué à 3.
En fait on pourrait réutiliser exactement la même argumentation en te faisant remarquer que finalement XMPP réinvente le job des email qui est exactement un protocole de diffusion décentralisé de message.
[^] # Re: Cette roue roule vachement plus vite !
Posté par lepieru . Évalué à 0.
En effet. Niveau décentralisation, c'est le même principe (avec un protocole unique, pas 3).
Mais au niveau des possibilités, on parle plus de la même chose. Le courrier électronique n'est qu'un type de message qui peut être communiqué via XMPP.
[^] # Re: Cette roue roule vachement plus vite !
Posté par Amandine . Évalué à 2.
Matrix /est/ extensible: on permet à n’importe quel type de données et évènements de circuler et à différentes sémantiques d’être définies. Mais on demande une baseline de features interopérable plus élevée que XMPP. Donc en pratique si tu veux utiliser Matrix pour de nouveaux usages (par exemple faire passer du MIDI, comme on a pu le faire au Hackathon Techcrunch) sans changer les APIs client-serveur ou serveur-serveur : tout peut se passer côté client uniquement, et le serveur est agnostique à ce qui passe. Donc tu peux ajouter beaucoup de nouvelles features sans tout mettre à jour. Bien sûr certaines features nécessitent des mises à jour serveur, mais inversement elles peuvent être transparentes pour le client.
[^] # Re: Cette roue roule vachement plus vite !
Posté par Arathor . Évalué à 9.
Pas du tout, irc c’est user@host.tld comme tout le monde. @user ça vient de twitter.
[^] # Re: Cette roue roule vachement plus vite !
Posté par rakoo (site web personnel) . Évalué à 6.
L’intérêt majeur c'est de distribuer la charge et réduire le downtime quand un des serveurs tombe en panne. En fait il y a déjà des propositions de salon de discussion plus ou moins décentralisés, notamment FMUC, qui n'a pas bouge depuis un bail.
Et en fait c'est a peu près la même chose pour tout ce qui est XMPP: il y a un gros effort de fait pour standardiser les pratiques, mais ça prend du temps et on en arrive a avoir besoin une bonne dizaine de XEPs pour des besoins "standards":
Au final ce qui est largement déployé c'est les bouts faciles (messagerie, MUC, web), c'est a dire en fait IRC, fonctionnellement parlant. Des qu'on sort de ces cas d'utilisations (plusieurs clients qui doivent avoir leur historique synchronise, le mobile fiable, la VoIP…) ça a encore du mal a prendre parce que tout le monde doit se farcir l'ensemble des XEPs. Et a ma connaissance, il n'y a pas de liste de XEPs minimum a implémenter pour avoir un client correct.
Ben justement, non. Tu peux te créer ton compte sur ton nœud, ou utiliser un identifiant externe qui sera traduit en identifiant utilisable dans matrix, comme ton addresse email actuelle par exemple.
[^] # Re: Cette roue roule vachement plus vite !
Posté par lepieru . Évalué à 0.
Très juste, ça prend beaucoup de temps. Un peu comme designer une nouvelle solution from scratch…
C'est ce que j'appelle créer un compte sur une nouvelle plate-forme :)
# L'historique automatique est-il vraiment un avantage ?
Posté par Zatalyz (site web personnel) . Évalué à 6.
Sur IRC, j'aime bien que le log des conversations ne soit pas automatique. Parfois, c'est sympa d'avoir une discussion "éphémère", qui ne concerne que les présents, qui n'a de sens que dans l'instant présent, et qui n'a pas besoin d'être archivée. Y'en a même certaines qu'il vaut mieux ne pas archiver ! Les projets ayant besoin de garder un historique peuvent facilement mettre en place un bot qui logue et publie ces logs sur un site (même moi, j'y suis arrivée, c'est dire si c'est difficile :p ), il y a suffisamment d'outils pour ça. On a le choix : garder un historique ou non. Et si un AFK squatte un canal où on a envie de délirer sans prise de note, c'est facile de le kicker.
Du coup, est-ce que sur Matrix, c'est possible de désactiver cet historique si on souhaite des conversations éphémères ? Si ce n'est pas le cas, c'est une feature à envisager sérieusement. Avec la politique de flicage intensif pour tout et n'importe quoi, c'est même un argument publicitaire, de ne pas avoir d'historique !
[^] # Re: L'historique automatique est-il vraiment un avantage ?
Posté par Amandine . Évalué à 2.
Oui le propriétaire d'une room peut configurer une option pour limiter la taille de l'historique stocké sur les serveurs participant à cette room (l'option n'est pas encore implémentée mais elle est prévue).
L'encryption bout-en-bout (quand elle sera dispo) est aussi une bonne protection pour limiter l'accès de l'historique aux participants prévus.
# Et toujours pas de norloge...
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Vous êtes bien gentil d'inventer des protocoles raivolutionnaires, mais des discussions à plus de deux personnes sans norloge, ni même du threading, c'est aussi mort que JP2.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et toujours pas de norloge...
Posté par Arathorn . Évalué à 1.
il ya des norloges depuis le début (hover-dessus pour les voir), et le threading est en version 2 (voir "relates-to" en https://github.com/matrix-org/matrix-doc/blob/master/drafts/general_api.rst).
[^] # Re: Et toujours pas de norloge...
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
norloge != horloge cf https://linuxfr.org/board
Je ne comprends pas qu'en 2015 on puisse créer un protocole de messagerie sans ça de base.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et toujours pas de norloge...
Posté par Arathorn . Évalué à 1.
D'accord, maintenant je comprends. Déposée comme demande de fonctionnalité a https://matrix.org/jira/browse/SYWEB-290
# Mais quel beau site !
Posté par stopspam . Évalué à 4. Dernière modification le 16 février 2015 à 23:29.
Ça n'a rien à avoir mais je trouve toujours aussi amusant le contraste entre les sites officiels :
tout pourrisans fioriture d'un serveur qui poutre.# XMPP, Matrix, Fosdem, toussa
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
On était voisins au Fosdem (« lounge » XMPP et Matrix), on a pu un peu discuter, et j'ai assisté à la conf. Je voulais en parler dans un résumé du Fosdem que j'avais commencé à écrire, mais au final je n'ai pas eu le temps et je suis passé à autre chose (et puis bon faut se remettre du rigodon de Dunkerque).
Le projet m'a eu l'air intéressant, pas nécessairement impressionnant (je n'ai rien vu de vraiment nouveau), mais prometteur. Je vais sûrement suivre ça. Malgré la jeunesse du truc, ils ont réussi à faire déjà pas mal de choses, mais il faut aussi relativiser: les gens ont applaudi pour la visio avec WebRTC, alors qu'à mon sens c'est plutôt les mozilla and co qu'il faut applaudir pour ça. J'ai aussi eu l'impression qu'il y avait un rejet de XMPP que je trouve dommage (comment peut on critiquer le côté extensible ? C'est justement ce qui rend le protocole est génial). Je renvoi au commentaire de Jehan qui démontait pas mal d'idées reçues.
Donc à mon sens Matrix est un projet prometteur à surveiller.
Maintenant revenons en à XMPP, vu que nous avons aussi été au summit qui précédait le Fosdem. Je vois, comme souvent, une méconnaissance ou mauvaise compréhension de XMPP dans les commentaires ici. XMPP est un protocol très simple qui se base sur 3 types de données (les stanzas):
<message/> pour les requêtes de type j'envoi est j'oublie
<iq/> pour les requête de type question/réponse (avec réponse obligatoire)
<presence/> pour les données broadcastées
une fois qu'on sait ça, on connait l'essentiel. Les extensions, c'est plus ou moins la philosophie Unix: chaque extension gère une chose, et la gère bien (enfin disons que c'est discuté jusqu'à arriver à la meilleure solution possible). et dans toutes les extensions, il y en a très peu qui sont vraiment finales, beaucoup sont expérimentales, soit parfois très éloignées de la version idéale (c'est pour ça que ça discute beaucoup, c'est une des raisons qui rend les nombreux clients avec des façons de faire différentes utiles, c'est pour ça que c'est bien qu'on voit des gens de milieux techniques différents).
XMPP peut parfaitement être distribué (avec un client=1 serveur) et on est beaucoup à envisager ça à terme, c'est déjà possible en réseau local. Après ça n'est pas forcément la solution idéale pour tous les cas d'utilisation, et différents serveurs intermédiaires ça a ses avantages (pour encore faire une analogie: il ne faut pas réinventer l'opposition microkernel et kernel monolithique).
Maintenant quelques sujets qui on été abordés au summit:
le chiffrement de bout en bout, mais c'est un vieux sujet dans XMPP, qui a du mal à trouver une solution qui marche bien. Pour le moment il est question de documenter l'utilisation actuelle d'OTR, d'éventuellement faire une XEP qui adapte OTR à XMPP. Il est question de faire un prochain summit dont c'est le sujet principale, avec hackathon dans la foulée.
des discussions sur un MUC 2 (Multi-Users Chat, les conversations à plusieurs type IRC). Il semble qu'on arrive à un MUC basé sur les mécanismes PubSub, avec une fédération facilitée.
On parlé aussi d'un MUC sans présence, une équipe fait des expérimentation avec ça. L'intérêt est surtout pour les téléphones où on se connecte/déconnecte souvent. Enfin pour moi on réinvente surtout PubSub, je ne suis pas convaincu de l'intérêt
Nous avançons sur PubSub, comme je l'avais expliqué dans un précédent journal. D'ailleurs la deuxième XEP dont je parlais dans ce journal est passée juste avant le summit, et en Belgique on a pu avoir pas mal de contacts pour nous aider, l'année 2015 devrait être particulièrement intéressante. Au passage edhelas nous a fait une démo de l'appli Movim pour Android, c'est très sympa.
Bref, ça bouge. XMPP est très utilisé, et ce n'est parce que Gtalk va (est ?) fermer qu'il est mort. Ejabberd arrive à en vivre, Jitsi arrive à en vivre, Mongoose IM arrive à en vivre, Buddycloud arrive à en vivre, Prosody arrive à en vivre, OpenFire arrive à en vivre, etc. Sans parler de toutes les applications de messagerie à la mode qui sont 9 fois sur 10 du XMPP avec des extensions proprio.
Bon je ne vais pas faire un roman parce que je vais me coucher, mais je trouve très bien qu'il y ait des expérience sur de nouveaux protocole, et de nouvelles idées. Ceci dit, je doute fort de voir quelque chose arriver au niveau de XMPP tant en terme de possibilités que de clients/serveurs avant longtemps.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.