Journal XMPP et (micro)blogage: la donne a changé

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
56
26
mai
2015

Salut à Vous,

Nous venons de faire un énorme pas en avant dans la gestion du blogage/microblogage avec XMPP, aboutissement de plusieurs mois d'efforts, voici quelques explications.

XMPP a de nombreux atouts : protocole standard, stable, largement répandu, décentralisé et extensible, c'est un choix logique pour construire un logiciel de communication aujourd'hui. Choix que des projets comme Movim, Jappix ou Salut à Toi (dont je suis un des dév principaux) ont fait, et dans une certaine mesure Buddycloud mais ce dernier utilise ses propres extensions au standard.

Grâce à sa popularité, de nombreux serveurs et bibliothèques sont disponibles, ce qui facilite grandement la vie des développeurs. Le problème, c'est que contrairement à des projets qui développent leurs propres protocoles, nous n'avons pas la main sur toute la chaîne, et nous pouvons avoir des implémentations très différentes (le standard permet de les rendre compatibles, mais elles peuvent être plus ou moins complètes, plus ou moins efficaces, etc).

Ainsi pour le microblogage (XEP-0277, les XEP sont des extensions au protocol XMPP), il faut un service PEP (Personal Event Protocol, XEP-0163), qui est une version simplifiée d'un service PubSub (Publish Subscribe - publication/abonnement -, une façon de transmettre et recevoir des données décrite dans la XEP-0060).

Le problème, c'est que ce service doit faire partie du serveur pour 2 raisons : d'une part il nécessite un accès à certains privilèges réservés au serveur (accès à la présence des contacts, envoi de messages), et d'autre part on accède à un service PEP en contactant directement le serveur (directement sur le jid - jabber ID, l'identifiant XMPP - de notre contact, je passe les détails techniques qui parlent de ressources).

On se retrouve donc avec des besoins spécifiques, nécessaires pour le moment que pour certains projets, et donc peu implémentés, dans des serveurs où on n'a pas la main (on peut bien sûr proposer des contributions, mais ça prend du temps), et avec l'impossibilité d'implémenter ça ailleurs que sur le serveur. Bref, soit le serveur implémente ce qu'on veut, soit on est coincés, comme je l'avais expliqué dans un précédent journal.

Dans ce journal, j'expliquais qu'une solution que nous avions était de proposer 2 nouvelles XEPs: une qui permet à un composant externe d'avoir un accès privilégié au serveur et ainsi pouvoir accéder aux informations de présence par exemple, et une autre permettant au serveur de déléguer une fonctionnalité (un espace de nommage pour être plus précis) à une entité externe.

Après plusieurs péripéties, ces XEPs ont été publiées (XEP-0355 -Namespace Delegation- et XEP-0356 -Privileged Entity- : attention elle sont expérimentales, et donc sujettes à des changements importants), et j'ai récemment publié des modules les implémentant dans Prosody (ici et là).

Alors ça change quoi ? Eh bien nous pouvons désormais utiliser notre propre implémentation PubSub en tant que service PEP du composant, ou en d'autres termes nous pouvons utiliser notre propre implémentation externe de ces fonctionnalités auparavant réservées au serveur, et ce de manière générique donc potentiellement compatible avec tous les serveurs. Pour être plus clairs : nous ne sommes plus dépendants de l'implémentation du serveur, et nous pouvons avoir les fonctionnalités nécessaires pour potentiellement tous les serveurs sans effort supplémentaire.

Jusqu'ici nous utilisions notre propre service PubSub pour « Salut à Toi » (SàT PubSub, qui est un fork amical de Idavoll), mais il nous était techniquement impossible de l'utiliser comme service PEP, et nous étions donc incompatibles avec les autres logiciels (Movim et Jappix donc), pour le microblogage. Maintenant que les XEPs sont publiés et les modules prosody écrits, nous sommes en train d'adapter notre composant pour être enfin compatibles avec les autres.

Il faut bien comprendre qu'un service PubSub est un composant potentiellement complexe et difficile à écrire si on veut qu'il soit complet. Nous aimerions que notre composant devienne un service complet utilisable par tous les projets XMPP, voire qu'il réintègre le projet initial (mais l'auteur d'Idavoll est un peu débordé, cela semble difficile dans l'immédiat). PubSub est une base pour de très, très nombreuses fonctionnalités.

D'autres projets sont intéressés pour implémenter ces XEPs, en particulier nous sommes en contact avec un des développeurs principaux du populaire ejabberd. Une fois qu'on aura essuyé les plâtres avec notre première implémentation, j'espère qu'on verra fleurir des services externes et des implémentations des XEPs sur les serveurs.

Je ferai une conférence courte (20 min) pour expliquer le fonctionnement de pubsub et des ces XEPs aux RMLL de Beauvais en août, j'ai eu confirmation de la conférence mais je n'ai pas encore les horaires.

