Salut à vous,
ce journal fait plus ou moins suite à celui sur le XMPP summit à Berlin. C'est un peu technique mais ça devrait être compréhensible. L'idée est de montrer comment ça se passe de l'autre côté du logiciel.
Donc pour résumer: nous sommes plus ou moins 4 (Binary un développeur russe, Edhelas de Movim, et Souliane et moi de « Salut à Toi ») à essayer de pousser PubSub (Publish Subscribe) en XMPP pour corriger les derniers problèmes et avoir un système de (micro)blogage décentralisés. Au niveau de « Salut à Toi » (SàT par la suite), nous avons décidé que nous passerions nos propres blogs sur le projet pour la prochaine version. La XEP de Binary est passé en « experimental » (première phase vers la standardisation) et porte le numéro 0351. De mon côté j'avais publié une première XEP: « privileged component », et j'en avais une deuxième prévue.
Avant de parler des XEP, expliquons un peu le problème: PubSub est un peu le parent pauvre de XMPP. La XEP est conséquente, peu de serveurs l'implémentent complètement, et il nous manque presque toujours une fonctionnalité pour pouvoir l'utiliser avec nos projets. Notamment, pour le microblogage, il faut implémenter « Personal Eventint Protocol » (PEP), une version simplifiée de PubSub, et qui permet en particulier d'avoir un service PubSub par compte (pour être plus clair: normalement il faut trouver un « nœud », une sorte d'adresse, pour accéder à un service PubSub, avec PEP il suffit d'avoir son jabber id (jid) soit une information qu'on a déjà quand on connait le contact).
L'implémentation de PEP pose problème sur pratiquement tous les serveurs: soit c'est lent, soit incomplet, soit les 2 :). En plus de cela sur SàT nous implémentons une fonctionnalité non standard (pour le moment) qui permet d'envoyer des microblogs à un groupe en particulier (uniquement les amis ou uniquement la famille par exemple), l'équivalent des « cercles » ou des « aspects » qu'on trouve par ailleurs.
Pour résoudre ce problème, il y a principalement 2 options: se concentrer sur un serveur avec une équipe de dév à l'écoute, c'est ce que font Jappix et Movim en recommandant Metronome (même s'ils fonctionnent plus ou moins avec d'autres serveurs), ou alors faire un service PubSub/PEP indépendant du serveur qui implémente tout ce dont on a besoin, c'est ce que nous avons choisi pour SàT.
Côté service PubSub, nous avons eu de la chance en ayant une bonne base avec Idavoll, une implémentation de PubSub faite par Ralph Meijer lui même (un des auteurs de la XEP PubSub), utilisée notamment par Apple pour les notifications dans Mac OS X, et qui en plus utilise les mêmes technologies que SàT (Twisted et Wokkel - du même auteur -). Le projet n'est plus actif, et nous voulions implémenter des choses non standards, aussi nous l'avons forké dans le projet SàT PubSub.
Nous avons donc notre service PubSub qui implémente ce que l'ont veut, mais comment l'interfacer avec les serveurs XMPP ? XMPP définit un protocol pour « brancher » un service (un composant) sur un serveur, c'est la XEP-0114. Le problème est que c'est aussi limité qu'un client normal (or il nous faut accéder à des données sensibles comme les contacts - ou roster - d'une entité), et que ça ne permet pas de remplacer le service PEP du serveur lui même: c'est impossible avec les XEPs actuelles de XMPP.
Notre première solution, actuellement en place sur la dernière version de SàT, était d'utiliser des bidouilles avec Prosody: détourner un module existant (remote-roster) pour accéder au roster d'un contact, et simuler PEP en associant un nœud à une entité. Problème: c'est sale, et ça n'est plus standard, donc nous ne pouvons pas communiquer avec Movim et Jappix.
L'autre solution, que nous avions en tête depuis très longtemps mais il fallait trouver le temps, c'était d'écrire les XEPs qui nous manquent pour faire les choses proprement.
Ces XEPs sont donc 2: « privileged entity » qui permet de donner des permissions importantes à une entité, et « namespace delegation » qui permet de faire traiter par une entité externe un espace de nommage normalement réservé au serveur (PEP dans le cas qui nous intéresse).
L'écriture d'une XEP est un exercice peu amusant, et qui demande une certaine rigueur. Il faut penser aux problèmes d'implémentation, de sécurité, etc. Il faut être ouvert aux critiques qui ne manqueront pas sur la liste « standard ». La tradition veut que l'ont utilise les personnages de « Romeo et Juliette » pour donner les exemples. Des conseils de style sont donnés dans la XEP-0143, et on télécharge sur le dépôt XMPP les sources des autres XEP que l'on peut utiliser comme modèle, ainsi que le fichier xep.xsl qui permet la transformation via XSLT en XHTML. J'ai écrit sur mon blog un billet qui donne une astuce pour avoir l'aperçu en temps réél, en utilisant Konqueror, D-Bus et inotify.
Une fois une première version obtenue, on la soumet à la XSF en envoyant un courriel à l'« editor team », qui place alors la XEP dans le dossier inbox en attendant que son statut soit décidé à une réunion XSF. Il faut indiquer explicitement qu'on possède les droits sur la XEP et qu'on les donne à la XSF, afin que celle-ci puisse publier sous licence libre. Ceci s'accompagne d'un message sur la liste standard, et des premières réactions qui sont parfois enthousiastes, parfois moins, et qui s'accompagnent en général de critiques techniques/corrections à apporter ou discuter.
Ensuite c'est l'attente d'une réunion du « council » qui décidera par consensus si la XEP peut passer à l'état « experimental » et ainsi avoir un numéro officiel. En attendant, on peut renvoyer des versions mises à jour en fonction des retours, qui s'accompagneront d'un nouveau message sur standard et de nouveaux retours.
J'ai dû rappeler plusieurs fois sur le salon de la XSF qu'on était dans l'attente d'une évolution pour les XEP. La semaine dernière, il y a enfin eu une réponse de la XSF:
4) Accept http://xmpp.org/extensions/inbox/namespace-delegation.html
as Experimental?
Dave and Fippo +1, Lance, Kev and Matt to vote onlist5) Accept http://xmpp.org/extensions/inbox/privilege-component.html as
Experimental?
Kev, Lance, Fippo, Matt to vote onlist. Dave -1 to post
reasons/resolutions to standards@
Traduction: « namespace delegation » ils sont plutôt favorables mais on attend encore des votes, « privileged entity » Dave a mis un veto (le -1), et doit fournir des explications sur ce qui le dérange. Nous sommes à plusieurs mois depuis le début de l'écriture des XEP, et c'est bien sûr très décevant de voir un veto sur l'une d'elles. Bien que nous n'ayons pas encore les explications officielles, j'ai pu discuter avec Dave sur le salon de la XSF, ce qui le dérange c'est qu'il y a déjà des XEP qui gèrent des permissions à un autre niveau, comme security labels et qu'il pense qu'il faudrait unifier tout ça sur un standard existant, comme XACML. C'est une remarque sensée, mais j'ai peur qu'on n'ait pas de solution avant des années avec un protocole aussi complexe à intégrer, alors qu'une XEP comme la mienne peut toujours devenir obsolète une fois une meilleure solution disponible.
Voilà où on en est, on attend encore du mouvement de la XSF pour savoir quoi faire, et après il faudra penser aux premières implémentations expérimentales (dans Prosody), puis à l'implémentation dans SàT. La partie code n'a pas encore été touchée et il y a déjà eu beaucoup de travail, mais c'est le prix à payer si on veut faire les choses proprement et durablement.
En même temps, nous avons repris contact avec Ralph Meijer pour essayer de remettre sur pieds Idavoll: nous aimerions un service PubSub générique utilisable par tous les projets, pas uniquement par SàT, et tous les serveurs. Notre stratégie est d'expérimenter dans SàT PubSub, et de remonter dans Idavoll une fois les choses standardisées et propres. Nous cherchons à remonter du code de SàT vers Wokkel également.
Encore un long journal, je ne sais pas si ce genre de journaux techniques vous intéressent. La prochaine fois je pourrai vous parler de nos déboires avec Pyjamas (Transpileur Python/Javascript) et de notre besoin de factoriser le code entre les frontaux.
# typos
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Malgré une relecture, je vois encore des typos:
à essaye ==> à essayer
L'écrite ==> L'écriture
Si un modo peut les corriger: merci.
j'en avais vu d'autres mais je ne retrouve plus. Et faut que je me mette un peu au boulot :).
[^] # Re: typos
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
les autres (merci souliane):
l'interfacer avec les serveurs PubSub ==> l'interfacer avec les serveurs XMPP
en attendant que leur statut ==> en attendant que son statut
[^] # Re: typos
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Encore, encore !
Posté par dzecniv . Évalué à 7.
C'est super intéressant, merci.
J'attends avec grand grand intérêt ton retour d'utilisation de Pyjamas !
[^] # Re: Encore, encore !
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 6.
Tout pareil. Tes journaux sont très intéressants, surtout continue !
[^] # Re: Encore, encore !
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
Ben je peux te faire une version courte: le projet en lui même est très bien malgré quelques défauts de conception (il teste les fonctionnalités par navigateur comme ça se faisait avant, alors qu'aujourd'hui il faudrait plutôt tester par fonctionnalité directement). Python est relativement bien géré, parfois c'est pas les bonnes exceptions qui pètent, parfois le code n'a pas le comportement attendu (en particulier nous avons eu des soucis avec __getattr__ et les setters). Mais une fois qu'on a l'habitude, on s'en sort pas trop mal.
Le gros problème, c'est que ça n'est plus maintenu suite à une des plus lamentables engueulades que j'ai vu sur un projet libre: au lieu de partir et de forker proprement le code, un des dév qui avait accès au serveur a détourné le serveur et a inscrit de force tout le monde (dont moi) sur une autre liste, j'avais raconté ça dans un commentaire et dans un journal.
Sans savoir les raisons exactes de la dispute (enfin dans les grandes lignes ça ressemble surtout à des gamineries), nous nous refusions de soutenir le fork et ses méthodes, aussi nous avons pris contact avec Luke, et essayé de pousser pour faire revenir Pyjamas sur le rails et le paquet dans Debian (qui avait disparu entre temps parce que plus compilable). En poussant un peu Luke a rouvert un site (http://pyj.be) et nous l'avons aidé à re-soumettre un paquet à Debian. Malheureusement le paquet n'est pas passé (il fallait vérifier les licences pour des images, moi je n'ai plus eu le temps de m'en occuper, et Luke a l'air trop débordé également), et Luke n'a pas renouvelé le domaine, donc aujourd'hui on est à nouveau au point mort, et le fork sur github ne semble pas en meilleur état.
Bref, Pyjamas est un super projet, mais mort à cause d'un fork sale. D'autre part il a quelques petits défauts, et est bloqué en python 2.7 (il faudrait tout réécrire pour passer en python 3.x).
Pour le moment nous gardons donc la version actuelle qui a 2 ans mais marche relativement bien, et nous sommes en train de réfléchir à la suite. Nous envisageons plusieurs options, nous sommes en train de les étudier en ce moment même:
maintenir pyjamas nous même, ça risque d'être difficile, et on restera bloqués sur les défaut mentionnés plus haut
trouver une alternative: nous avons Rapydscript qui est un précompilateur javascript avec une syntaxe à la Python - un Pyjamas très très simplifié - que nous regardons, et Meduse un transpileur Python/Dart (Dart pouvant se transpiler en javascript) qui a l'air très prometteur. Problème: Pyjamas ce n'est pas que le transpileur, c'est aussi le framework, la transition risque d'être difficile
réecrire la partie navigateur entièrement en javascript: on aurait la maîtrise, mais on perdrait la factorisation du code avec les autres frontaux, ça serait dommage
créer notre propre transpileur sur mesure: un pyjamas très simplifié, en gommant ses défauts et en partant directement sur Python 3. Ça serait du boulot, mais çe ne me semble pas insurmontable, surtout que Python fourni déjà pas mal d'outils (un module standard gère déjà l'arbre syntaxique). C'est la solution qui me plait le plus parce qu'intéressante techniquement, et surtout on peut envisager de transpiler tout le code y compris la partie serveur, dans l'optique de faire une vraie application pour Firefox OS.
Dans tous les cas, on y réfléchit, mais ça sera sur plusieurs mois, en parallèle, et on garde la version actuelle de Pyjamas pour le moment.
P.-S.: ben c'était pas si court finalement :)
[^] # Re: Encore, encore !
Posté par lolop (site web personnel) . Évalué à 3.
Une autre alternative à regarder peut-être, Brython, http://brython.info/ qui permet de faire tourner le Python 3 dans le JavaScript.
Ça a été lancé par Pierre Quentel, un breton (d'où le nom !-).
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Encore, encore !
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
ah intéressant en effet, j'avais vu empythoned, mais c'est encore un projet mort.
Par contre je m'inquiète un peu des performance, dans la console j'ai fait un import os, ça a mis plusieurs secondes…
[^] # Re: Encore, encore !
Posté par lolop (site web personnel) . Évalué à 3. Dernière modification le 16 décembre 2014 à 15:42.
Faudrait voir une fois le premier import fait, car il faut au démarrage compiler en JavaScript les modules utilisés (est-ce que JavaScript gère un cache?).
Et voir les exemples dans la gallerie: http://brython.info/gallery/gallery_fr.html
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Encore, encore !
Posté par flan (site web personnel) . Évalué à 2.
Merci pour l'info, ça a l'air vraiment pas mal !
Je souffre à chaque fois que je dois faire du JS, et il y a des chances que je doive recoder une appli en Python + Qt (avec PySide) en JS…
Je me demande si je ne vais pas essayer avec Brython.
[^] # Re: Encore, encore !
Posté par reynum (site web personnel) . Évalué à 4.
Pourquoi resteriez vous bloqué sur ces problèmes ?
Est il si difficile de passer de Python 2 vers 3 ?
J'ai un peu utilisé Pyjama en 2009 et c'était déjà prometteur comme projet, le voir mourir me peinerais, mais bon…
kentoc'h mervel eget bezan saotred
[^] # Re: Encore, encore !
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
C'est plus compliqué que passer le script 2to3 dessus, y'a tout le compilateur à porter, regarde cette discussion: https://groups.google.com/forum/#!searchin/pyjamas-dev/python$203/pyjamas-dev/v9ouzQJsohY/Bm01sI79DiYJ en particulier:
Aussi j'ai rapidement regardé le code de pyjamas, et c'est relativement complexe, je pense que rien qu'entrer dans le code demanderait un gros investissement, surtout qu'il n'y a plus vraiment de liste de diffusion ou de point de contact pour trouver de l'aide (et je ne veux toujours pas utiliser le fork, qui de toute façon est mourant aussi).
Par contre en écrivant le notre depuis zéro, on peut éventuellement réutiliser le framework (même si je pencherais plutôt pour en réécrire un plus proche de la page HTML finale).
Rapydscript semble une solution possible, faut voir ce que ça donne avec un projet comme le notre.
Après c'est aussi que ça serait un bon terrain d'apprentissage de repartir de zéro, le problème étant principalement le temps qu'on peut y consacrer…
# XSF, XEP et XMPP
Posté par Bruce Le Nain (site web personnel) . Évalué à 7.
Toi, enfin plutôt vous (en tenant compte des autres développeurs cités) qui connaissez bien le workflow de XMPP, certes on peut dire qu'il y a un énorme travail de stabilisation et de sécurisation non négligeable. Mais le protocole ne risque-t-il pas de mourir par l'extrême lenteur/rigueur et manque (apparent) de réactivité de la XSF (évidemment, c'est facile à dire, ce sont des bénévoles, peut-être pas nombreux et sûrement pris par des tas d'autres choses en parallèles), dans le sens ou justement des développeurs motivés pourraient finir par jeter l'éponge par découragement.
Je ne critique pas du tout les bonnes volonté, c'est juste un feeling depuis plusieurs années, que le JSF devenue XSF, par son processus de workflow interminable sapait un peu involontairement l'intérêt des développeurs impliqués dans l'amélioration du protocole. J'espère me tromper :)
[^] # Re: XSF, XEP et XMPP
Posté par Goffi (site web personnel, Mastodon) . Évalué à 9.
Je crois qu'il y a du monde salarié, pas que tu bénévolat, loin de là ! Par contre le problème est surtout qu'ils n'ont pas les mêmes priorités que nous, et du coup ils ont plus envie de se bouger sur l'internet des objets que sur PubSub.
Après oui ça sape un peu le moral, surtout de voir un veto, mais il y a d'autres choses qui ne sont pas agréables (par exemple je viens de me voir refuser 2 conférences au FOSDEM, la XSF n'a même pas de devroom cette année ! 2 ans de suite, XMPP n'est plus à la mode visiblement :( ).
Le moral est effectivement difficile à garder, surtout qu'on cherche à vivre du projet et qu'on met plus de temps que ce qu'on avait prévu. Mais on a aussi des succès, des gens enthousiastes, des choses qui avancent bref des choses qui nous motivent.
Dans notre cas on a créé l'association et ouvert le compte en banque, là on a tout juste obtenu la mise en place d'un système de paiement des cotisations en ligne, il nous reste à refaire le site web et sortir la prochaine version, et on devrait voir l'activité enfin monter un peu.
On a quand même envie d'arriver vite à quelque chose utilisable par le public.
Alors oui le XSF il faut la pousser un peu pour qu'elle aille dans notre sens (c'est sûr c'est plus facile quand on s'appelle Google), mais c'est pas le plus démotivant et on en a vu d'autre, pour le moment le moral tiens bon :).
On a aussi souvent des discussions de fond, plus « politiques », qui nous permettent de penser que ce qu'on fait est utile, et ça c'est important.
Bref, moral mis à part, le protocole est tout à fait moderne, et s'adapte aux nouveautés finalement assez bien (dernier exemple en date: les websockets). Alors oui y'a plus l'effet de mode comme on peut en voir avec bitmessage, twister ou tox, mais au final c'est un ensemble beaucoup plus complet, et qui pourra être distribué totalement un jour (comprendre sans serveur intermédiaire). Donc non au final, il vaut mieux prendre son temps et bien faire les choses.
[^] # Re: XSF, XEP et XMPP
Posté par edhelas (site web personnel) . Évalué à 6.
Étant développeur du projet Movim j'attends également énormément des ces XEP. C'est assez frustrant d'avoir à "attendre" la norme pour pouvoir bien faire les choses au lieu de tout faire dans notre coins et perdre la compatibilité avec les autres.
De mon point de vue je vois la messagerie instantanée d'aujourd'hui comme était le Web au début des années 2000 : fragmenté, bourré de "trucs maisons/proprio" et quasiment impossible à unifier. Ici je parle surtout de la flopée de clients de messagerie qu'on a aujourd'hui : WhatsApp, Skype, BBM, iMessage… Et comme le Web a l'époque on avait un standard porté par le W3C qui avait du mal à évoluer à cause de ces différentes pressions (navigateurs utilisant des normes maison, peu de changement, omniprésence de gros acteurs).
Ce qu'on cherche ici à faire (SàT, Movim, Jappix…) c'est de pousser la norme pour offrir aux utilisateurs tout ce qu'ils souhaitent par dessus un protocole standard et universel. Tant qu'on aura pas ce déclic (une masse critique pour être pris au sérieux selon moi) on aura pas la possibilité de pousser cette norme et on restera dans le monde ultra fragmenté qu'est l'IM aujourd'hui.
Mozilla pourrait être, au même niveau qu'avec Firefox pour le Web, l'acteur qui pourrait créer ce déclic. Ils pourraient implémenter correctement XMPP dans Thunderbird, ne pas partir sur des solutions maison pour la messagerie de Firefox, essayer de rapprocher WebRTC et XMPP… mais bon ils ont pas l'air de comprendre que y'a pas que le Web qui a besoin d'utiliser des standards.
D'ailleurs quand je parle de XMPP en tant qu'IM je le limite aussi à tord. XMPP permet aujourd'hui de faire bien plus que de l'IM. Dans Movim par exemple nous voulons montrer qu'on peut l'utiliser en tant que protocole Social et ainsi standardiser des choses aussi basiques que "le flux d'actualité", "des groupes de partage"… XMPP pourrait également à terme remplacer l'email (le structure du réseau est très proche, mais la norme est beaucoup plus moderne et propre que notre bon vieux combo SMTP/POP/IMAP), l'implémentation dans Thunderbird pourrait ici avoir du sens (un bug a été ouvert là dessus d'ailleurs).
Et pour répondre à ta question, oui les processus de standardisation de la XSF sont long et comme disait Goffi nous n'avons pas les mêmes priorités. Donc des fois c'est un peu difficile de montrer vers quoi nous souhaitons faire tendre le protocole.
Par dessus ça on est pas aidé par les autres clients et serveurs XMPP qui pour la plupart ne respectent que peu XMPP (oui oui, mêmes les clients "de référence" libres). Pidgin ne supporte que très peu PEP, Gajim a de fâcheuses tendances à spammer l'utilisateur lorsqu'on utilise Pubsub, la XEP Bookmarks n'est pas utilisée correctement (donc non il n'y a pas de synchronisation entre clients, c'est pourtant pas très compliqué, c'est juste une liste de liens à récupérer et enregister sur le compte du contact…). Coté serveur Goffi l'a bien montré, le support de PEP et Pubsub est bien souvent inexistant, pourtant nous avons réellement besoin de tout ça pour commencer à construire ce que nous souhaitons par dessus.
Donc oui vouloir bien faire les choses en utilisant la norme demande du temps, temps qu'on pourrait passer sur nos projets à construire ce que nous souhaitons.
# Explications sur le veto
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
Pour ceux que ça intéresse, Dave vient de poster ses explications sur son veto: http://mail.jabber.org/pipermail/standards/2014-December/029378.html
(protoXEP c'est « privileged entity », la XEP que j'ai proposé, on appelle protoXEP les XEPs qui ne sont pas encore dans le processus de standardisation, c.-à-d. qui n'ont pas encore de numéro officiel).
[^] # Re: Explications sur le veto
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
Suite a une longue discussion sur la liste standard@ et sur le salon XMPP de la XSF (et la lecture de specs), j'ai pu mieux comprendre les arguments de Dave (membre du conseil qui a mis le veto), et je dois reconnaître que je suis d'accord: il souhaite une approche plus moderne, basé sur un nouveau modèle: Attribute Based Access Model (ABAC), beaucoup plus souple et qu'on pourra réutiliser ailleurs. Problème: c'est aussi un modèle beaucoup plus compliqué, mais ça peut valoir le coup d'essayer de l'introduire dans XMPP.
J'étais assez déçu car je pensais que le veto était définitif et que je pouvais jeter mon travail à la poubelle et attendre at vitam eternam avant de pouvoir faire ce que je veux (un composant PEP externe), mais après discussion, Dave a également mis de l'eau dans son vin, et je viens de re-soumettre une XEP très édulcorée (beaucoup plus simple et restrictive), mais qui fait ce que je veux. On va voir si elle va passer mais j'ai bon espoir.
Je songe aussi à m'attaquer à l'ABAC moi même, mais ça risque de prendre du temps…
En tout cas on a un bon exemple de l'intérêt de critiques techniques, même si ça n'est pas toujours agréable pour l'ego, et le travail qu'on doit jeter. Au final, et si ça se fait vraiment, on devrait se trouver avec une meilleure solution technique dans XMPP.
[^] # Re: Explications sur le veto
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 19 décembre 2014 à 09:46.
Une des 2 XEPs a été publiée (Namespace Delegation): XEP-0355, la première XEP, ça fait un petit quelque chose :'o) .
Pour la deuxième j'ai assez bon espoir, et si tout va bien, on ne devrait plus être dépendants des implémentations des serveurs pour le microblogage et ce qui tourne autour.
Bon ça reste du expérimental, donc sujet à évolutions.
# L'état de la messagerie instantanée en 2014
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 17 décembre 2014 à 15:49.
C'est peut-être une mauvaise idée de digresser ici, mais je tenais à aborder ce sujet.
Il y a quelques temps, peut-être deux ou trois ans, je pensais m'approcher du Grâal ; en ajoutant quelques comptes à mes paramètres GNOME, je pourrais communiquer avec n'importe lequel de mes potes, qu'ils soient sur MSN, Facebook ou qu'ils aient un compte Gmail, et ce rien qu'avec mon compte XMPP chez l'APINC. Dans le pire des cas, j'ouvrais Skype, et en plus il se disait que Skype allait fusionner avec MSN. En d'autres termes, la guerre semblait gagnée.
Aujourd'hui, quand je veux envoyer un message à quelqu'un, je dois dégainer mon Android, ouvrir le dossier "Messageries" que j'ai crée sur mon lanceur, et choisir l'appli sur laquelle j'aurai le plus de chances que mon correspondant lise mon message - parce que des contacts qui ont Toutes Les Applis, j'en connais, seulement ils n'en utilisent qu'une ou deux régulièrement, et ce n'est jamais la même. J'ai l'impression que les applis libres, comme Empathy qui, chez moi, galère avec Facebook et Hangouts (une histoire d'OAuth apparemment), n'arrivent plus à suivre l'explosion de services de messageries qui n'ont pas du tout l'air interopéables. [EDIT : je viens de lire le commentaire d'edhelas plus haut, où il semble déplorer la même situation]
Aurions-nous régressé en la matière ? Comment les utilisateurs d'XMPP vivent-ils la situation ?
[^] # Re: L'état de la messagerie instantanée en 2014
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Oui nous avons clairement régressé. Non seulement il y a une explosion des services, mais en plus il y a une explosion des services proprio et fermés, la situation est pire qu'à l'époque de MSN et ICQ.
Le courriel n'est plus un outil standard, certains ne consultent même plus, des dinosaures Usenet n'a plus qu'une présence anecdotique (à part pour alt.binaries), par contre IRC est encore très actif dans les projets libres.
XMPP avec son système de transport peut apporter une solution, mais ça n'est plus à la mode (à part spectrum2, et encore je ne sais pas si c'est super maintenu, il n'y a plus beaucoup de passerelles en développement à ma connaissance).
Bref, je pense que les passerelles sont intéressantes pour ce problème, et d'ailleurs on a pour projet d'en développer quelques unes, mais pas pour les services proprio et fermés, ça légitimerait la fragmentation sans rien résoudre.
[^] # Re: L'état de la messagerie instantanée en 2014
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Ils ressentent une grande solitude.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Firefox Hello ?
Posté par Aissen . Évalué à 3.
Je me demandais quels étaient vos avis sur l’arrivée d’un client de messagerie texte/voix/vidéo dans Firefox: Hello.
Je sais que vos objectifs respectifs (SàT, Movim, Jappix) sont de faire bien plus que du chat, mais je me demande quel est votre positionnement par rapport au fait que les 500 millions d’utilisateurs de Firefox vont avoir accès à de la messagerie instantanée p2p chiffrée en end-to-end.
N’est-ce pas une formidable opportunité pour faire du XMPP over WebRTC (à la BOSH ?) ? Est-ce qu’il n’y a pas un risque que Firefox Hello supplante les messageries instantanées basiques (l’espoir fait vivre) ?
[^] # Re: Firefox Hello ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 18 décembre 2014 à 15:39.
Je pense que - si ça marche, on a fait un essai pas encore super concluant -, c'est une très bonne chose: malgré des tentatives régulières, on n'a pas encore trouvé d'outil libre qui fonctionne correctement en remplacement de Skype.
Movim a une implémentation audio/vidéo basée sur webrtc et les technos Mozilla, nous la visio-conférence est assez loin dans nos priorités pour le moment, et du coup on est très contents de voir une solution libre offerte par Mozilla, surtout qu'elle fonctionne sans compte.
En plus XMPP est connu pour aimer discuter avec les autres protocoles (les transports, il est possible de faire communiquer SIP et XMPP), donc je ne vois aucune raison, si le protocole de Mozilla devient populaire, qu'il n'y ait pas de possibilité de communiquer avec XMPP.
XMPP communique déjà un peu avec WebRTC: http://xmpp.org/extensions/xep-0343.html (attention expérimental, donc non vraiment validé), et Movim vient de remplacer BOSH par WebRTC.
Par contre de là à « supplanter » les messageries instantanées je pense qu'il y a un monde (enfin tu as précisé basiques, donc à la limite). Je ne pense pas que leur but est d'avoir un truc aussi puissant que XMPP, et si c'était le cas, ça serait probablement peu pertinent de ne pas utiliser XMPP directement.
Donc pour résumer: je pense que c'est une très bonne chose de voir Hello débarquer, et si le service prend (ce qui serait super), j'espère qu'on pourra rapidement communiquer avec XMPP.
[^] # Re: Firefox Hello ?
Posté par edhelas (site web personnel) . Évalué à 5.
Quelques petites corrections :)
Oui on a une implémentation très très instable de WebRTC dans Movim, d'ailleurs je pense la désactiver pendant quelques temps le temps de retravailler dessus et de la stabiliser (je préfère avoir un truc qui marche bien qu'un machin qui est présent dans l'interface et qui pose des problèmes/marche une fois sur 20).
Par contre Movim n'a pas remplacé BOSH par WebRTC mais par WebSockets ;) On avait de très très gros soucis de performance avec BOSH (qui "transporte" une connexion XMPP classique sur des requêtes HTTP) et le fait de passer à WebSocket nous apport beaucoup de bonnes choses :
- Temps de connexion très rapide, j'arrive même en dessous des clients bureaux comme Pidgin ou Gajim… pour un truc en PHP :D
- Persistance des sessions, vous pouvez fermer votre navigateur, passer sous un tunnel (physique, pour les tutures, je parle pas de VPN là :p), la session restera ouverte (car tenue coté serveur)
- Possibilité de "bourriner" la connexion, BOSH nous imposait une limite "d'une demande à la fois"
Pour mon avis sur Firefox Hello, j'en ai déjà parlé un peu plus tôt dans la discussion. Je pense que Mozilla se plante à vouloir réinventer la roue et que pour une fondation qui défend la neutralité et les standards c'est marrant de les voir ne pas respecter aucune des deux prérequis (neutralité ? non ils sont entrain de créer leur propre protocole, donc on sera dépendant d'eux pour les choix de spécification). Ils ont déjà implémenté XMPP en partie dans Thunderbird donc qu'on aille pas me dire qu'ils savent pas faire la même chose pour Firefox.
Et l'argument de Goffi sur le possible fait d'utiliser un "transport" XMPP pour communiquer avec eux n'est pas bon. Un transport travaillera toujours ne mode "dégradé" (que ça soit au niveau des performances, des fonctionnalités…) du fait d'avoir à convertir un protocole en un autre. Les librairies de transport sont bien souvent en retard et n'implémentent jamais toutes les fonctionnalités du protocole à transporter.
Donc Mozilla, s'il te plaît, il n'y a pas que le Web qui a besoin de standard, de décentralisation et de neutralité !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.