Compte-rendu d’incident du 22/04/2020 (et suivants)

Après les deux semaines compliquées qui viennent de passer pour JabberFR et la plupart des problèmes résolus, il est temps de faire le point sur la situation ainsi que d’expliquer en détail ce qu’il s’est passé.

Pour les gens qui ne veulent pas le détail technique et horodaté, sachez que tout JabberFR a été déplacé vers un serveur dédié chez Ikoula, quand il était précédemment chez Online depuis 2016, et que tout fonctionne à priori.

Historique

Le 21/04 : Tout à commencé le 21 avril par la dernière faille OpenSSL, qui permet de potentiellement provoquer un crash de service depuis un client en TLS 1.3, ce qui est assez gênant. Nous avons donc planifié une maintenance afin de relancer les services, et par la même occasion redémarrer avec un noyau LTS plus récent. Pour ça nous avons attendu la mise à disposition d’un paquet ArchLinux avec le correctif, qui est arrivé dans la nuit du 21. Une maintenance est planifiée.

Le 22/04 :

  • 13h25 : Un redémarrage du serveur est effectué, à la suite de la mise à jour des différents paquets.
  • 13h35 : Le serveur est toujours indisponible, nous basculons donc en mode « rescue » afin de diagnostiquer le problème
  • 13h35-15h50 : En dehors de quelques problèmes mineurs de fsck rapidement corrigés, nous ne trouvons rien de particulier. Quelques tentatives de reboot infructueuses et nous décidons d’ouvrir un ticket au service client pour éclaircir la situation.
  • 17h50 : Il y a visiblement un problème hardware avec notre disque, nous devons donc faire une sauvegarde, les autoriser à changer le disque, puis une réinstallation.
  • 18h30 : Mise en place d’un serveur temporaire avec l’espace disque suffisant chez Scaleway pour transférer les données, pendant qu’on trie un peu ce qu’on doit garder ou laisser tomber
  • 23h40 : Fin du transfert des données (ironiquement pas limité par la bande passante mais les entrées/sorties disque, les données Prosody étant composées de plusieurs centaines de milliers de fichiers mais faisant seulement 15 Gio, 1,7Gio après compression zstd)
  • 00h10 (le 23) : Demande de changement de disque faite auprès du service client
  • 01h25 (le 23) : Le disque a été remplacé

Le 23/04 :

  • 12h00 : Après avoir tenté en vain de démarrer sur une image ISO spécifique pour faire une installation personnalisée, il est décidé d’installer l’image ArchLinux standard puis de refaire une installation propre en chroot depuis le système de secours.
  • 16h06 : Après avoir fait l’installation, le système ne démarre toujours pas, et nous tombons pile pendant une plage de maintenance planifiée de la « console » online.net (qui contient à la fois les outils d’administration et de contact du support technique)
  • 17h00 : À la vue des nombreux problèmes rencontrés et après une journée complète d’indisponibilité, nous décidons de mettre en place un service temporaire ailleurs pour permettre une continuité de service, nous décidons de prendre une seconde machine temporaire (moins chère car avec moins d’espace disque et de ressources).
  • 18h47 : Le service principal est de retour sur l’IP 51.15.92.143, avec les enregistrements DNS à jour.
  • 20h00 : Le serveur Online est à nouveau disponible, nous mettons en place petit à petit notre installation personnalisée et rapatrions les backups.
  • 21h35 : Nous avions oublié de désactiver la limite de sécurité du nombre de fichiers ouverts par Prosody, qui a été assez vite atteinte, il est donc brièvement indisponible avant de revenir.

Le 24/04 :

  • 15h09 : Fin de la copie des backups, extinction du serveur Scaleway temporaire (utilisé uniquement pour stocker les backups).
  • 18h48 : Prosody arrête de répondre sur le serveur temporaire, suite à un bug dans un module tiers très utilisé, il n’est pas redémarré tout de suite afin d’enquêter sur le problème.

