`, c.‐à‐d. le cœur du message. Comme des tas d’extensions ajoutent des informations en dehors du ``, il est risqué de les utiliser avec OTR. Autrement dit, il vaut mieux que le client désactive tout quand il utilise OTR. D’autre part, il ne fonctionne qu’avec une conversation directe et il n’est pas possible de laisser un message hors ligne. ## Le bout en bout moderne : Aloxotl En parallèle est arrivé Aloxotl, qui corrige plusieurs défauts d’OTR. Désirant l’implémenter, les développeurs du client [Conversations](https://conversations.im/) ont pu bénéficier du [_Google Summer of Code_](https://fr.wikipedia.org/wiki/Google_Summer_of_Code), sous l’égide de la [XSF](https://fr.wikipedia.org/wiki/XSF "XMPP Standards Foundation"), à condition qu’ils rédigent une XEP. Ceci a donné [OMEMO](https://conversations.im/omemo/), qui apporte principalement une synchronisation entre les ressources XMPP (et donc entre les appareils) et les messages hors ligne. Deux XEP ont donc été proposées (_cf._ le lien précédent), l’une pour le cœur d’OMEMO, l’autre pour son utilisation avec le transfert de fichiers Jingle. Malheureusement, elle souffre du même défaut qu’OTR, c’est‐à‐dire qu’elle ne chiffre que le `` du message. [_N. D. L. A. : aussi, et c’est un avis personnel, leur méthode de chiffrement pour les fichiers n’est pas bonne, car elle ne profite pas de la souplesse de Jingle, mais ce sont des points qui vont très certainement s’améliorer à force de discussions sur la [liste « standards »](http://mail.jabber.org/mailman/listinfo/standards)_]. Les [discussions](https://linuxfr.org/users/goffi/journaux/parlons-xmpp-episode-4-les-discussions-de-groupes) de [groupe type MUC](https://linuxfr.org/users/goffi/journaux/parlons-xmpp-episode-5-les-discussions-de-groupe-suite-et-les-transports) sont prévues mais pas encore possibles. ## Côté IETF Mais ça n’est pas tout ! Il y a eu également un travail sur une méthode de chiffrement faite par l’IETF, dont on peut consulter le [brouillon](https://tools.ietf.org/html/draft-thomson-xmpp-secure-00). Méthode qui, elle, chiffre la _stanza_ complète ! ## Et re-OpenPGP Enfin, il y un travail en cours pour une nouvelle intégration, propre cette fois, d’OpenPGP dans XMPP, dont un [brouillon](http://geekplace.eu/xeps/xep-openpgp/xep-openpgp.html) est disponible. Les salons de discussion ==== ## MIX La nouvelle version du protocole de discussion de groupe (mentionnée brièvement [dans l’épisode 5 de _Parlons XMPP_](https://linuxfr.org/users/goffi/journaux/parlons-xmpp-episode-5-les-discussions-de-groupe-suite-et-les-transports)) a désormais une XEP officielle ! Elle est très intéressante et a un gros potentiel, on ne parle plus de MUC 2 désormais, mais de MIX pour _Mediated Information eXchange_ (échange d’information avec modération), spécifiée dans la [XEP-0369](https://xmpp.org/extensions/xep-0369.html). Les avantages sont nombreux, en voici quelques-uns : - tout est basé sur [PubSub](https://linuxfr.org/users/goffi/journaux/parlons-xmpp-episode-8-pubsub-et-pep) ; - ça fonctionne bien avec différentes ressources qui partagent le même surnom (« _nick_ »), avant ça n’était possible qu’avec des bidouilles plus ou moins sales ; - les présences, qui étaient à la base de MUC, sont facultatives dans MIX. L’absence de présence est surtout utile pour réduire (de beaucoup) le trafic (et donc améliorer la durée de vie de la batterie sur appareils mobiles) ; - bien meilleure synchronisation, plus besoin de logs sur un site séparé : il suffit de retourner dans le salon pour savoir tout ce qui s’est dit pendant votre absence ; - possibilité de suivre un salon en « invisible » ; - la gestion du surnom (« _nick_ ») d’une entité est découplée de la façon de s’y adresser, ainsi on peut continuer de s’adresser à quelqu’un de la même façon, même après un changement de pseudo ; - devrait pouvoir fonctionner en « MUC fédéré » ([XEP-0289](http://xmpp.org/extensions/xep-0289.html)), c.‐à‐d. (en gros) un salon réparti sur plusieurs serveurs ; - extensible, la technologie peut être utilisée pour autre chose que des conversations de groupe, ou pour partager tout type de données. Sans trop entrer dans les détails, en gros un salon MIX agit comme un service PubSub et contient des « nœuds » qui sont facultatifs. Chaque nœud gérant une information (présence, messages, sujet sur salon, configuration, etc.), on interagit avec le nœud qui nous intéresse de la même façon que pour un nœud PubSub traditionnel. La XEP étant toute récente, elle comporte encore beaucoup de zones non remplies, elle risque d’évoluer très fortement au cours de l’année, et on verra peut-être des nouvelles utilisations pas forcément liées à la messagerie de groupe. ## MUC light Erlang Solutions (serveur [MongooseIM](https://github.com/esl/MongooseIM)) a également proposé son extension pour les salons de discussions, son nom est MUC light pour l’instant, mais il est probable que cela change. L’extension a été proposée et refusée avec commentaires, donc elle évoluera. De plus, elle entre un peu en compétition avec MIX, chose commune dans le petit monde des standards. L’approche est intéressante car très simple : MUC light reprend MUC, tout en le simplifiant et en l’optimisant pour le mobile (consommation de bande passante et de batterie). Les implémentations auront donc un effort minimaliste à produire. De plus, elle implémente un ensemble de besoins concrets de vrais clients de l’entreprise, qui ont poussé cela en production. Le code du serveur est libre : branche [`muc_light`](https://github.com/esl/MongooseIM/tree/muc_light) du dépôt MongooseIM. Les avantages sont nombreux, en voici quelques‐uns : * basée sur MUC : l’effort pour prendre en charge cette extension est donc minimaliste par rapport à MIX ; * pas basée sur PubSub, qui est très verbeux, et pas complètement pris en charge par les implémentations (MUC est très largement pris en charge) ; * pas de présence, ce qui allège considérablement le trafic ; * basé sur un ensemble de besoins de vrais clients concrets, qui ont vraiment des _group chats_ en production (cela ne part pas de discussions théoriques, dont les implémentations ne sont que probables et à des dates lointaines et inconnues) ; * implémentation serveur existante ; * fonctionne avec MAM ([XEP-0313: _Message Archive Management_](https://xmpp.org/extensions/xep-0313.html)). XMPP Summit et FOSDEM ================ ## FOSDEM La semaine prochaine aura lieu le 19e _XMPP Summit_ à Bruxelles, immédiatement suivi du [_FOSDEM_](http://www.fosdem.org/), où XMPP fait son grand retour dans une _devroom_ « RTC » (_real-time communications_, communications temps réel) avec SIP. Le programme est alléchant (_cf._ [https://fosdem.org/2016/schedule/track/real_time/](https://fosdem.org/2016/schedule/track/real_time/)), avec notamment Nÿco, bien connu ici, qui aura une [conférence samedi à 12 h 50](https://fosdem.org/2016/schedule/event/state_of_xmpp/) (soyez à l’heure, les conférences sont souvent courtes au _FOSDEM_). Edhelas de Movim aura également une conférence, mais dans une autre salle ([salle H.2215 samedi à 17 h 40](https://fosdem.org/2016/schedule/event/movim/)). Goffi fera deux conférences le samedi, [une dans la _devroom_ Python à 13 h 30](https://fosdem.org/2016/schedule/event/decentralized_social_network/), où il expliquera en quoi Python a aidé à développer [_SàT_](http://linuxfr.org/tags/sat/public), et [une dans la _devroom_ RTC à 18 h](https://fosdem.org/2016/schedule/event/decentralized_blogging_with_xmpp/) à propos du développement d’un moteur de blog décentralisé basé sur XMPP. Les différents participants vont également être présents comme l’année dernière au _XMPP lounge_, mais pas en permanence (beaucoup assistent aussi à d’autres conférences). ## XMPP Summit Le _Sommet XMPP_ a lieu deux fois dans l’année, dont une au _FOSDEM_ à Bruxelles, et l’autre à l’_OSCON_. Ce sommet a lieu en marge du _FOSDEM_, les deux jours précédents. Le [programme](https://wiki.xmpp.org/web/Summit_19) est en cours d’écriture. ## Rencontre réseaux sociaux XMPP Plusieurs membres de projets de communications (notamment Diaspora, Movim et SàT) ont décidé de se rencontrer informellement autour d’une bière. Si vous travaillez sur un de ces projets (ou pas, d’ailleurs), n’hésitez pas à nous contacter (en commentaire, par exemple) ou à venir nous voir après une des confs. Nous aimerions bien voir des gens de _GNU Social_, _Friendica_, _Hubzilla_, _SeenThis_, etc. Jingle ====== ## ICE-TCP Pour finir, on peut noter qu’il y a de l’activité autour de Jingle (épisode expliquant le fonctionnement à venir), notamment par le bien connu Peter Saint‐Andre — déjà auteur ou coauteur d’une très grande partie des XEP et des RFC XMPP —, en particulier le transport ICE-TCP est à paraître et va compléter le ICE-UDP déjà disponible (ICE est une méthode pour faire de la traversée de [NAT](https://fr.wikipedia.org/wiki/Network_address_translation "Network Address Translation")). ## Transport HTTP Un nouveau transport HTTP est également sorti, à travers la [XEP-0370: _Jingle HTTP Transport Method_](https://xmpp.org/extensions/xep-0370.html). # Implémentations ## Openfire 4.0 ! Dave Cridland nous a produit un effort remarquable : il a publié [Openfire 4.0](https://community.igniterealtime.org/blogs/ignite/2016/01/11/openfire-400-released) ! Le vénérable serveur XMPP développé en Java sous licence Apache 2.0. ## Movim 0.9 Movim est sorti en version 0.9 ! Ne vous y trompez pas, malgré le numéro de version inférieur à 1, c’est une version majeure. La [liste des changements](https://github.com/movim/movim/blob/master/CHANGELOG.md) est impressionnante ! Une dépêche complète arrivera bientôt. Vous pouvez déjà tester cette nouvelle version sur les Pods [français : _pod.movim.eu_](https://pod.movim.eu/), [néerlandais : _nl.movim.eu_](https://nl.movim.eu/) et [italien : _it.movim.eu_](https://it.movim.eu/) ou jeter un œil sur le [site officiel](https://movim.eu/). ## Prosody 0.9.9 ## Une nouvelle version du populaire serveur Prosody est également sortie, principalement de sécurité. L’[annonce est visible ici](http://blog.prosody.im/prosody-0-9-9-security-release/). ##Gajim 0.16.5## Gajim continue son chemin avec une version mineure améliorant principalement l’implémentation de [MAM](https://xmpp.org/extensions/xep-0313.html). #Dépêches régulières ?# Comme l’activité de XMPP est très dynamique en ce moment, nous sommes plusieurs personnes à vouloir rédiger des dépêches collectives régulières (1 fois/mois) pour donner des nouvelles sur XMPP, un peu dans l’esprit des [dépêches noyau](https://linuxfr.org/tags/noyau_linux/public). Si d’autres personnes sont intéressées à participer, n’hésitez pas !