J'en profite pour donner des informations importantes sur notre avancement sur « Salut à Toi »: avec ce que je viens d'expliquer nous supprimons enfin notre dernier blocage majeur. Nous arrivons aussi à une situation délicate au niveau financier car nous vivons sur nos propres économies. Nous avons créé une association loi 1901 (appelée elle aussi « Salut à Toi »), et nous souhaitons nous salarier avec les adhésions (nous avons compté qu'il faudrait environ 6000 adhérents à une moyenne de 10 € - par an ! - pour nous salarier au SMIC + frais divers).

Nous allons donc profiter de la prochaine version pour lancer une campagne d'adhésion à l'association, et nous avons refait notre site pour donner quelques explications: http://salut-a-toi.org . Si la campagne réussit, nous espérons sortir une version grand public/stable pour la production à la fin de l'année ou au premier trimestre 2016. Nous en profiterons aussi pour parler de quelques projets que nous avons en tête, comme des passerelles vers d'autres plate-formes, ou un boîtier basse consommation avec SàT préinstallé.

Enfin, nous nous posons la question du financement participatif (crowdfunding), et voulons voir si les principes/plate-formes collent avec nos valeurs éthiques, je serais très intéressé par des retours en commentaires (où je peux détailler pourquoi on se pose ces questions).

Voilà, encore un long journal, j'espère que ça vous permet de mieux comprendre le travail effectué et ce qu'on vient de franchir…

  • # Pourquoi

    Posté par  (site web personnel) . Évalué à 10.

    Pourquoi ce n'est pas une dépêche?

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Pourquoi

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      C'était juste une explication comme ça, je ne pensais pas que ça valait le coup d'en faire une dépêche :).

      Tiens pendant que je suis là, souliane me fait remarquer que
      leur propre protocoles => leurs propres protocoles

      si un modérateur pouvait corriger…

      j'ai vu aussi une ou deux autres fautes/typos mais je ne sais plus où et je n'ai pas le courage de tout relire :)

  • # Excellent travail

    Posté par  (site web personnel) . Évalué à 1.

    Excellent, et très intéressant. Merci pour ces retours. Cela fait plaisir de voir que cela avance.

    • [^] # Re: Excellent travail

      Posté par  (site web personnel) . Évalué à 7.

      Je suis heureux de voir que ce long travail porte enfin ses fruits et que nous allons enfin avoir une solution Pubsub générique et facilement adaptable aux serveurs XMPP du moment.

      De la même façon nous allons pouvoir, pour la première fois avoir une pleine compatibilité avec des clients XMPP sur la gestion de flux et nous allons donc pouvoir faire du "réseautage social" :
      - En temps réel (alors que de nombreux autres protocoles sont construit sur du polling HTTP)
      - Multi-client et multi-serveur
      - Extensible pour transporter de nombreuses normes (je me concentre sur Atom pour le moment)
      - Décentralisé
      - Hors du Web, car selon moi un réseau social n'a rien à faire sur le Web, c'est un réseau avant tout. Le Web n'est qu'une interface à celui-ci (au même niveau que le réseau mail, chat ou de partage de fichier).

      En tous cas, Movim est prêt à accueillir les publications de SàT et je serais heureux de corriger les petits défauts pour que nous soyons pleinement compatibles :)

      edhelas

      • [^] # Re: Excellent travail

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        Oui c'est assez sympa de se dire qu'on va pouvoir discuter ensemble et faire un réseau plus large en dehors de la messagerie instantanée où c'était déjà le cas.

        Je pense que d'autres projets vont suivre: du côté de Poezio (très bon client XMPP console pour ceux qui lisent), ils ont commencé à parler d'une implémentation du microblogage également, j'aimerais beaucoup voir ça dans Gajim aussi, mais la dernière fois que j'en ai parlé au dév principal (il y a plusieurs années tout de même), il n'en était pas question, ils voulaient se concentrer sur la messagerie/vidéo conf (ce qui est un choix tout à fait compréhensible).

        Pour ceux qui lisent ce commentaire, il y a d'autres point sur lesquels on avance, notamment avec edhelas (et quelques autres personnes) on est en train d'essayer de revoir les signets (bookmarks).

  • # Adhésions ?

    Posté par  . Évalué à 3.

    Pourquoi forcément demander une adhésion au personnes qui souhaites soutenir le projet ?
    Adhérer à une association, c'est devenir membre de la vie de cette asso. Je suppose que je ne suis pas la seule personne qui pense que ce projet est intéressant, mais que je ne peux pas sérieusement adhérer à cette association car je ne pourrais pas y investir réellement du temps.

    Par contre, si j'avais des sous, faire un don régulier serait déjà plus envisageable, car la demande de temps serait moins importante (quelques secondes tous les mois en lisant mon relevé bancaire).

    • [^] # Re: Adhésions ?

      Posté par  . Évalué à 1.

      Ça dépend des asso.
      Pour certaines, un bureau et éventuellement un conseil d'administration regroupe les membres actifs.
      Les autres membres sont juste conviés à l'AG annuel.

      • [^] # Re: Adhésions ?

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        Oui c'est un peu ça. Vous pouvez lire les statuts et le règlement intérieur pour mieux comprendre: les membres du bureau (un bureau collégial qui prend les décisions au consensus) sont les membres actifs, et ceux qui seront (on l'espère) salariés: si on a suffisamment de sous à terme et qu'on veut salarier quelqu'un d'autre, il sera membre du bureau.

        Les adhérents n'ont aucun obligation de participation, même si on a une liste de diffusion pour les adhérents et qu'on aimerait les rencontrer régulièrement.

        Nous avons choisi la forme associative pour plusieurs raisons: déjà c'est très facile à créer, d'autre part c'est assez souple pour s'organiser comme on le souhaite, ensuite le but non lucratif même s'il ne protège pas de tout évite au moins l'actionnariat (ce que nous voulions) et d'accumuler l'argent n'importe comment. Il y a aussi d'autres avantages: le don à une entreprise n'est pas possible ou très difficile alors que possible pour une association. Ici l'adhésion est une forme de soutien tout à fait légal (mais nous paieront des impôts dessus une fois salariés, ce qui est tout à fait normal).

        Autre chose: il est très difficile de transférer le capital d'une association sauf vers une coopérative. Or nous envisageons la coopérative à terme.

        Bref, vois l'association comme une façon de « tester » l'activité, et comme un cadre légal, et l'adhésion comme un moyen de nous soutenir.

        Ah aussi je précise qu'on aimerait un don régulier, mais annuel: on a une fourchette de dons qui va de 0 à 100, mais on espère une moyenne de 10€/adhérent/an, autrement dit même pas un café par mois ! Nous ferons un rappel à chaque adhérent tous les ans (pas du spam, un rappel gentil :)), sans aucune obligation de redonner ou de donner le même montant (on peut donner 10 € un an et rester adhérent pour 0 € l'année suivante, ou ne plus être adhérent du tout).

        Voilà, j'espère que c'est plus clair. Nous envisageons le financement participatif pour nous lancer également…

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 1.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Adhésions ?

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            En effet, contrairement à ce qu'on pense souvent, il est possible d'être salarié et membre du bureau en même temps et c'est ce qu'on souhaite faire.

            Dans ce cas la gestion est intéressée et il n'y aucun avantage fiscal (encore une fois, c'est tout à fait normal). Et oui on sera le plus transparent possible, on a déjà essayé d'expliquer les choses clairement sur le site (n'hésitez pas à nous dire si ça n'est pas assez clair), et il suffit de nous rejoindre sur le salon XMPP de SàT (sat@chat.jabberfr.org) pour poser des questions.

            Aussi on n'a pas de président/secrétaire/trésorier vu qu'on est en autogestion et donc sans hiérarchie. Ça surprend souvent les gens y compris dans l'administration, mais c'est tout à fait possible.

    • [^] # Re: Adhésions ?

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Comme disait l'autre : "Si j'avais du lard je te ferais une omelette au lard mais je n'ai pas d'oeufs"

      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

  • # Déplacer le problème ?

    Posté par  . Évalué à 10.

    Juste pour être sûr que j'ai bien compris :

    Vous aviez des problèmes avec les serveurs XMPP pour faire du microblogage parce que cela nécessite que le serveur implémente le XEP-0163 (service PEP). Or la majorité des serveurs déployés ne l'implémentent pas encore (l'XEP-0163 est encore au stade de draft).

    Pour contourner ce problème, deux nouvelles XEP ont été publiées (à l'état expérimental) : XEP-0355 et XEP-0356 pour permettre de déléguer à un serveur tiers l'implémentation du service PEP.

    Cela permet d'avoir une implémentation unique du service PEP qui permet de se connecter à n'importe quel serveur XMPP qui implémente ces deux XEP expérimentales.

    Si je comprend bien, pour que cela fonctionne, il faut donc que tous les projets de serveur XMPP acceptent d'implémenter ces deux XEP et que les détenteurs de serveur XMPP utilisés acceptent de mettre à jour le code de leur serveur vers cette nouvelle version ?

    Je ne connais pas la complexité d'implémentation de ces XEP, mais n'est ce pas ambitieux de penser que les développeurs des serveurs seront plus à même d'implémenter deux XEP expérimentales de 2014 qu'ils l'ont été d'implémenter une XEP pas modifiée depuis 2010 ?

    Mes deux cents…

    • [^] # Re: Déplacer le problème ?

      Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 27 mai 2015 à 11:30.

      Dans l'idéal tout serait implémenté par tous les serveurs oui.

      Mais en pratique les implémentations sont soit inexistantes, soit incomplètes, soit ont des problèmes de performances.

      Alors pourquoi c'est comme ça ? La XEP-0060 et une XEP longue et complexe (c'est une des plus longues de XMPP), et de nombreuses choses sont optionnelles. Les implémentations sont souvent incomplètes pour une ou plusieurs de ces raisons:

      • beaucoup de serveurs et clients se concentrent plutôt sur la messagerie instantanée, même si je pense que c'est en train de changer

      • comme peu de clients utilisent pubsub de manière intensive, il y a peu de demandes pour améliorer les implémentations côté serveurs

      • beaucoup de choses optionnelles, donc même si on a une implémentation, on n'a pas forcément ce que l'ont souhaite

      • il y a des choses comme les signets (bookmarks ou XEP-0048) qui au départ n'utilisaient pas pubsub - qui n'existait pas - et qui ont ensuite été mises à jour pour utiliser pubsub. Comme la première implémentation marche, beaucoup ne voient pas de raison de changer.

      • et surtout c'est un gros boulot, un projet à part entière, il faut les ressources pour implémenter pubsub + le boulot déjà existant sur le serveur.

      Bref à mon sens c'est beaucoup plus logique d'avoir ça comme composant extérieur complet, que comme un parent pauvre du serveur. Et si on veut améliorer l'implémentation d'un serveur ça peut aller, mais tous les serveurs avec les dizaines de langages et d'architectures utilisés, c'est plus compliqué.

      D'autre part, nous bougeons beaucoup sur PubSub, et il peut y avoir de nouvelles XEPs à implémenter, qui mettront du temps à arriver dans les serveurs: avec la maîtrise du composant, on peut faire une implémentation immédiatement (et pour tous les serveurs !), la chaîne de développement est beaucoup plus rapide.

      Dans notre cas particulier, nous avons une extension non standard (pour le moment) qui permet d'envoyer un message à un groupe uniquement: vu qu'il n'y a pas de XEP associée, aucune chance de voir ça dans un serveur. Là on peut tester et améliorer avant de proposer une XEP.

      Enfin oui ces 2 XEPs sont beaucoup plus faciles à implémenter (il m'a fallu quelques jours pour Prosody alors que ce sont mes premiers modules pour ce serveur), regarde leur taille et compare à la XEP-0060 pour comprendre, et ça peut servir dans d'autres cas qu'un composant PEP/PubSub. D'autre part tout ce qui est nécessaire à faire un service PEP est obligatoire dans ces XEPs, alors que tout ce dont on a besoin dans PubSub ne l'est pas forcément. Donc si elles sont implémentées, on est sûr d'avoir ce qu'il faut.

      • [^] # Re: Déplacer le problème ?

        Posté par  . Évalué à 5.

        Donc si j'ai bien compris :

        • la spécification censée faire ce dont vous avez besoin est longue, complexe, imprécise et lourde à implémenter, donc inutilisable
        • vous avez donc créé deux spécifications plus simples, plus courtes et plus précises donc plus facilement implémentables en espérant que d'autres vous suivront.

        J'ai bon ?

        • [^] # Re: Déplacer le problème ?

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          la spécification censée faire ce dont vous avez besoin est longue, complexe, imprécise et lourde à implémenter, donc inutilisable

          j'ai dit longue et complexe (encore que le complexe résulte surtout de la longueur, le principe est simple), pas imprécise et encore moins inutilisable (on l'utilise tous les jours !).

          vous avez donc créé deux spécifications plus simples, plus courtes et plus précises donc plus facilement implémentables en espérant que d'autres vous suivront.

          On a écrit 2 spécifications (relativement faciles à implémenter) qui permettent de développer à l'extérieur des choses qui étaient réservées au serveur, autrement dit on décentralise le code.

  • # Fusion avec XEP-0114

    Posté par  (site web personnel) . Évalué à 3.

    Déjà, félicitations pour l’avancée, grâce a ça on pourra voir des composants (au sens XMPP) se développer sans être spécifique a un serveur. Excellent !

    En fait si j'ai bien compris, ici il s'agit d’étendre un peu les capacités des composants. Du coup on se retrouve avec:

    • la XEP-0114 qui est une standardisation d'une pratique répandue (a l’époque)
    • la XEP-0225 qui veut nettoyer un peu ça mais qui n'est pas encore standard
    • deux XEP qui permettent aux composants d'agir plus comme des serveurs que comme des clients

    Du coup j'ai deux questions:

    • Est-ce qu'il y a des cas d'utilisation dans lesquels une des deux XEP pourrait etre utile mais pas l'autre ? Dit autrement, pourquoi deux XEP et pas une seule ?

    • Est-ce qu'il n'y avait pas moyen de pousser pour une mise a jour du protocole des composants, c'est-a-dire dépoussiérer 225 en y ajoutant vos cas d'utilisation ?

    • [^] # Re: Fusion avec XEP-0114

      Posté par  (site web personnel) . Évalué à 3.

      Ah mais non, après examen plus précis de 355 et 356, ces deux XEPs ne sont pas spécifiques aux composants donc mes questions n'ont pas vraiment de sens, pardon.

      • [^] # Re: Fusion avec XEP-0114

        Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 27 mai 2015 à 17:45.

        Effectivement, les XEPs ne sont pas spécifiques aux composants (même si ça leur est principalement destiné dans un premier temps)

        Il y a bien une méthode « traditionnelle » historique (la XEP-0114) pour connecter des composant: c'est une sorte de client simplifié, et dans le conf du serveur on met un jid à associer et un mot de passe, et voilà.

        Cette méthode est simple et peu moderne, mais a le mérite d'être répandue et fonctionnelle. La XEP-0225 est plus moderne (elle permet d'utiliser TLS par exemple), mais je ne pense pas que son adoption est aussi systématique dans les serveurs. Enfin je ne me suis jamais trop penché dessus, vu que pour l'instant la XEP-0114 nous convient. Mais je pense qu'à terme, la XEP-0114 va être dépréciée au profit de la XEP-0225 ou une plus récente, mais ça prend du temps (parce que ça marche en l'état, c'est un peu le même problème avec l'adoption de pubsub pour les signets (bookmarks)).

        edit: pour être bien clair, les nouvelles XEPs n'ajoutent rien pour la connexion d'un composant (ce qui existait déjà comme tu l'as dit); elles leurs permettent d'avoir un accès privilégié aux serveurs de manière générique, et de gérer des fonctionnalités qui ne pouvaient pas l'être en dehors du serveur avant.

  • # serveurs et clients

    Posté par  (site web personnel) . Évalué à 3.

    Je comprends la démarche, mais est-ce qu'elle ne remets pas en cause l'un des fondements de la philosophie XMPP «la complexité sur le serveur»?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: serveurs et clients

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Dans ce cas précis, la complexité sera dans un composant (ou entité) dédié, pas dans le client, donc ça ne perturbe pas trop cette philosophie.

      Mais de manière générale, les clients gèrent de plus en plus de choses, et la complexité augmente: il est possible d'avoir du pubsub sur le client lui même si on veut, et pour l'audio vidéo c'est clairement le client qui gère le plus de choses.

      Après c'est des possibilités, des fonctionnalités à implémenter ou non, un client de base qui ne ferait que de la messagerie peut toujours s'implémenter de façon très simple.

  • # Routeur XMPP

    Posté par  . Évalué à 1.

    Si j'ai bien compris la XEP-0356, ça permettrait d'avoir un serveur qui implémente les 2 RFC et qui route le reste vers des composants indépendants (avec leur propre daemon) qui eux apporteraient leur fonctionnalités (MUC, PEP, PubSub, E-mail, etc)?

    • [^] # Re: Routeur XMPP

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      C'est à peu près ça sauf que c'est le XEP-0355 (la XEP-0356 c'est les privilèges), et que l'autre n'est pas nécessaire.

      En gros quand on demande un truc à un serveur, au lieu de le gérer directement (ou pas 'il ne connait pas le protocole), il délègue à une autre entité. Pour MUC, PubSub et une passerelle courriel ça ne change pas grand chose parce que c'était déjà possible de faire ça depuis un composant, pour PEP par contre c'est le seul moyen d'implémenter ça à l'extérieur (c'était notre motivation principale).

      Ça peut être utilisé avec tout ce qui est réservé normalement au serveur. Par exemple ça pourrait être utilisé pour MAM (Message Archive Management, qui permet d'avoir l'historique des conversation géré par le serveur) pour que l'historique soit stocké à l'extérieur du serveur (ou tout simplement pour l'implémenter sur un serveur qui ne le gère pas).

      • [^] # Re: Routeur XMPP

        Posté par  . Évalué à 2.

        La ressource vers laquelle on délègue doit-elle être accessible au client? Ou seul le serveur à besoin d'un accès (auquel cas il s'occupe de faire suivre le message)?

  • # Précisions pour les noobs ?

    Posté par  . Évalué à 2.

    Je ne me suis encore jamais penché sur XMPP, mais ce que tu présentes a l'air bien sympa, si j'y comprenais quelque chose :-)

    Justement, il s'avère que depuis peu je me demande comment faire du microblogging décentralisé (mais aussi sélectif : microblogguer avec un groupe de personnes défini)… Et si je te comprends bien vous avez simplifié la façon de l'implémenter avec XMPP ?

    Si c'est ça, peux-tu expliquer aux noobs comme moi ce qu'il faudrait mettre en place pour pouvoir l'utiliser ? (si c'est possible dès maintenant…)

    Peut-on utiliser un serveur jabber parmi ceux qui sont sur le wiki ou faut il un serveur sur lequel on a la main (quelques commentaires du journal sont troublants et il me semble y lire que les choses peuvent se faire au niveau du client seulement ??? Ou je pige vraiment rien ?)

    Peut-on utiliser un client jabber classique ? Je comprends que non (c'est ça ?). Quels sont les clients spécifiques qui implémentent ou implémenteraient ça ? Seulement SÀT¹ ?

    ¹ Mais si je comprends bien SÀT nécessite aussi un serveur web…

    • [^] # Re: Précisions pour les noobs ?

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Salut,

      Et si je te comprends bien vous avez simplifié la façon de l'implémenter avec XMPP ?

      Simplifier c'est pas le mot, disons qu'on n'est (enfin on sera dans quelques temps si tout va bien) plus bloqués par les possibilités des serveurs (dans le sens le logiciel, après il faut que les instances de ces logiciels activent ce qu'il faut).

      Si c'est ça, peux-tu expliquer aux noobs comme moi ce qu'il faudrait mettre en place pour pouvoir l'utiliser ? (si c'est possible dès maintenant…)

      Dès maintenant c'est possible d'utiliser des serveurs pour faire du microblogage de base, mais ça marche plus ou moins bien. Metronome (fork de Prosody) est le serveur recommandé par Movim et Jappix, Ejabberd avait des problèmes de performance à une époque mais sinon c'est à ma connaissance l'implémentation PubSub la plus complète des serveurs, Prosody dans le version stable ne stocke pas les billets sur le disque, OpenFire j'ai arrêté à un moment suite à un bogue très gênant, je ne sais pas où ça en est, et je ne sais pas trop l'état non plus de Tigase ou autre.

      Si c'est ça, peux-tu expliquer aux noobs comme moi ce qu'il faudrait mettre en place pour pouvoir l'utiliser ? (si c'est possible dès maintenant…)

      Il faut principalement activer le composant PEP, il faut suivre la documentation du serveur pour voir comment faire.

      Peut-on utiliser un serveur jabber parmi ceux qui sont sur le wiki ou faut il un serveur sur lequel on a la main

      La page que tu donnes cite des instances de serveurs, et du coup il faut voir au cas par cas ce qu'ils activent. Tu peux utiliser un client XMPP pour voir les fonctionnalités et la présence de « http://jabber.org/protocol/pubsub#publish » dans les fonctionnalités, et « (pubsub/pep) » dans les identités (désolé c'est un peu technique, mais c'est comme ça qu'on regarde si une fonctionnalités existe. Avec salut à toi il y a l'interface en ligne de commande pour tester ça, par exemple sur jabber.fr ça donne:

      % jp info disco jabber.fr