Le 25/04 :

  • 17h05 : L’installation du système est finalisée, mais un problème d’IPMI nous empêche d’y accéder après une demande de redémarrage.
  • 19h45 : Après avoir enchaîné les problèmes de redémarrage et un serveur à nouveau indisponible, la décision est prise de changer d’hébergeur plutôt que continuer avec un serveur plutôt vieux dont l’état matériel ne devrait pas aller en s’améliorant (et faute de trouver une offre équivalente au même endroit). Il se trouve qu’Ikoula avait à ce moment précis une promotion sur son serveur dédié Agile S qui offre la même configuration que celui qu’on avait chez Online, avec un CPU plus récent, la possibilité d’avoir un SSD, et un GPU inutile, pour 1€ de moins TTC.

Le 27/04 :

  • 22h10 : Prosody est à nouveau indisponible à cause d’un bug dans un module tiers. Le module est désactivé pour l’heure.

Du 26/04 au 08/05 : Mise en service progressive du serveur Ikoula, avec restauration des backups, tests, et amélioration de nos processus. Les services web sont les premiers à être remontés, avec un reverse-proxy depuis la machine temporaire. Nous y allons doucement car les jours précédents ont été un peu stressants.

Le 08/05 :

  • Le service est arrêté comme annoncé un peu après 22h, afin de garantir l’intégrité des données sur le nouveau serveur. Les enregistrements DNS sont mis à jour (on avait au préalable mis un TTL de 10 minutes).
  • 22h57 : Le service est lancé sur le nouveau serveur.
  • 23h01 : Le service est relancé avec les bons certificats 😀
  • 23h40 : Prosody est à nouveau en carafe à cause de module tiers, car nous avons oublié de les désactiver sur le nouveau serveur.
  • 23h42 : Le service est à nouveau disponible.

Détails de la nouvelle installation

Nous restons sous ArchLinux, qui est le système que nous savons le mieux administrer et qui nous apporte beaucoup de flexibilité.

En revanche, comme nous étions de toute façon partis pour faire une réinstallation complète dès le 22/04, nous avons décidé de mettre en place une configuration plus complexe mais qui sécurise plus les données de nos utilisateurs tout en nous facilitant la vie.

Après un certain temps passé dans des images de secours fournies par les opérateurs pas forcément aussi utiles qu’on le voudrait, on a également pris la décision de garder un système ArchLinux en clair de 5 Go, qui nous permet de démarrer dessus pendant les phases de maintenance longues, de monter les partitions du système principal voire de kexec dedans afin d’éviter un reboot et/ou des modifications du bootloader en série en cas de panne.

L’idée dès le départ a donc été de mettre en place un système chiffré via LUKS déverrouillable à travers SSH (nécessitant donc une clef SSH et la phrase de passe LUKS). Sous ArchLinux c’est plutôt simple à mettre en place à travers mkinitcpio-systemd-tool (nous comptons documenter un peu mieux la procédure pour pouvoir permettre à n’importe qui de faire de même).

À l’intérieur de ce volume LUKS chiffré, nous avons choisi une partition BTRFS, qui nous permet entre autre de gérer dynamiquement des subvolumes (partitions internes à la partitions, qui peuvent avoir des options différentes telles que de la compression à la volée, déduplication, etc), et qui permet des transferts de partitions incrémentaux sur le réseau plutôt sympathiques, par exemple « ssh serveur btrfs send | btrfs receive » (dd fonctionne aussi mais force à prendre tout l’espace alloué pour la partition, et ne permet pas de le faire en incrémental).

Le système de backups précédent utilisant duplicity était entre autres calibré pour les 100Go de backup FTP fournis par Online, ce qui n’est plus possible, il a fallu donc ré-évaluer nos possibilités. Pour le moment les backups sont donc effectués via borg, vers un espace mis à disposition sur un serveur de mathieui en attendant de prendre une décision, et englobent plus qu’auparavant (intégralité des données de prosody + configurations des logiciels dans /etc + données httpupload) pour un total d’une quarantaine de Go. Ils sont bien sûr chiffrés et la clef n’est pas présente sur le serveur distant.

Nous avons également mis en place etckeeper, plus pour garder une trace des changements (et ne pas les oublier lors de la prochaine réinstallation) que pour s’en servir comme point de restauration ou backup.

Conclusion

Cet incident nous aura permis de constater que la migration est plus simple qu’auparavant, mais qu’il nous faut un moyen de redondance rapide en cas de panne majeure du serveur principal. Les backups plus complets devraient être un bon pas dans cette direction, idéalement nous pourrions périodiquement faire un btrfs send/receive mais cela aurait un coût opérationnel trop important (payer un autre serveur en permanence en plus du principal).

Nous allons prendre le temps de faire des tests dans les semaines à venir pour voir si on peut faire repartir un service opérationnel à partir de ces backups en cas de grosse panne dans des délais raisonnables (en dessous de 2h si possible).

Pour les domaines utilisateurs

Les administrateurs de domaines « utilisateurs » (c’est à dire d’un service qui dont nous avons la gestion du service XMPP mais pas la main sur le DNS) sont invités à mettre à jour leur enregistrement DNS pour un CNAME qui pointe sur jabberfr.org, plutôt qu’un A qui pointerait sur une IP, ou un CNAME qui pointerait vers im/im2.apinc.org.

Sortie de Dino 0.1

Ceci est une traduction en français de l’article de lancement de Dino 0.1 : https://dino.im/blog/2020/01/dino-0.1-release/

Nous sommes heureux d’annoncer la parution de la première version stable de Dino : la version 0.1. Ceci marque une étape importante du processus de développement commencé il y a trois ans, composé du travail combiné de trente contributeurs, dont quatre étudiants du Google Summer of Code et de multiples sprints de développement.

Dino est une application sécurisée et libre de messagerie instantanée décentralisée. Elle utilise le protocole XMPP (« Jabber ») et est interopérable avec les autres clients et serveurs XMPP. Nous nous efforçons de fournir une interface utilisateur intuitive, simple et moderne.

Fenêtre principale de Dino

Motivation : pourquoi Dino ?

Les applications de chat comme WhatsApp et Facebook Messenger sont faciles à utiliser, et ont donc été adoptées par des milliards de gens. Cependant, elles sont propriétaires et les entreprises derrière elles sont fréquemment critiquées pour malmener les données personnelles de leurs utilisateurs. Un certain nombre d’applications de messagerie instantanée ont été crée avec comme but de fournir une alternative plus respectueuse de la vie privée, comme par exemple Signal et Wire, mais même si elles chiffrent les messages et ont libéré leur code source, leurs utilisateurs doivent toujours accepter un service centralisé, et faire confiance à une entreprise privée.

XMPP est un protocole ouvert pour des communications fédérées. Il existe beaucoup de serveurs publics qui communiquent les uns avec les autres, et n’importe qui peut héberger son propre serveur. Cela fournit une excellente base pour fabriquer un client de messagerie instantanée décentralisé et respectueux de la vie privée. Nombre de clients existent déjà pour le protocole XMPP, cependant Dino vise un public différent. Alors que les clients existants ciblent les power users maîtrisant la technologie, l’écosystème XMPP manque d’un client qui soit agréable à utiliser tout en fournissant les fonctionnalités que les gens attendent d’une application de chat moderne. Dino remplit ce manque en tentant d’être sécurisé et respectueux de la vie privée tout en offrant une excellente expérience utilisateur.

Fonctionnalités

Au premier abord, l’interface utilisateur de Dino ressemble à celle d’autres messageries instantanées populaires qui pourraient vous être familières. Sur le côté gauche, vos conversations ouvertes sont listées, ordonnées de façon à ce que les derniers messages reçus soient toujours en haut. Vous pouvez ouvrir de nouvelles conversations ou rejoindre des salons de discussion avec le menu « + ».

Conversation avec une image embarquée et un fichier attaché dans Dino

Messagerie instantanée et plus

Vous pouvez envoyer des messages à vos contacts ainsi qu’à des groupes privés ou à des salons publics. Dino peut être utilisé en même temps que d’autres clients, ce qui fait que vous pouvez continuer une même conversation sur votre téléphone comme sur votre ordinateur. Les messages que vous envoyez et recevez lorsque Dino était éteint sont synchronisés au lancement.

La recherche de messages de Dino, avec les résultats surlignés

Recherche de message

Dino gère le partage d’images et d’autres fichiers, il peut les transférer via votre serveur ou directement à votre contact, en peer-to-peer et sans limite de taille de fichier.

Une recherche de messages avancée vous permet de rechercher et de filtrer votre historique de messages, globalement ou dans une conversation donnée. Après avoir regardé dans les résultats, vous pouvez sauter à un message pour lire davantage de contexte.

Vous pouvez utiliser plusieurs comptes dans la même interface, pour par exemple séparer facilement votre identité au travail et à la maison.