Features:

http://jabber.org/protocol/commands
http://jabber.org/protocol/disco#info
http://jabber.org/protocol/disco#items
http://jabber.org/protocol/stats
iq
jabber:iq:register
jabber:iq:time
jabber:iq:version
msgoffline
presence
presence-invisible
urn:xmpp:time
vcard-temp
--
Identities:

ejabberd (server/im)
--
Extensions:

http://jabber.org/network/serverinfo

--
Items:

[chat.jabberfr.org]
[irc.jabberfr.org]
[j2j]
[presence.jabberfr.org]
[proxy.jabberfr.org]
[users.jabberfr.org]

      Pas de « http://jabber.org/protocol/pubsub#publish » ici ni de « (pubsub/pep) », ça n'est donc pas possible. Il faut alors soit avoir le main sur le serveur, soit contacter les admins.

      (quelques commentaires du journal sont troublants et il me semble y lire que les choses peuvent se faire au niveau du client seulement ??? Ou je pige vraiment rien ?)

      Il faut d'une part que des fonctionnalités soient activées sur le serveur (pep au minimum), et d'autre part que le client soit capable de gérer ça (une compatibilité XEP-0277 au minimum). XMPP a la grande force d'être extensible, mais ça rend son approche un petit peu plus compliquée parce que les fonctionnalités s'activent ou pas en fonction de ce que sait faire le serveur/client en face.

      Bon maintenant je parlais ici de microblogage de base. À ça il faut ajouter Message Archive Management (MAM) et/ou Result Set Management (RSM) pour pouvoir accéder à des message anciens (plus que les 10 derniers par exemple). Ce sont d'autres fonctionnalités que le serveur doit implémenter, et à ma connaissance, ça n'est disponible nulle part.

      Nous on a un composant qui gère tout ça, mais il n'était pas possible de le « brancher » sur le serveur avant. Maintenant c'est possible avec Prosody et bientôt sur d'autres serveurs j'espère (ça marche probablement avec Metronome aussi vu que c'est un fork de Prosody). Côté Prosody c'est expliqué sur les pages wiki des modules que j'ai écrit: https://code.google.com/p/prosody-modules/wiki/mod_privilege et https://code.google.com/p/prosody-modules/wiki/mod_delegation ). Mais notre composant est en cours d'adaptation à ces nouveautés, c'est bien avancé mais il va falloir encore patienter un (petit) peu.

      On n'est ainsi plus limités par les serveurs.

      Peut-on utiliser un client jabber classique ?

      Rien n'empêche un client classique d'implémenter ça, mais à ma connaissance aucun ne travaille dessus. On aimerait bien en voir ! Côté Poezio (très bon client console), on en parle.

      Je comprends que non (c'est ça ?). Quels sont les clients spécifiques qui implémentent ou implémenteraient ça ?

      Pour l'instant les 3 seuls (sauf erreur) sont Jappix, Movim et SàT.

      Mais si je comprends bien SÀT nécessite aussi un serveur web…

      Non, c'est même le seul des 3 cités qui n'en a pas besoin: tu peux utiliser une interface non-web (c'est multi-interface), mais on vient de retirer l'interface de bureau parce qu'on va en écrire une nouvelle pour la version grand public (fin d'année), soit tu utilises le serveur web intégré avec Libervia. Il y a une image Docker qui permet de tester ça facilement: http://wiki.goffi.org/wiki/Docker/en (expérimentale, n'hésite pas venir demander de l'aide/dire ce qui ne va pas sur le salon XMPP de SàT: sat@chat.jabberfr.org).

      mais aussi sélectif : microblogguer avec un groupe de personnes défini

      Ça par contre seul SàT en est capable, mais ça n'est pas (encore) standard. On va essayer de standardiser ça dans le futur. C'est de toute façon compatible avec les implémentations classiques, et on construit tout autour de cette logique: partage de fichiers, accès au commandes internes, etc.

      Voilà, j'espère que c'est plus clair, sinon n'hésite pas à demander des précisions.

      • [^] # Re: Précisions pour les noobs ?

        Posté par  . Évalué à 1.

        Merci beaucoup, c'est super clair et ça donne de nombreuses pistes d'expérimentation ! Du boulot en perspective (il ne reste plus qu'à trouver le temps ! :-))

      • [^] # Re: Précisions pour les noobs ?

        Posté par  (site web personnel) . Évalué à 2.

        Vu que les serveurs n'ont pas l'air d'être dans un super état et qu'ils n'évoluent pas trop, c'est peut être le moment de lancer sàt server? :-)

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Précisions pour les noobs ?

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Euh si ils avancent et ils sont bien maintenus (suffit d'aller sur le salon prosody pour voir comme c'est actif), c'est juste que les priorités ne sont pas forcément les mêmes que pour nous.

          Et sinon un jour on va probablement implémenter un serveur aussi, ou du moins une partie de ce que fait le serveur, pour avoir quelque chose de complètement P2P/Distribué/ça_dépend_comment_vous_appelez_ça. Y'a pratiquement tout ce qu'il faut déjà avec les bibliothèques qu'on utilise, mais bon c'est vraiment pas pour tout de suite.

  • # XMPP et messagerie instantanée, la donne est pourrie ?

    Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 30 mai 2015 à 10:43.

    Je m'éloigne du sujet mais au vu des récentes nouvelles concernant l'abandon de XMPP par Facebook, il semblerait que la situation continue de s'aggraver pour les gens qui ont cru pouvoir remplacer MSN par Jabber il y a dix ans, non ?

    (je réalise que ce commentaire est une redite d'un de mes précedents coms, qui était également en réponse à un journal SàT. Désolé si je sonne comme un disque rayé :p)

    • [^] # Re: XMPP et messagerie instantanée, la donne est pourrie ?

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Pour moi ça n'aurait aucun intérêt d'utiliser XMPP si tout le monde était sur FB ou gtalk.

      L'annonce de l'utilisation et de l'abandon de XMPP par FB ne m'a fait ni chaud ni froid (d'un point de vue perso je n'ai jamais vraiment utilisé, et d'un point de vue général ça ne change rien pour FB qui n'était pas fédéré, et pour Gtalk le seul intérêt est - ça marche encore - de pouvoir communiquer avec des gens dessus), et c'est à mon sens une grosse erreur de se faire héberger là bas de toute façon.

      Non ce qui montre la vitalité de XMPP, c'est le nombre et le dynamisme des projets qui l'utilisent et des standards, et de ce côté j'ai plutôt tendance à penser que ça s'améliore.

    • [^] # Re: XMPP et messagerie instantanée, la donne est pourrie ?

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 30 mai 2015 à 15:27.

      MSN et Jabber c'est pas exactement la même chose, en fait. Moi aussi je suis attiré par les autres protocoles qui brillent parce qu'ils sont tout neufs et ne sont pas en XML (comme matrix par exemple), mais l'"abandon" de XMPP par des grands acteurs (je mets Google dans le même panier) n'est pas une preuve de l'inutilité de XMPP, au contraire même.

      Il faut bien voir que l'intérêt de ces acteurs est de créer un enclos dans laquelle les utilisateurs restent, et de contrôler au maximum les entrées et sorties. La fédération, si chère à XMPP, est un défaut qui ne peut être contre-balancé que par la prospective d'attirer plus d'utilisateurs en interne. C'est pour ça que GMail fait du SMTP et se fédère ainsi au reste du monde, mais ils le font parce qu'il y a beaucoup à y gagner; Facebook fait du HTTP parce qu'ils ne contrôlent pas toute la chaîne jusqu'à leurs serveurs et doivent donc utiliser les mêmes outils que le monde extérieur. Google a un avantage sur ce point, ils contrôlent une partie des navigateurs et peuvent donc se permettre des choses qui cassent la compatibilité.

      Pour le moment les maigres avantages à supporter XMPP pour un géant comme Facebook (on peut à peine dire que plus de monde utiliserait Facebook, vu que les clients XMPP tendent à être utilisés par des gens qui se soucient un peu de leur vie privée) ne valent pas les inconvénients (quelqu'un pourrait offrir les mêmes fonctionnalités que Facebook, mais à l'extérieur).

      En revanche ce qu'on peut regretter, c'est l'absence d'entité qui s'impose comme référence dans le domaine XMPP: la messagerie instantanée simpliste est de loin l'utilisation la plus répandue aujourd'hui alors que XMPP est capable de bien plus.

      • Pourquoi est-ce que personne ne fait de la messagerie un peu plus poussée avec les fonctionnalités qu'on attendrait aujourd'hui (historique illimité, recherche, multi-appareils, chiffrement end-to-end, asynchronicité,…) ? Tout est là, mais personne ne fait la totalité comme le fait IRCCloud avec irc ou Slack dans leur propre univers. Vu de loin j'ai même l'impression que matrix essaie de construire un ensemble de logiciels qui fournit les fonctionnalités. À un moment j'ai cru que DuckDuckGo avait un plan quand ils ont annoncé qu'ils ouvraient les inscriptions sur leur serveur, mais on dirait qu'ils ont un prosody qui tourne et ça s'arrête là.

      • XMPP a tout sur le papier pour remplacer SMTP et faire du chiffrement par défaut (dans la veine du point précédent); personne n'en fait rien…

      • XMPP a tout sur le papier pour remplacer twitter, et j'ai pas vu de grand mouvements de ce côté là. Il y a bien juick qui à un moment permettait de poster via un bot XMPP, et buddycloud qui a ses propres XEPs. Bon sur ce point le gros problème c'était que l'implémentation dépendait du serveur, et grâce aux 2 XEPs (encore merci les gars !) on va pouvoir développer, mais encore une fois, rien n'a percé.

      À force de voir "X abandonne XMPP" on est décu en se disant que XMPP a perdu. À l'inverse il faut plutôt être décu de ne pas voir plus de "X utilise XMPP pour dominer le monde", c'est-à-dire des nouveaux entrants qui utilisent XMPP comme avantage compétitif et qui démontrent la viabilité de XMPP comme brique de base pour fournir des services. Mais ça grouillote toujours dans le monde XMPP, donc penser que XMPP est mort est juste faux.

      (Je pense également que si il y a si peu de services offerts au public avec XMPP, c'est parce que XMPP a pour philosophie de tout faire sur le serveur ce qui est une aberration immense à mon avis: l'innovation ne vient quasiment jamais des serveurs mais bien des clients, à savoir le bout de la chaine, là où il n'y a pas besoin de demander l'autorisation à qui que ce soit pour tenter quelque chose)

      • [^] # Re: XMPP et messagerie instantanée, la donne est pourrie ?

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        Sans vouloir nous mettre trop en avant, je pense qu'on est en plein dans ce que tu recherches (et Movim aussi sur certains points). Plus en détails:

        Pourquoi est-ce que personne ne fait de la messagerie un peu plus poussée avec les fonctionnalités qu'on attendrait aujourd'hui (historique illimité, recherche, multi-appareils, chiffrement end-to-end, asynchronicité,…) ?

        Si si, on fait ! historique illimité, recherche, multi-appareils c'est MAM + Message Carbons et les implémentations sont de plus en plus courantes.

        Chiffrement de bout en bout c'est un peu plus compliqué parce qu'il n'y a pas de bonne solution avec XMPP (c'est une vieille marotte et il y a eu plusieurs tentatives, mais rien n'a encore été largement adopté). La seule solution un peu populaire c'est OTR, et elle n'est pas (encore) standardisée en XMPP ! C'est des bidouillages de l'utiliser, mais ça fonctionne tant bien que mal, d'ailleurs on l'implémente dans SàT (et même 2 fois parce qu'on a décidé de faire une implémentation dans le navigateur pour l'interface web). Asynchronicité c'est de base dans XMPP, quel est ton problème avec ?

        XMPP a tout sur le papier pour remplacer SMTP et faire du chiffrement par défaut (dans la veine du point précédent); personne n'en fait rien…

        Le chiffrement est de base dans XMPP et même obligatoire depuis plus d'un an. Et pour SMTP là encore on peut par dire qu'on ne fait rien: c'est un truc dont on parle depuis plus de 4 ans (lire ici), on a un serveur IMAP, un serveur SMTP et un stockage Maildir dans SàT, et on fera certainement une passerelle SMTP pas pour cette version mais pour la prochaine.

        XMPP a tout sur le papier pour remplacer twitter, et j'ai pas vu de grand mouvements de ce côté là.

        Il me semble que ce journal montre justement le contraire. Tu peux essayer Movim ou Jappix, ou la démo de Libervia pour voir ce qu'on peut déjà faire, mais il y a encore du boulot c'est sûr.

        C'est parce que XMPP a pour philosophie de tout faire sur le serveur ce qui est une aberration immense à mon avis

        L'idée de base c'était - je pense - de se dire qu'il y a moins besoin de serveurs différents que de clients différents, et donc de simplifier la vie des développeurs de clients. La philosophie est toujours valable: si tu veux utiliser juste la partie messagerie instantanée de XMPP, ou juste la partie messagerie style courriel, tu peux facilement. Si tu veux des choses avancée, il faut de toute façon souvent des implémentations côté serveur et client (MAM par exemple).

        il n'y a pas besoin de demander l'autorisation à qui que ce soit pour tenter quelque chose

        Ben les nouvelles XEPs vont justement sacrément faciliter les choses de ce côté maintenant.

        Et la standardisation est un avantage énorme sur tout nouveau protocole, et à qui il faudra un temps fou (ça se compte en années) avant d'arriver au niveau de XMPP.

        Nous ça faisait longtemps qu'on attendait d'être débloqué pour le microblogage, maintenant je ne vois plus rien de majeur qui va nous gêner, et je pense ne pas trop m'avancer en disant que l'utilisation et les fonctionnalités de XMPP vont exploser sous peu.

      • [^] # Re: XMPP et messagerie instantanée, la donne est pourrie ?

        Posté par  (site web personnel) . Évalué à 6. Dernière modification le 31 mai 2015 à 00:49.

        Pour répondre globalement à ce post je dirais que ces grosses boites ont souhaités se passer de XMPP pour plusieurs choses :
        - Les standards c'est chiants, et comme tu le dis si bien, si tu contrôle la chaine, pourquoi s'emmerder à vouloir être compatible avec les autres ? Quand tu es un grand acteur (comme Google) et que tu es imposant sur un marché (le mail avec Gmail), mais pas assez pour dominer, tu te plie aux standards et tu reste compatible. Se passer de XMPP casse des choses mais pas tant que ça en fait vu la "faible" utilisation de celui-ci atour de ces acteurs.
        - XMPP est utilisé à 10% de sa capacité, voir moins. À combien de personnes, même dans la communauté du libre, je dois expliquer que non XMPP n'est pas uniquement pour le chat mais peut faire bien plus? On a plus de 300 extensions maintenant mais certaines d'entre elles sont a peine implémentés (Pubsub, sortit en 2008, jamais implémenté en totalité sur un serveur, et coté client…)
        - Elles ont pas "compris" l'intérêt de XMPP, parcequ'elles se sont cantonnés à faire du chat par dessus, comme 80% des autres projets. Mais je pense que ce soucis vient aussi de la XSF qui doit activement communiquer sur les possibilités offertes par XMPP.

        Avant de critiquer les multinationales parcequ'elles font des chôses dans leurs intérêts, regardons nous, libristes. On a attendu que Mozilla arrive pour faire du Web l'un des domaines les plus innovants de l'informatique moderne. Coté réseaux sociaux on a des dizaines de projets (StatusNet, Pump.io, Diaspora, Matrix…) qui sont certes très intéressants mais qui ne règlent pas le "problème" général. Quand Mozilla a bossé sur Firefox, ils ne voulaient pas créer UN Web pour eux, ils voulaient améliorer LE Web dans son ensemble.

        Donc oui XMPP est critiquable, oui le XML sépabo, oui c'est chiant d'écrire une XEP pour dire comment gérer la sauvegarde d'un message sur un serveur mais c'est nécessaire.

        Quand Google a voulu se mettre à XMPP ils ont tenté la fédération et ont proposé un client simple (Google Talk) et qui était dispo sur pas mal de plateformes à l'époque. Ils ont également travaillé à la "standardisation" (à leur manière certes) et au développement de la visio sur le protocole, ce qui nous a apporté Jingle. As t'on vu une révolution depuis ? Peut-on facilement faire de la visio sur nos machines de libristes ? Non. La norme est là pourtant. Et pourtant Pidgin n'a pas bougé, Gajim a une implémentation plus que buggé, Empathy pareil, les seuls qui se bougent sont Jitsi.

        Résultat des courses, c'est grâce au Web qu'on a de la visio pas trop pourrit avec WebRTC, grâce à qui ? Mozilla et Google (principalement).

        Donc avant d'aller voir pourquoi ça marche pas chez les autres améliorons nos clients, Pidgin ne semble pas bouger depuis plusieurs années, pourtant c'est pas compliqué il suffit juste d'implémenter la norme. Pour les nouveaux projets (comme Empathy) ils se cantonne au strict minimum (liste de contact, vcard et présence).

        Je bosse sur le protocole XMPP depuis plus de 5 ans déjà et mon principal problème n'est pas d'écrire des normes ni d'essayer de l'implémenter dans mon client (Movim). Mon problème c'est de voir que je suis le seul (avec Jappix, SàT et quelques autres clients) à vouloir aller de l'avant, et c'est usant, très usant. J'ai créé un petit tableau récapitulatif du support de la normes sur les principaux clients ici https://pod.movim.eu/?q=about#caps_widget , il y a encore de très grosses lacunes chez pas mal de clients.

        Donc avant de vouloir réinventer un énième protocole "social" essayez d'améliorer l'existant. XMPP offre, selon moi, les ingrédients pour créer une petite révolutions dans le domaine des échanges sociaux sur le Internet.

        Pour vous donner quelques idées :
        - Sur le papier on peut associer WebRTC et Jingle, Jappix l'a fait et semble être le seul à le faire assez bien. WebRTC colle au niveau protocolaire avec les solutions de visio "classiques" (hors du Web) pourquoi ne travaillons nous pas à rendre compatible Pidgin, Gajim… avec WebRTC ? Les normes sont là, il "suffit" juste de les implémenter.
        - Sur XMPP on peut sauvegarder les bookmarks de nos clients (salons de discussions…), la norme existe… et pourtant. Pidgin sauvegarde ses bookmarks en local, Gajim fait à sa façon… bref même un truc aussi simple n'est pas fini. Du coup Goffi, moi et quelques autres motivés allons réécrire et simplifier la norme (http://xmpp.org/extensions/xep-0048.html) pour, espérons le, faciliter l'implémentation dans ces clients.
        - Les XEP Vcard4 et Avatar permettent de "pusher" les informations entre les contacts, qu'est ce qui est encore majoritairement implémentés ? vcard-temp, XEP historique (http://xmpp.org/extensions/xep-0054.html) sortie en 2008 et qui fonctionne en pulling (il faut requêter une à une les vcard de vos contacts). J'ai implémenté Vcard4 tout seul en une après-midi sans grande difficulté, le nombre de projets qui ont fait de même se comptent sur les doigts d'une main. Petit détail, il n'y a rien à faire coté serveur (enfin il faut qu'ils supportent PEP, ce qui est déjà fait pour la majorité d'entre eux).

        Donc pour résumer, la solution on l'a sous nos yeux, il faut juste l'implémenter et rendre compatible nos projets existants.

        edhelas

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.