Securité et vie privée

La fenêtre de gestion des clés OMEMO de Dino

La sécurité a été un point central dans le développement de Dino depuis le tout début. C’est pourquoi nous prenons en charge deux méthodes de chiffrement bout-à-bout directement : le standard de chiffrement bien connu OpenPGP vous permet d’étendre la toile de confiance des mails à XMPP. Le chiffrement à double-ratchet OMEMO fournit un système de chiffrement moderne où chaque client a une confiance spécifique, et est utilisé à grande échelle sur le réseau XMPP.

Nous prenons votre vie privée au sérieux dans chaque détail, par exemple vous pouvez empêcher Dino d’informer l’émetteur d’un message que vous l’avez lu, pour qu’ils ne voient pas la double-check sur leurs messages. Dino vous permet de configurer ses fonctionnalités de vie privée par contact : vous pouvez garder vos meilleurs amis au courant de vos activités tout en ne partageant rien avec les étrangers.

Rapide et bien intégré

Dino n’inclue pas un navigateur web complet avec sa consommation de ressources faramineuse et ses nombreuses potentielles failles de sécurité. À la place, il est une application de bureau native, ce qui lui permet d’être léger et de consommer vraiment peu. Dino s’intègre très bien avec le reste de vos applications et services de bureau.

Prêt ?

Après avoir créé un compte XMPP, vous pouvez contacter d’autres personnes à travers du réseau XMPP globalement connecté. Les adresses XMPP sont de la forme utilisateur@example.com. Vous pouvez vous connecter avec un compte existant ou en créer un nouveau !

Compte-rendu de l’AG de JabberFR du 2019-10-09

Détails de la tenue

  • Date : 2019-10-09
  • Heure de début: 19h30
  • Président de séance : xbright
  • Secrétaire de séance : mathieui
  • Nombre de membres présents : 8

Ordre du jour

  • État des lieux des adhésions
  • Renouvellement du bureau
  • Bilan financier
  • Bilan de l’activité & activités prévues
  • Recrutement d’administrateur⋅ice⋅s

Déroulement

État des lieux des adhésions

On comptabilise 26 adhérents au total, dont environ 8 à jour de cotisation. Le montant des cotisations est plutôt supérieur au montant minimum requis, ce qui est une bonne chose.

Bureau

Le bureau précédent était composé de :

  • elghinn (président)
  • Omega (secrétaire)
  • xbright (trésorier)

Link Mauve et Jérémie étaient eux comptés parmi les administrateurs de l’association.

Un nouveau bureau est donc proposé, composé de :

  • Link Mauve (président)
  • mathieui (secrétaire)
  • xbright (trésorier)

Le nouveau bureau est élu à l’unanimité.

Bilan financier

Il y a à l’heure de l’AG 189.42€ présents sur le compte de l’association.

mathieui paye actuellement les frais d’hébergement, plusieurs pistes pour réduire les coûts sont proposées, qui nécessitent toutefois une simplification de la réinstallation de tous les services et l’import des données.

Bilan d’activité

L’activité de l’association a été principalement de maintenir et faire évoluer le serveur, en configurant ou écrivant les logiciels nécessaires, ainsi que représenter la communauté JabberFR au travers de différents évènements autour du libre, comme les RMLL ou le Capitole du Libre. JabberFR aura un stand au Capitole du Libre à Toulouse en Novembre 2019.

Recrutement d’administrateur⋅ice⋅s

Suite à la demande pour de nouveaux administrateurs (Link Mauve étant devenu président et Jérémie ayant arrêté son implication), Minos se propose et est élu à l’unanimité.

Discussion et questions libres

  • Nicosss suggère d’avoir des bulletins d’adhésion imprimés pour les évènements
  • mathieui propose de passer à helloasso pour gérer les adhésions
  • Arnaud J. fait remarquer l’existence de SimpleAsso qui est libre, mais qui nécessite plus de travail d’intégration
  • Arnaud J. indique qu’il aimerait être administrateur quand il aura du temps libre, c’est dûment noté.

Heure de fin: 20h55

Lettre d’actualité XMPP du 3 septembre 2019

Bonjour à toutes et à tous,
Nous vous proposons aujourd’hui une traduction de la lettre d’actualité initialement publiée sur xmpp.org ce 3 septembre.

Bonne lecture !

Beaucoup d’actualités durant ces deux mois de juillet et août : deux évènements à Lyon et Stockholm (et d’autres bientôt), de nouveaux outils, nouvelles versions de serveurs (Openfire, Ejabberd), beaucoup de nouvelles sorties de clients (Kaidan, Salut à Toi, Xabber Android, Movim, Converse, Beagle IM et Siskin IM). Nous essayons également une nouvelle section dans cette newsletter à propos des XEP, c’est-à-dire les spécifications.

N’oubliez pas de soumettre vos articles XMPP/Jabber, tutoriels ou blog posts sur notre wiki.

Articles

Georg Lukas a publié un article à propos des 10 ans de yaxim !

Marek Foss de ProcessOne, nous raconte dans les détails la façon dont ils ont déployé un geocluster XMPP pour la coupe du monde FIFA au Brézil.

Cyril Brulebois présente comment envoyer des messages HTML avec Net::XMPP (en Perl).

Évènements

Maxime “pep.” Buquet fait le rapport du sprint qui a eu lieu à Lyon en juillet dernier dans les bureaux de Wisolv : DOAP – Description Of A Project, réactions, occupant-id, et bien d’autres.

Le prochain sprint XMPP aura lieu à Stockholm, le weekend du 28 et 29 septembre, dans la municipalité de Nacka.

Quelques hackers XMPP se sont retrouvés à Ziegeleipark, Mildenberg, en Allemagne, en août, pour le Chaos Communication Camp 2019, un camp plein-air organisé par le Chaos Computer Club (CCC) tous les 4 ans, qui rassemble des hackers de nombreux endroits.

Le troisième lundi de chaque mois est tenu le meetup de Bavière. Ce mois-ci ce sera le 16 Septembre (lundi).

Si vous organisez un évènement dans votre ville, n’hésitez pas à le soumettre sur notre wiki.

Nouvelles versions de logiciels

Serveurs

Prometheus XMPP Blackbox Exporter (sous licence Apache 2.0) vous permet de sonder vos services XMPP et d’exporter des mesures de vos sondes sur Prometheus.

La communauté Igniterealtime a annoncé plusieurs sorties de versions :

Antonino Siena a annoncé xmpp-http-upload, un composant HTTP upload pour XMPP simple et efficace (sous licence MIT).

Mickaël Rémond a annoncé Ejabberd 19.08, avec JSON Web Token, un validateur de configuration, amélioration de la montée en charge, et d’autres.

Jérôme “Goffi” Poisson a annoncé SàT PubSub 0.3.0, un composant XMPP PEP/PubSub indépendant, qui a pour but d’être complet et universel.

Clients

Kaidan 0.4.0 et 0.4.1 sont sortis, et sont disponibles en téléchargement pour Linux, Windows, et macOS (et expérimental sur Android et Ubuntu Touch).

Jérôme “Goffi” Poisson a sorti Salut à Toi v0.7 « La Commune » avec des tonnes de changements (et il publie des notes de progrès régulières).

Xabber Android 2.6.4 (634) est sorti sur Google Play, et améliore la synchronisation avec l’archive, le temps de démarrage, apporte la prise en charge des références dans les messages (fichiers, suivis, balisage (gras, italique, etc.), mentions, citations), des paramètres pour la compression d’image, des changements visuels, et d’autres.

Timothée Jaussoin a sorti Movim 0.15 – Donati, avec le support des réactions, partage de publication, et plus.

JC Brand a sorti Converse, le client web de chat basé sur XMPP/Jabber, en versions 5.0.0 et 5.0.1, avec beaucoup d’améliorations.

Wojciech Kapcia, de Tigase, a annoncé deux versions de Beagle IM pour macOS et Siskin IM pour iOS.

Bibliothèques

Lance “legastero” Stout a sorti StanzaJS (anciennement connu en temps que Stanza.io), la bibliothèque XMPP JS avec une API JSON, en plusieurs versions 12.x.

JC Brand a sorti la version 1.3.4 de la bibliothèque strophejs.

Florian “Flow” Schmaus a annoncé une extension de la bibliothèque jXMPP avec un framework de test pour “XMPP-Strings”, ainsi que Smack 4.4.0-alpha2.

Services

Arc Games a malheureusement annoncé fermer son service XMPP : « À partir du 19 septembre 2019, Star Trek Online ne supportera plus les connections à notre système de chat interne via un client XMPP. »

Extensions et spécifications

Nous commençons avec les XEPs en LAST CALL (« dernier appel »), puisque ce sont celles avec la plus grande priorité en termes de retour d’information. Nous continuons avec les nouvelles XEPs pour vous faire part de leur existence, et ensuite les XEPs obsolètes, pour que vous puissiez les remplacer progressivement. Nous finissons avec les mises-à-jour. Une dernière section : les spécifications amies.

Last Call

XEP-0353: Jingle Message Initiation

Titre : Jingle Message Initiation

Abstract: This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder’s online resources or choosing a particular online resource.

URL: https://xmpp.org/extensions/xep-0353.html

This Last Call begins today and shall end at the close of business on 2019-08-13.

XEP-0300: Use of Cryptographic Hash Functions in XMPP

Titre : Use of Cryptographic Hash Functions in XMPP

Abstract: This document provides a common wire format for the transport of cryptographic hash function references and hash function values in XMPP protocol extensions.

URL: https://xmpp.org/extensions/xep-0300.html

This Last Call begins today and shall end at the close of business on 2019-08-13.

Nouvelles XEPs

XEP-0421: Anonymous unique occupant identifiers for MUCs

Version 0.1.0 of XEP-0421 (Anonymous unique occupant identifiers for MUCs) has been released.

Abstract: This specification defines a method that allows clients to identify a MUC participant across reconnects and renames. It thus prevents impersonification of anonymous users.

Changelog:
Accepted by vote of Council on 2019-07-17. (XEP Editor (jsc))

URL: https://xmpp.org/extensions/xep-0421.html

XEP-0420: Stanza Content Encryption

Version 0.1.0 of XEP-0420 (Stanza Content Encryption) has been released.

Abstract: The Stanza Content Encryption (SCE) protocol is intended as a way to allow clients to securely exchange arbitrary extension elements using different end-to-end encryption schemes.

Changelog:
Accepted by vote of Council on 2019-06-26. (XEP Editor (jsc))

URL: https://xmpp.org/extensions/xep-0420.html

XEPs Obsolètes

XEP-0387: XMPP Compliance Suites 2018

Version 1.0.0 of XEP-0387 (XMPP Compliance Suites 2018) has been released.

Abstract: This document defines XMPP protocol compliance levels.

Changelog:
Move to Draft as per Council vote on 2018-01-24. (XEP Editor (jwi))

URL: https://xmpp.org/extensions/xep-0387.html

XEPs mises à jour

  • Version 0.3.0 de XEP-0414 (Cryptographic Hash Function Recommendations for XMPP)
  • Version 1.1.0 de XEP-0368 (SRV records for XMPP over TLS)
  • Version 0.3.0 de XEP-0380 (Explicit Message Encryption)
  • Version 1.4.0 de XEP-0184 (Message Delivery Receipts)

Spécificationss amies

Celle-ci peut intéresser la communité ; c’est en Last Call à l’IETF actuellement : https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

Nouveau sprint, nouveaux goodies

Ceci est une traduction de l’article en anglais New sprint, new goodies. La date originale de l’article est le 17 Juillet 2019.

Ce weekend du 14 juillet, un groupe d’enthousiastes s’est rassemblé pour travailler sur de nouvelles fonctionalités dans les différentes implémentations d’XMPP. Wisolv — société de développement sur mesure — nous a généreusement fourni ses locaux à Villeurbanne (à coté de Lyon).

Sur l’ensemble, nous avons réussi à faire pas mal de choses et sommes bien contents du résultat. Au programme : DOAP, Message Reactions, Occupant-id, divers corrections de bugs et discussions, sans oublier quelques progrès sur le client Jabber pour Haiku !

Feux d’artifice du 14 Juillet par olek_impek.

DOAP – Description Of A Project (Description d’un projet)

Il existe beaucoup de listes de logiciels XMPP. Celles-ci ne prennent en considération que les fonctionalités favorites de leur auteur, sont plus ou moins à jour, et en général pas compréhensibles par les machines. Le projet DOAP fournit un moyen à chaque projet d’héberger une description sémantique de celui-ci, qui peut ensuite être utilisé pour présenter des informations sur les logiciels XMPP.

Quelques années plus tôt, Link Mauve a soumi une proposition pour étendre le format DOAP avec des informations que ces listes souhaitent exposer, mais il n’a pas sucité beaucoup d’intérêt… jusqu’à ce sprint !

PulkoMandy a écrit un ensemble de feuilles de style XSLT pour présenter ces informations. Link Mauve a écrit un schéma XML ainsi qu’un script Javascript intégrant les informations directement sur les XEPs (vous pouvez en voir un exemple ici avec la XEP bookmarks). Tous les auteurs de clients présents au sprint ont écrit un fichier DOAP pour leur projet.

Reactions

Movim a été un des premiers clients à implémenter les réactions, en utilisant la spécification Message Attaching. Les développeurs de Dino pensaient pouvoir améliorer la situation, notamment certains problèmes avec les clients qui n’implémentent pas la XEP, ce qui les a poussé à écrire une nouvelle spécification il y a déjà plusieurs semaines. Cette protoXEP a été envoyée dans l’inbox ce weekend !

Edhelas a adapté son implémentation dans Movim en utilisant cette nouvelle spec, mathieui a travaillé sur Poezio (pas encore mergé, mais les changements dans Slixmpp le sont), et fiaxh et larma ont commencé à l’implémenter dans Dino.

Occupant-id

Occupant-id est un autre protoXEP qui a été soumise ce weekend par larma.

Elle spécifie que les composants MUC fournissent un identifiant stable et unique qui serait attribué par salon par utilisateur (bare real JID). Ceci est utile en particulier pour les salons semi-anonymes où il n’est pas possible de s’assurer que deux messages viennent du même participant entre deux reconnections.

Certaines applications client pensent déjà la demander dans les salons semi-anonymes pour des fonctionalités telles que Last Message Correction ou Reactions.

Un module prosody est aussi disponible et fonctionne avec la dernière version (0.11) ou trunk.

Encore plus

PulkoMandy a commencé à porter Jabber4Haiku — maintenant Renga — à gloox. Fiaxh a travaillé sur stable and unique IDs dans Dino. Slixmpp utilise enfin des ids non prévisibles. J’ai travaillé avec mathieui sur des problèmes sur l’API asynchrone de Poezio et Slixmpp. Une nouvelle version de xmpp-parsers est sortie, corrigeant les problèmes dans la documentation au passage !

La suite

J’aimerais remercier Wisolv une fois de plus de nous avoir hebergé ce weekend.

Le mois prochain des membres de la communauté seront présent au booth XMPP à FrosCon, ainsi qu’à CCCamp2019. Venez visiter notre page d’évènements pour plus d’informations sur nos activités !

Lettre d’actualité XMPP du 3 mai 2019

Bonjour à toutes et à tous,
Nous vous proposons aujourd’hui une traduction de la lettre d’actualité initialement publiée sur xmpp.org ce vendredi 3 mai.
Au sommaire : des retours d’expérience de migrations vers XMPP, des nouvelles de Salut à Toi, des explications sur le chiffrement OMEMO, et un retour sur le dernier sprint XMPP tenu à Berlin.
Bonne lecture !

Bienvenue sur la lettre d’actualité XMPP.

Si vous connaissez un article, un tutoriel ou un billet de blog que vous souhaiteriez voir figurer dans cette lettre, merci de l’ajouter sur le wiki XMPP.

Actualités

Rafał Leśniak a publié un article à propos des défis relevés par Forward Health, une plateforme de messagerie basée au Royaume-Uni et dédiée aux services de santé, qui a migré d’une solution tierce de discussion vers XMPP (en anglais)
C’est une lecture intéressante pleine d’enseignements sur comment XMPP est perçu par des nouveaux venus découvrant ce protocole.

Continuer la lecture

Lettre d’actualité XMPP du 3 avril 2019

Bonjour à toutes et à tous,
Nous vous proposons aujourd’hui une traduction de la lettre d’actualité initialement publiée sur xmpp.org ce mercredi 3 avril.
Bonne lecture !

Bienvenue sur la lettre d’actualité XMPP.

Si vous connaissez un article, un tutoriel ou un billet de blog que vous souhaiteriez voir figurer dans cette lettre, merci de l’ajouter sur le wiki XMPP.

Actualités

Un travail a été proposé auprès la communauté Open Source Design pour concevoir les badges de la “Compliance Suite”.
C’est une initiative qui cherche à créer des éléments graphiques que les développeurs pourront appliquer sur leurs logiciels clients et serveurs afin d’identifier les niveaux de conformité de ceux-ci.

Une page wiki dédiée au suivi des intégrations a été créée sur le wiki de la XMPP Standards Foundation (XSF).
Ceci dans l’idée de visualiser les projets ou services qui fournissent des fonctionnalités comme les notifications mais ne proposent pas XMPP dans leurs intégrations.
Cette page peut être utilisée afin de suivre les intégrations sur toute sorte de logiciel et les rendre visibles de telle sorte que d’autres personnes puissent y travailler ou les promouvoir.

Continuer la lecture

Lettre d’actualité XMPP du 28 février 2019

Bonjour à toutes et à tous,
Nous vous proposons aujourd’hui une traduction de la lettre d’actualité initialement publiée sur xmpp.org ce jeudi 28 février.
Au sommaire : un retour sur la présence XMPP au FOSDEM, le lancement du successeur d’ejabberd SaaS nommé Fluux, les déboires du client Monal sur l’App Store français, et enfin les logiciels publiés et mis à jour ce mois-ci.
Bonne lecture !

Bienvenue sur la lettre d’actualité XMPP.

Si vous connaissez un article, un tutoriel ou un billet de blog que vous souhaiteriez voir figurer dans cette lettre, merci de l’ajouter sur le wiki XMPP.

FOSDEM

Début février, le rassemblement annuel FOSDEM19 s’est tenu à Bruxelles. De nombreux amateurs de XMPP étaient présents et 5 conférences à propos de XMPP ont été présentées.

Continuer la lecture

Lettre d’actualité XMPP du 31 janvier 2019

Bonjour à toutes et à tous,
Mieux vaut tard que jamais : nous vous proposons aujourd’hui une traduction de la lettre d’actualité initialement publiée sur xmpp.org le 31 janvier.
Bonne lecture !

Bienvenue sur la lettre d’actualité XMPP.

Si vous connaissez un article, un tutoriel ou un billet de blog que vous souhaiteriez voir figurer dans cette lettre, merci de l’ajouter sur le wiki XMPP.

Cette semaine (NDT : celle du 30 janvier) à Bruxelles, nous avons tenu un sprint dédié à l’UI/UX (interface et expérience utilisateur), le 23ᵉ sommet XMPP, et durant le weekend plusieurs développeurs et passionnés de XMPP vont assister au FOSDEM 2019.

Continuer la lecture

Lettre d’actualité XMPP du 4 janvier 2019

Bonjour à toutes et à tous,
Nous vous proposons aujourd’hui une traduction de la lettre d’actualité initialement publiée sur xmpp.org ce vendredi 4 janvier.
Au sommaire, entre autres sujets : un coup d’œil dans le rétroviseur pour les vingt ans de XMPP, Movim comme alternative à la censure sur Tumblr, la prise en charge de XMPP par les appareils de domotique Logitech, une nouvelle passerelle entre Matrix et XMPP…
Bonne lecture !

Bonne année 2019, et bienvenue sur la lettre d’actualité XMPP.

Si vous connaissez un article, un support de cours ou un billet de blog que vous souhaiteriez voir figurer dans cette lettre, merci de l’ajouter sur le wiki à l’adresse https://wiki.xmpp.org/web/News_and_Articles_for_the_next_XMPP_Newsletter

Actualités

C’est aujourd’hui (NDT : le 4 janvier) le 20ᵉ anniversaire de Jabber !
Jabber a été standardisé et renommé XMPP par la suite.

Si vous souhaitez remonter le temps, jetez un coup d’œil à l’interview de Jeremie Miller en 2001 par Linux Magazine, ou l’annonce originale de la sortie sur Slashdot par Jeremie le 4 janvier 1999.

Le Linux Journal a publié un article Lessons in Vendor Lock-in: Messaging, qui propose une réflexion à propos de la messagerie instantanée sur les 20 dernières années, et le fait que le “verrouillage par les fournisseurs” (vendor lock-in) reste toujours une problématique d’actualité.

Continuer la lecture