Planete JabberFR

Parlons XMPP - épisode 7 - cas pratiques: SleekXMPP et SàT

(pour lire les épisodes précédents, suivez l'étiquette correspondante)

Comme cela a été demandé plusieurs fois, nous allons pour cet article faire un petit cas pratique avec deux bots XMPP.

SleekXMPP

c'est SleekXMPP que nous allons tester, que je n'avais jamais utilisé avant cet article. Il s'agit d'une bibliothèque Python qui se veut simple, avec peu de dépendances, et gérant tout avec des greffons. Vous pouvez aussi utiliser le fork (amical) fait pour Poezio, Slixmpp qui a réécrit le cœur de la bibliothèque pour tout gérer en asynchrone (sans thread) via le récent asyncio (aussi il faut une version de Python >= à 3.4, alors que SleekXMPP fonctionne avec Python 2 et 3).

Sans entrer trop dans les détails, que vous trouverez sur le site officiel avec plusieurs tutoriels (http://sleekxmpp.com/), faisons un simple bot qui répond à des commandes ad-hoc (aucun lien avec Tintin, voir plutôt l'épisode 6):

Ce script est une adaptation de l'exemple donné dans le dépôt officiel (voir sa licence). Des explications sont données après le script, et il devrait fonctionner avec Python 2.6 ou supérieur ou 3.1 ou supérieur.

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sleekxmpp
from sleekxmpp import jid

JID="mon_super_bot@mon_super_server.tld"
PWD="mon_super_mot_de_passe"
ADMIN=jid.JID("mon_admin@mon_super_server.tld")
CMD_ENVOI = u'envoi message'
CMD_DECO = u'déconnexion'
CMD_ADMIN = u'gros bouton rouge'


class MonSuperBot(sleekxmpp.ClientXMPP):

    def __init__(self):
        sleekxmpp.ClientXMPP.__init__(self, JID, PWD)
        self.add_event_handler("session_start", self.session_start)
        # note 1
        self.register_plugin('xep_0030')
        self.register_plugin('xep_0004')
        self.register_plugin('xep_0050')
        self.register_plugin('xep_0199', {'keepalive': True, 'frequency':15})

    def session_start(self, event):
        # note 2
        self.send_presence()
        self.get_roster()
        self['xep_0050'].add_command(node='monbot',
                                     name=u'Commandes de monbot',
                                     handler=self._handle_commands)

    def _handle_commands(self, iq, session):
        form = self['xep_0004'].makeForm('form', 'bot')
        form['instructions'] = u'Choisissez une commande'
        options = [CMD_ENVOI, CMD_DECO]

        # note 3
        if session['from'].bare == ADMIN:
            options.append(CMD_ADMIN)

        form.addField(var='command',
                      label=u'commande',
                      ftype='list-single',
                      required=True,
                      options=options
                      )

        session['payload'] = form
        session['next'] = self._handle_command_complete
        session['has_next'] = False

        return session

    def _handle_command_complete(self, payload, session):
        form = payload
        command = form['values']['command']

        if command == CMD_ENVOI:
            self.send_message(mto=session['from'],
                              mbody="Message important !",
                              mtype='headline')
        elif command == CMD_DECO:
            self.disconnect(wait=True) # note 4
        elif command == CMD_ADMIN:
            # note 5
            if session['from'].bare == ADMIN:
                session['notes'] = [('warning', 'BOOM !')]
            else:
                raise ValueError("ce n'est pas un admin !")
        return session


if __name__ == '__main__':
    xmpp = MonSuperBot()
    if xmpp.connect(): # note 6
        print(r"\o/")
        xmpp.process(block=True)
    else:
        print(":(")

Explications

Après avoir importé sleekxmpp, nous utilisons quelques constantes (n'oubliez pas bien sûr de remplacer JID et PWD par des valeurs adaptées) pour simplifier, les exemples officiels permettent de manière plus élégante de préciser jid et mot de passe en ligne de commande.

Notre bot se comportera comme un client, nous héritons donc de sleekxmpp.ClientXMPP.

au niveau de la note 1 nous implémentons les greffons qui gèrent les XEPs qui nous intéressent :

  • disco (XEP-0030) pour annoncer ad-hoc, comme expliqué dans l'épisode 3
  • les formulaires de données (x-data, XEP-0004) et les commandes « ad-hoc » (commands, XEP-0050), expliquées dans l'épisode 6
  • la XEP-0199 permet d'envoyer et de répondre à des « pings », afin de s'assurer que la connexion et les logiciels sont toujours actifs.

À la note 2 nous envoyons notre présence et demandons la liste de contacts (« roster »), ce qui est requis par les RFCs, certains serveurs pouvant refuser de répondre si ce n'est pas fait.
Ensuite nous utilisons le greffon des commandes « ad-hoc » pour ajouter le point d'entrée à nos commandes.

Ce point d'entrée appellera la méthode « _handle_commands », et nous utilisons un formulaire (comme expliqué dans la XEP-0004) pour spécifier nos commandes. La liste « options » nous sert à indiquer nos commandes dans l'ordre voulu.

Au niveau de la note 3, nous profitons de l’identification forte de XMPP pour vérifier très simplement si le demandeur utilise l'adresse (jid) de notre compte privilégié, que nous avons indiqué dans la constante « ADMIN ». Nous aurons ainsi un jeu de commandes différent si nous utilisons le compte privilégié ou un autre.
Évidemment si vous voulez profiter de l'authentification forte, il faut vous assurer que tout est en ordre au niveau des certificats et du chiffrement (ce que fait a priori SleekXMPP de base, consultez la documentation pour plus d'informations).

L'ajout de commande se fait ici par une liste à choix unique (« list-single »), mais vous pouvez demander d'autres choses comme des mots de passe ou des jids, tout est expliqué dans la XEP-0004.

Quelques précisions sur ad-hoc : à chaque « page » vous pouvez effectuer une action:

  • cancel pour annuler
  • prev pour revenir en arrière
  • execute pour lancer une commande ou continuer la session
  • next pour passer à la page suivante
  • complete pour finir la sesssion

Ces actions sont gérées par sleekXMPP à travers le dictionnaire « session », la meilleure documentation que j'ai trouvée sur le sujet est le code lui-même : dans le fichier « sleekxmpp/plugins/xep_0050/adhoc.py » présent dans les sources.

Ad-hoc permet également d'indiquer un message, une « note », pour donner l'état de votre commande, elle peut avoir un type « info », « warn » (warning: attention) ou « error » (erreur).

Dans le code nous indiquons que nous avons notre dernière « page » par « session['has_next'] = False », et qu'il faut traiter la réponse dans « _handle_command_complete ». Oui c'est un peu contre-intuitif d’avoir à la fois has_next à False, et un next, mais ce dernier correspond à la réponse et non à une nouvelle page.

Passons à ces réponses. Nous regardons ce qui est dans le formulaire pour savoir quoi faire. Dans le premier cas nous envoyons un message manchette ou « headline » (voir l'épisode 2)

Dans le deuxième cas (au niveau de la note 4) on fait une déconnexion. Alors j'ai eu un problème ici avec SleekXMPP, que j'utilise pour la première fois comme indiqué plus haut : il faudrait pour faire propre terminer la session ad-hoc avant de déconnecter, mais je n'ai pas trouvé de moyen simple de le faire, vu que la déconnexion est immédiate et qu'il faut retourner le dictionnaire session pour terminer la séquence. Peut-être que je suis passé à côté de quelque chose, n'hésitez pas préciser en commentaire si vous avez une astuce.

Passons à la note 5: je refais une vérification du jid avant de lancer la commande privilégiée. La raison est simple: le formulaire est envoyé du client au bot par le serveur sans être vérifié par ce dernier, c'est au bot à le faire. Il est interdit d'ajouter une nouvelle commande, mais comme je doute que SleekXMPP conserve le formulaire d’origine pour vérifier qu'il n'y a rien de nouveau, un attaquant pourrait ajouter la commande privilégiée sans être admin. Cette vérification permet de l'éviter.

Pour faire propre il faudrait envoyer une réponse XMPP précisant que l'action est interdite, mais pour faire simple je me suis contenté d'une exception ici.

Enfin, au niveau de la note 6 on se connecte. Pour un serveur local de test, si vous n'avez pas de serveur DNS configuré comme il faut, vous pouvez spécifier l'adresse ip ou le nom de domaine local en dur, ainsi que le port (par exemple « self.connect(('localhost', 5222)) ». Si votre certificat n'est pas valide, vous pouvez aussi utiliser « use_tls=False » (pour les tests uniquement !). La documentation de SleekXMPP vous indiquera plus clairement comment gérer correctement les certificats.

Enfin, un autre problème que j'ai eu avec SleekXMPP: il ne semble pas possible avec ma version (1.3.1) d'indiquer de ne pas utiliser de commande « exécuter » ou de spécifier son équivalence (ce qui est pourtant possible avec la XEP-0050). Il faudrait qu'elle soit absente ou équivalent à « compléter ». Vous allez ainsi avoir un bouton qui sera inutile, et provoquera même une erreur. Là encore si quelqu'un plus habitué à la bibliothèque peut indiquer en commentaire comment corriger cela. Utilisez donc le bouton « compléter » (ou « finir ») et non « exécuter » de votre client.

Voilà la capture de notre bot piloté par Gajim:

bot piloté par Gajim

Salut à Toi

Pour indiquer les ajouts faits au code, nous utilisons un bot dénommé « Sabot ». Nous gérons les sources avec Mercurial (sur https://repos.goffi.org/). Celui-ci permet d'exécuter une commande via des crochets (« hooks »), dont un qui est lancé à chaque série de commits: incoming. Nous avons donc ceci dans notre hgrc:

[hooks]
incoming.sabot = /chemin/vers/hg_sabot_hook.sh

Pour le bot, nous profitons du côté multi-interfaces de SàT: SàT a une architecture qui permet pour un même client (et donc les mêmes profils, comptes, etc) d'avoir différentes interfaces (console, ligne de commande, bureau, web, etc).

Nous avons donc créé le compte comme un compte normal grâce à Primitivus, l'interface console (nous sommes sur un serveur sans interface graphique disponible). On peut joindre le salon désiré (ici sat@chat.jabberfr.org), et le mêttre en favori (grâce à la XEP-0048), ainsi que gérer l'entrée automatique (« autojoin »). Il ne reste plus qu'à envoyer le message quand le script hg_sabot_hook.sh est appelé, ce que nous faisons à l'aide de « jp », l'interface en ligne de commande:

#!/bin/sh

#on s'assure d'abord que D-Bus est lancé
eval `/chemin/vers/dbus-launch.sh`

REPOS_BASE="http://repos.goffi.org/sat"
PROJECT_FULL="Salut à Toi"
REPOS="$REPOS_BASE/rev/$HG_NODE"
MUC="sat@chat.jabberfr.org"

hg log -r $HG_NODE --template "Commit from {author|person} on $PROJECT_FULL\n{desc}\n$REPOS" | jp message -cp sabot $MUC

(le vrai script est un tout petit peu plus long puisqu'il gère aussi les noms des autres dépôts).

L'option « -c » indique de se connecter si ça n'est pas le cas, et « -p sabot » précise qu'il faut utiliser le profil « sabot »

Le script dbus-launch.sh s'assure juste que D-Bus est bien lancé et réutilisé entre les sessions de l'utilisateur:

#!/bin/sh
DBUS_PATH="/tmp/.dbus.`whoami`"
if [ ! -e $DBUS_PATH ]; then
        dbus-launch --sh-syntax > $DBUS_PATH
        chmod 400 $DBUS_PATH
fi
cat $DBUS_PATH

Voilà pour ces cas pratiques. La prochaine fois, je parlerai soit de PubSub, soit de Jingle.

Conférences des RMLL

Salut à vous,

 
j'attendais de voir les vidéos publiées, c'est désormais le cas. Notre passage aux RMLL s'est très bien passé et a été l'occasion de se faire de nouveaux contacts et d'avoir des discussions très intéressantes. J'ai particulièrement apprécié participer à la table ronde sur les nouveaux médias, et rencontrer Arno de SPIP/SeenThis (je connaissais déjà les autres participants).
 
Je n'ai pas eu l'occasion de voir beaucoup de conférences car j'étais au stand, mais je viens bien sûr vous recommander de voir celles sur XMPP ou en particulier la table ronde sur les nouveaux médias:

Toutes les interventions étaient vraiment intéressantes, y compris dans le public. Merci à ceux qui y ont participé, et à Olicat pour avoir animé.

En ce qui concerne XMPP, il y a bien sur les conférences de Libervia et Movim. Pour Libervia la qualité est vraiment mauvaise, aussi je vous recommande plutôt la version de Pas Sage En Seine, c'est la même conférence:

Libervia

Movim

Et sur un plan plus technique, la conférence « PubSub, Microblogage et XMPP » dont j'ai déjà parlé plusieurs fois:

En dehors de ça comme je l'ai dit je n'ai pas pu voir beaucoup de conférences. J'ai particulièrement aimé celle de Paul Kocialkowski sur Replicant (en anglais, il y en a aussi eu une en français que je n'ai pas pu voir, je ne sais pas si c'est le même ou pas, du coup je mets les 2):

À voir aussi celle de Gelnior (de Newebe/Cozy cloud) sur la conception graphique, je l'avais vue aux JDLL:

Enfin, autre conférence que je n'ai pas (encore) vue, mais comme on en parle dans la table ronde je la mets ici, la conférence « SPIP et sa communauté »:

 
Il y en a eu beaucoup d'autres, aussi n'hésitez pas à préciser en commentaires celles que vous conseillez.

Appel à la communauté: aidez moi à traduire la série « Parlons XMPP »

Salut à vous,

la série que j'ai commencé fin juin, « Parlons XMPP » a plus de succès que ce à quoi je m'attendais (surtout en été !), et a incité plusieurs personnes à regarder un peu plus ce que peut faire ce protocole.

Du coup j'aimerais bien traduire la série en anglais (ou autre !), mais je n'ai vraiment pas le temps de le faire moi même, vu que je dois déjà travailler sur Salut à Toi, et que l'écriture des articles en français me prend beaucoup de temps.

Alors je veux tenter le coup avec une traduction collaborative, un peu comme ce que fait framasoft pour traduire des articles de l'anglais vers le français, mais dans l'autre sens.

Tous les articles sont sous licence libre (Cc By-SA), et il faut bien noter que je parle souvent de « Salut à Toi » sur lequel je travaille, même si je parle aussi d'autres projets.

Bref, je tente le coup, j'ai ouvert un framapad avec le premier article.

Si vous voulez participer ajoutez votre nom ou pseudo pour être dans les auteurs de la traduction, et vous pouvez traduire en dessous du paragraphe en français. Je demanderai une relecture par un anglophone à la fin.

En dehors des 6 articles déjà publiés, je pense continuer au rythme d'un par semaine au moins pendant l'été.

Pour aider à la traduction, c'est par ici: https://bimestriel.framapad.org/p/parlons_XMPP

Merci d'avance !

Goffi

Parlons XMPP - épisode 6 - les commandes à distance

(pour lire les épisodes précédents, suivez l'étiquette correspondante)

 
Aujourd'hui nous allons parler d'une de mes fonctionnalités favorites dans XMPP : les commandes à distance. Il s'agit de la possibilité pour 2 entités XMPP d'exécuter des actions à distance de manière générique.

La première méthode, assez peu utilisée à ma connaissance, est via la XEP-0009 (oui c'est une vieille, elle date de 2001), qui donne une méthode pour utiliser XML-RPC à travers XMPP.
XML-RPC est un Système de communications inter processus, c'est à dire un moyen pour 2 entités de communiquer à distance. Vous pouvez ainsi exécuter des commandes indépendamment du langage de programmation, en ayant des données décrites (est-ce que je reçois un entier ? Une chaîne de caractères ?). Ceci est particulièrement adapté pour la communication de machines à machines, quand on sait déjà quelles méthodes sont disponibles et ce qu'elles font. Le cas type est une interface de programmation (ou API) pour permettre de contrôler quelque chose, comme un serveur par exemple.

La deuxième méthode est appelée commandes « ad-hoc » (de circonstance), et c'est la XEP-0050 qui les explique. L'idée est aussi de pouvoir exécuter de manière générique des commandes, mais cette fois sans savoir à l'avance ce qui va être disponible, et en pensant plutôt à une interaction humain/machine, bien que machine/machine soit bien sûr tout à fait possible.

Le cas typique d'utilisation est la configuration d'un service, mais ce peut être utilisé pour n'importe quoi.
Ce qui rend cette fonctionnalité particulièrement puissante, c'est qu'elle fait partie de XMPP et donc peut profiter de tous ses avantages, en particulier l'authentification forte (quand on parle à server@example.net, on sait qu'on ne parle pas à quelqu'un d'autre) et la liste de contacts (roster) avec leurs groupes. Nous avons ainsi un système de permissions simple à mettre en œuvre et efficace.

Prenons un exemple: vous êtes administrateur sur Prosody (pour mémoire, un serveur XMPP populaire) – pour cela il vous suffit de donner votre jid dans la variable « admins » dans la configuration –, et vous voulez… pouvoir administrer votre serveur. Pas besoin de s'embêter à avoir une page web dédiée avec mot de passe etc, il vous suffit d'avoir un client XMPP qui gère les commandes ad-hoc (Gajim par exemple), et d'entrer l'adresse de votre serveur.

Exemple ci-dessous avec Libervia, l'adresse libervia.org est celle du serveur, voici ce que, en tant qu'admin, je peux voir.

capture d'écran des commandes ad-hoc pour un admin avec Libervia

Le « Send Announcement to Online Users » (envoyer une annonce à tous les utilisateurs en ligne) est particulièrement utile juste avant une mise à jour.

Avec un compte lambda, voilà ce que l'on voit :
capture d'écran des commandes ad-hoc pour un utilisateur lambda avec Libervia

Malheureusement avec certains clients, l'accès est tout sauf intuitif. Je pense que l'exemple le pire est Psi : pour accéder aux commandes du serveur il faut aller dans la découverte des services (« service discovery ») soit via le menu « General » soit en cliquant droit sur votre profil, puis cliquer sur le nom de votre serveur dans la liste des services, puis enfin cliquer sur l’icône en forme de terminal, appelée « execute command » (exécuter une commande).

Dans Gajim c'est plus simple (clique droit sur votre profil puis « exécuter une commande »), dans Swift c'est dans le menu Actions => Run Server Command (Exécuter une commande serveur). Si vous voulez exécuter des commandes sur un jid arbitraire dans Gajim, il vous faut passer par le menu « Découvrir les services », comme avec Psi ; je n'ai pas l'impression que ce soit possible avec Swift.

Ci dessous une capture de Movim, ces commandes sont dans le menu « actions »:

les actions dans Movim

Même sans être administrateur, les commandes « ad-hoc » peuvent vous être utiles. Par exemple, vous avez oublié de déconnecter votre client chez vous et vous vous trouvez chez un ami. Il vous suffit de vous connecter, et de spécifier le jid complet, avec la ressource, de votre client à la maison. SàT par exemple vous permet à l'heure actuelle de changer votre statut voire de vous déconnecter. Gajim permet en plus de transférer les messages non lus ou de quitter des salons de discussions.

Accès à un client Gajim à distance

Il est facile d'imaginer à quel point cette fonctionnalité peut être utile pour l'administration ou la surveillance de serveurs, pour la robotique, la domotique, le contrôle à distance de votre ordinateur, de votre bot XMPP, etc.

Voyons un autre cas pratique que nous avons implémenté dans Salut à Toi : on couple les commandes « ad-hoc » avec D-Bus. Pour ceux qui ne connaissent pas, D-Bus est un autre système de communication inter-processus qui a été développé par Freedesktop comme un standard commun dans les bureaux libres, en s'inspirant de l'existant et en particulier du DCOP de KDE. Il est donc très largement utilisé dans les logiciels libres, et permet de piloter beaucoup de logiciels courants.
En liant D-Bus et ad-hoc, SàT permet de créer très facilement une télécommande universelle, pilotable depuis n'importe quel client XMPP compatible (y compris sur votre téléphone, ce qui est particulièrement intéressant pour une télécommande), et en prime avec gestion des permissions par groupe.

Cette fonctionnalité est montrée dans le courte vidéo ci-dessous, on autorise les membres du groupe « coloc » à piloter une instance de VLC, pratique quand on fait une séance cinéma dans la colocation :).

Nous allons ajouter également la possibilité d’exécuter des scripts ou des commandes shell, on pourra ainsi très facilement autoriser tous les administrateurs d'un serveur à le redémarrer ou à avoir son statut.

Petite note sur le fonctionnement : les commandes ad-hoc, comme à peu près tout ce qui demande de la transmission d'informations typées dans XMPP, se basent sur les « Data Forms » (formulaires de données, XEP-0004). Cette extension standardise donc les formulaires, et permet de demander des booléens, des mots de passes ou encore des listes de jids.

J'en profite aussi pour vous donner le lien vers la conférence « PubSub, microblogage et XMPP » que j'ai faite aux RMLL il y a un peu plus de 2 semaines. J'y explique en 20 min les bases de PubSub et du microblogage dans XMPP, ainsi que l'intérêt des 2 XEPs que nous avons publiées (cf ce journal sur DLFP). J'en reparlerai bien sûr dans un prochain article.

Bien qu'ayant plusieurs idées en tête, je ne suis pas encore décidé pour le prochain article, il est possible que je parle de PubSub, de copie de fichiers, de chiffrement de bout en bout, ou de tout autre chose…

Conférence « PubSub, microblogage et XMPP » en ligne

Un petit billet pour vous dire que ma conférence rapide (20 min) et technique sur le (micro)blogage dans XMPP, « PubSub, microblogage et XMPP » vient d'être publiée.

Nous avons beaucoup travaillé dessus cette dernière année, et je pense qu’on va voir XMPP arriver en force dans ce domaine dans les mois à venir.

À voir aussi sur https://rmll.ubicast.tv/videos/pubsub-microblogage-et-xmpp/

Parlons XMPP - épisode 5 - les discussions de groupe (suite) et les transports

(pour lire les épisodes précédents, suivez l'étiquette correspondante)

 

Autre point intéressant par rapport à IRC, XMPP conserve l'ordre des messages, par exemple si vous avez la conversation suivante :

[Morphée] tu peux avoir la pilule rouge
[Lué] OK je prends celle-là
[Morphée] ou la bleue

Avec XMPP vous êtes sûrs que c'est la pilule rouge qui a été choisie, vous évitez ainsi les confusions (et de vivre dans l'ignorance).

Comme dit précédemment, la présence est envoyée au service MUC, pas besoin de vous renommer en xxx_away pour prévenir que vous n'êtes pas là, il suffit d'utiliser l'état associé (et vous pouvez utiliser le message de statut pour compléter). Une autre information utile nous est fournie par la XEP-0085 : les notifications d'états de discussion (« Chat State Notifications »). Cette extension permet de savoir ce que fait un utilisateur par rapport à une conversation : est-ce qu'il est actif dessus ? Est-ce qu'il est parti ? Ou est-il en train de taper un message ? Ceci fonctionne aussi avec les conversations de groupes, et c'est vraiment pratique à l'usage.

Quand vous commencez à fréquenter beaucoup de salons, vous avez envie que votre client en garde la liste, ou d'y aller automatiquement à la connexion ; c'est l'extension « Bookmarks » (marque-pages, XEP-0048) qui permet cela, et vous pouvez ainsi retrouver vos salons en changeant de client (puisque la liste est gardée sur le serveur). Alors petite parenthèse là-dessus, nous sommes plusieurs à penser que cette extension a des problèmes : elle est censée gérer les urls mais personne ne l'utilise de cette façon, elle ne gère pas les étiquettes, et elle pose des problèmes de concurrence, ou si on veut l'utiliser hors standard. Nous (plusieurs développeurs dont Edhelas de Movim que vous connaissez ici) avons donc commencé à écrire une alternative, qui pourrait même être utilisée pour synchroniser les marque-pages dans les butineurs, y compris différents. Affaire à suivre.

En plus de garder la liste, il est bien sûr utile de pouvoir facilement donner un lien vers un salon. La XEP-0045 défini les URI à utiliser pour cela (ici), avec la possibilité de préciser un mot de passe ou d'inviter du monde. C'est de cette façon que l'adresse suivante est cliquable : sat@chat.jabberfr.org ; il suffit de prendre l'adresse du salon, d'en faire une url XMPP en préfixant avec « xmpp: » et d'ajouter « ?join » à la fin pour indiquer qu'on lie un salon MUC. Pour que le lien fonctionne, il faut que vous ayez associé dans votre système un client XMPP avec ces urls (comme vous associez un butineur à une url http:).

Tout n'est pas toujours parfait non plus dans XMPP, et parfois l'héritage historique, ou les évolutions, ou la trop grande souplesse, amènent à un peu de complications.
Ainsi pour MUC il existe 2 méthodes pour inviter quelqu'un : directe (XEP-0249) ou arbitrée (« mediated invitation » définie dans le XEP-0045). La seconde méthode envoie une invitation à travers le salon lui-même, elle est surtout utilisée pour les salons « réservés aux membres » qui sont rares.
Elle risque en outre de se faire bloquer (si un utilisateur n'accepte pas, par exemple, que les messages de personnes dans sa liste de contacts – « roster » –, nous verrons dans un futur article comment faire cela). L'invitation directe est envoyée au jid à inviter sans passer par le salon – d'où son nom –, c'est celle qui est à préférer.
En pratique cette situation ne pose de problèmes éventuels qu'aux développeurs de clients, et il suffit souvent d'implémenter la XEP-0249.

D'un autre côté les extensions permettent des fonctionnalités alléchantes. Ainsi le « Federated MUC » (salons MUC fédérés, XEP-0289) permet de lier des salons entre eux pour qu'ils soient les miroirs les uns des autres. Ceci permet de choisir un serveur plus proche géographiquement de vous, ou d'avoir une solution de repli en cas de problème avec le vôtre. Des discussions sont en cours actuellement pour faire un « MUC 2 » basé sur « PubSub », bref XMPP est un protocole qui est loin d'être figé.

Bon tout ça c'est bien joli, mais IRC est tout de même un protocole qui fonctionne relativement bien, et qui est très populaire, ce serait bien de pouvoir communiquer avec.
XMPP gère des passerelles (ou « gateways » ou encore « transports »), c'est un moyen de communiquer vers un réseau extérieur sans rien modifier à votre client.

La passerelle est souvent sous forme d'un composant qui vient se greffer à votre serveur, et qui traduit le réseau externe (un peu pompeusement appelé « legacy » – réseau hérité – dans le jargon XMPP). La grande force de leur fonctionnement est que le mécanisme pour s'enregistrer est standardisé, et que pour votre client c'est du XMPP classique.
Une passerelle se concentrera la plupart du temps sur un réseau en particulier, et si elle est complète tentera de traduire le maximum voire toutes les fonctionnalités du réseau en question.

C'est la XEP-0100 qui explique le fonctionnement des passerelles, et elle réutilise – comme souvent – des XEP existantes, en l’occurrence « service discovery » dont on a parlé dans l'épisode 3, la XEP-0077 qui gère les enregistrements de comptes et la XEP-0144 (« Roster Item Exchange », échange d’éléments de la liste de contacts) pour l'ajout, la modification, ou la suppression des contacts (ou des « amis » sur les réseaux d'ours en peluche ou tout le monde s'aime et s'observe).
Disco permet, comme on l'avait vu, de nommer les passerelles, voire même pour les plus courantes d'avoir un type dédié. Ainsi il est possible d'identifier une passerelle IRC grâce au couple catégorie/type « conference/irc ».

Ci-dessous, une vielle capture de SàT, tirée de la première vidéo de présentation (2011 !) qui montre un gestionnaire de passerelles. Vous remarquerez peut-être qu'il y a une passerelle vers XMPP lui-même, elle peut être utile pour regrouper différents comptes XMPP si votre client ne le gère pas d'origine.

vieille capture gestionnaire passerelles SàT

Quelques remarques sur les passerelles:

  • souvent vous devez fournir un mot de passe pour vous connecter sur votre compte sur le réseau externe. C'est pratique car vous n'aurez pas à vous souvenir de X mots de passe (une fois enregistré dans la passerelle, plus besoin d'y penser), mais ça veut dire que vous le fournissez à la fois au serveur, et à la passerelle. Il vous faut donc faire confiance aux logiciels utilisés, mais aussi aux administrateurs des serveurs concernés. Encore une fois, il vaut mieux héberger soi-même son serveur.

  • vos communications passeront donc sur le serveur externe. C'est évident, mais il est bon de rappeler que le chiffrement de XMPP ou les précautions prises par vos administrateurs n'auront plus aucun effet une fois passé sur l'autre réseau (et donc selon le réseau, il est possible qu'on enregistre vos conversations, qu'on fasse du commerce avec vos données, etc). Il est toutefois possible d'utiliser du chiffrement de bout en bout dans certains cas, mais nous y reviendrons dans un futur article.

  • les fonctionnalités disponibles sont l'intersection de ce que sait faire XMPP, ce que sait faire/à implémenté votre passerelle, et de ce que sait faire/à implémenté votre client. Dans certains cas vous pouvez tout faire comme avec votre client d'origine du réseau externe (voire plus, avec le chiffrement de bout en bout par exemple), dans d'autres non.

  • si vous utilisez une passerelle vers un réseau non standard voire hostile, il est possible que votre passerelle cesse de fonctionner du jour au lendemain si le protocole change. Utilisez des standards !

Un service souvent utilisé pour les passerelles est Spectrum 2. Pour IRC, je vous recommande particulièrement biboumi: http://biboumi.louiz.org/. C'est fait par la même équipe que Poezio dont j'ai parlé précédemment, et c'est une passerelle très complète et vraiment simple d'utilisation.

Petit détail encore lié à la décentralisation de XMPP : si votre serveur n'a pas la passerelle que vous voulez, vous pouvez parfaitement utiliser une passerelle sur un autre serveur (si celui-ci ne l'interdit pas explicitement), mais cela veut dire que vous devez faire confiance à cet autre serveur pour votre identifiant/mot de passe et pour vos conversations.

Ce fonctionnement par passerelles standardisées et côté serveur permet d'avoir des logiciels qui se concentrent sur un réseau pour pouvoir communiquer avec le mieux possible, de garder le client qu'on apprécie et auquel on est habitué, d'éviter d'avoir à se souvenir de dizaines de mots de passes, d'avoir toutes nos communications au même endroit, ou encore de laisser les administrateurs s'occuper des mises à jour pour tout le monde d'un coup. C'est un gros atout dans la manche de XMPP.

Enfin, il existe aussi des techniques pour synchroniser un salon MUC XMPP avec un canal IRC (ou autre), qui vont du simple bot qui se contente de répéter tout entre les 2 salons (le plugins « Parrot » – Perroquet – permet de faire ça très facilement avec SàT), à celui un peu plus élaboré qui va créer plusieurs connexions sur IRC pour simuler les différents occupants du salon (c'est ce que faisait le désormais abandonné xib – merci Link Mauve pour le nom –). Cette dernière option risque de poser des problèmes avec les administrateurs du serveur IRC, aussi le mieux serait d'avoir un serveur multi-protocoles (ou tout le monde sur XMPP !).

Ceci clos notre tour des MUCs. Je n'ai pas parlé des détails comme les rôles car ils sont calqués sur IRC, et vous pouvez lire la XEP si vous voulez savoir vraiment comment tout cela fonctionne à l'intérieur. J'y reviendrai peut-être dans le futur pour expliquer d'autres XEPs, ou si MUC 2 voit le jour (ce qui semble bien engagé).
La prochaine fois je pense sortir un peu de la messagerie instantanée pour parler des commandes « ad-hoc » (de circonstance).

Parlons XMPP - épisode 4 - les discussions de groupes

(pour lire les épisodes précédents, suivez l'étiquette correspondante)

Dans le milieu du développement logiciel, et surtout dans le logiciel libre, les discussions de groupes sont très populaires, le plus souvent via IRC (Internet Relay Chat).
Ce vénérable protocole fait ce qu'on lui demande, et XMPP s'en est fortement inspiré. Voyons ça de plus près.

Les discussions de groupes utilisées actuellement sont appelées MUC pour « Multi-User Chat » et sont définies par la XEP-0045. Cette dernière standardise et étend la solution utilisée à l'origine, appelée « groupchat ». Comme tout ceci est calqué sur IRC, je vais expliquer au fur et à mesure les différences majeures avec lui.

Il est possible d'accéder à un salon situé sur n'importe quel serveur depuis n'importe quel serveur (encore une fois, tant que ça n'est pas explicitement interdit dans la configuration). Les salons ont un jid, comme les utilisateurs, qui est de la forme nom_salon@service. Par exemple celui de Salut à Toi est sat@chat.jabberfr.org : « sat » est le nom du salon, « chat.jabberfr.org » le service.

La ressource est utilisée pour les occupants du salon: sat@chat.jabberfr.org/goffi correspond à l'occupant appelé « goffi » sur le salon sat@chat.jabberfr.org. Ah, petit détail que j'ai oublié de vous préciser dans les précédents articles: tout est unicode en XMPP, y compris le jid. Vous pouvez donc utiliser un pseudo arabe ou russe. Mais attention : certains caractères unicodes se ressemblent fortement, aussi il peut y avoir un risque de confusion visuelle entre 2 mots qui se ressemblent graphiquement, qu'on appelle « homoglyphes » : par exemple « gοffⅰ » ressemble à « goffi » mais il utilise des caractères différents. Ce problème est mentionné dans un rapport technique unicode: http://www.unicode.org/reports/tr36/. Aussi, ne vous basez pas uniquement sur un pseudonyme pour identifier quelqu'un (surtout qu'il est possible qu'il soit réutilisé par quelqu'un d'autre entre 2 sessions).

Le pseudonyme (« nickname » ou « nick » en plus court) est lié au salon et non au service : vous pouvez vous appeler « toto » sur un salon et « titi » sur un autre, et il peut y avoir quelqu'un d'autre qui s'appelle « titi » également sur un troisième salon. Ceci est une autre grosse différence avec IRC où on a un seul pseudonyme par serveur, qui sera utilisé pour tous les salons (canaux ou « channels » chez IRC) de celui-ci.

Pour entrer ou sortir d'un salon, ou changer de pseudonyme, on envoie une présence disponible (ou pas) directement à salon@example.net/pseudo_désiré, mais ceci est normalement géré par votre client.

Il est possible d'écrire directement à tous les occupants du salon (en dessous c'est un message de type « groupchat » qui est envoyé au bare jid du salon), ou d'avoir une discussion privée avec un membre (on écrit normalement au jid complet – ou full jid – du destinataire).

Un salon peut être public ou caché (il n’apparaîtra alors pas dans la liste des salons), non anonyme ou semi-anonyme (dans le premier cas tout le monde peut voir le jid réel d'un occupant, dans le second seuls les modérateurs et administrateurs le peuvent), persistant ou temporaire, ouvert ou accessible uniquement à une liste blanche d'utilisateur ou encore protégé par un mot de passe, modéré ou pas.

Ces paramètres se règlent normalement à la création du salon, ou se modifient après coup via l'option idoine de votre client (sur Gajim : clique droit sur un onglet de salon => Gérer le salon => Configurer le salon). Selon le service utilisé, vous pouvez configurer plus ou moins de choses, par exemple limiter le nombre maximal d'occupants.

Une fonctionnalité souvent implémentée est l'historique, ou « back log » : quand vous arrivez dans un salon, le service vous envoie les X derniers messages, vous permettant ainsi de comprendre le contexte de la conversation en cours.

Aussi, si une archive publique du salon est conservée (on parle de salon « loggué »), le service doit vous avertir (c'est obligatoire dans la XEP), ce qui est un autre bon point par rapport à IRC. Il faut bien sûr garder à l'esprit que n'importe qui dans le salon peut garder une archive au risque de la publier sans votre consentement.

Bon tout ça c'est bien joli, mais une grande force d'IRC c'est sa simplicité : pas de compte à créer, il faut juste choisir un pseudo (unique), un serveur et roulez jeunesse ! Eh bien vous ne serez pas déçus, XMPP propose exactement la même chose avec les connexions dites « anonymes ». Pas d'anonymat au sens de Tor ici, mais plutôt la possibilité d'avoir un compte temporaire, avec un jid plus ou moins aléatoire, le temps de vous connecter. Ceci est disponible de base mais doit souvent être explicitement autorisé dans la configuration du serveur, et la plupart du temps les connexions anonymes sont limitées au serveur local, pas de communication avec les autres (pour éviter les pourriels).

Si vous voulez faire des conversations à la IRC de manière simple et intuitive, et si vous aimez la console, je vous recommande fortement Poezio qui est un excellent client XMPP, et qui joue la simplicité : de base, sans rien changer à la configuration, vous serez connecté anonymement sur le service MUC de Poezio. Il s'inspire de Irssi/Weechat, et reprend les commandes de ces derniers (ou plus généralement d'IRC). Ci-dessous le message au premier lancement, sans avoir touché à la configuration, on voit le jid anonyme attribué le temps de la session.

capture Poezio

Bon cet épisode est déjà suffisamment long, mais je n'ai pas fini avec les MUCs, aussi on en reparlera la prochaine fois, probablement avec les transports.

Libervia/Salut à toi aux RMLL à Beauvais toute la semaine

Salut à tous,

Nous serons présents avec Libervia/Salut à Toi pendant toutes les Rencontres Mondiales du Logiciel Libre à Beauvais, avec présence aux journées grand public (moi je n'y serai qu'à partir de dimanche, Souliane dès demain), puis au village associatif, et 3 conférences:

  • conférence « Libervia : repenser nos communications » lundi 6 juillet de 14h40 à 15h20 (salle 124) ;
  • table ronde/débat sur les nouveaux médias avec Timothée Jaussoin (Edhelas) de Movim, Pouhiou (Framasoft), Luc Fievet (April), Arno* (SPIP/SeenThis), Souliane et moi pour SàT, le lundi 6 juillet de 16h20 à 18h (amphi Brunuel) ;
  • PubSub, microblogage et XMPP jeudi 9 juillet de 15h00 à 15h20 (salle 203/204).

Si vous passez dans le coin, c'est l'occasion de discuter de vive voix.

Parlons XMPP - épisode 3 - le cœur et les extensions (suite)

(pour lire les épisodes précédents, suivez l'étiquette correspondante).
 
En plus de cette partie centrale, des fonctionnalités peuvent être ajoutées, d'où le X de XMPP (pour eXtensible).
 
Les extensions sont rédigées sous la forme de « XEP » (XMPP Extension Protocol), idée héritée — si je ne m'abuse — de Python. C'est de cela qu'on parle quand on voit les cryptiques XEP-0XXX dans les fonctionnalités gérées d'un serveur ou d'un client. Pas besoin évidemment de savoir cela pour utiliser un client XMPP, mais il peut être utile de lire une extension (elles se trouvent sur https://xmpp.org/xmpp-protocols/xmpp-extensions/) pour bien comprendre à quoi sert une fonctionnalité. Deux parties sont particulièrement utiles sans avoir à entrer dans les détails d'implémentation : la partie « abstract » (résumé) tout en haut qui indique ce que la XEP fait, et la section « introduction » (la toute première section) qui explique un peu plus les raisons et les cas d'utilisations de l'extension.
 
résumé de la XEP-0045
 
Une XEP peut décrire une fonctionnalité, une procédure (par exemple la XEP-0001 explique le cycle de vie des XEPs elles-mêmes), un héritage historique (c'est à dire le fonctionnement de quelque chose créé avant la XMPP Standard Foundation), une information (comme des bonnes pratiques), voire une blague (si si, y'a des histoires de toto dans les XEPs aussi !). Elle peut avoir plusieurs statuts (expliqués dans la XEP-0001, je ne sais pas s'il existe une version traduite en français quelque part). Il est intéressant de noter que beaucoup de XEPs sont « experimentales », et donc techniquement pas (encore) des standards, mais souvent implémentées tout de même. De telles XEPs peuvent changer fortement avant le passage au statut de « brouillon » (« Draft »), puis de standard final.
 
Pourquoi je vous parle de tout ça ? Pour que vous compreniez bien une chose: XMPP ce n'est pas que de la messagerie instantanée !
 
Voici quelques exemples d'extensions intéressantes:
 
  • Extended Stanza Addressing (Adressage de « stanzas » étendue, XEP-0033): permet d'envoyer un message à plusieurs destinataires à la fois, ou de faire des copies carbones ou des copies carbones invisibles (comme le … oui oui vous voyez où je veux en venir)
  • Multi-User Chat (Discussions multi-utilisateurs, XEP-0045): les discussions de groupes, à la IRC.
  • Ad-Hoc Commands (commandes de circonstance, XEP-0050): un système générique pour gérer tout type de commandes. Lié aux permissions des utilisateurs, c'est un outil absolument génial !
  • vcard-temp (Cartes virtuelles, version temporaire, XEP-0054): la façon historique de gérer des cartes de visites, une sorte de profil public. Une nouvelle extension va la remplacer à terme (la XEP-0292)
  • Jabber Search (Recherche Jabber/XMPP, XEP-0055): pour chercher des jid, utilisé en général par les annuaires.
  • Publish/Subscribe (Publication/Abonnement, XEP-0060): un très gros morceau, qui permet la publication de tout type d'information, et sa récupération en fonction de permissions, avec un système de notification en temps réel.
  • XHTML-IM (XEP-0071): pour publier avec un sous-ensemble de XHTML, c'est à dire avec une mise en forme (écrire en gras ou mettre une image par exemple).
  • Gateway Interaction (Communication avec les passerelles, XEP-0100): permet de gérer les passerelles, c'est à dire des liens avec des réseaux extérieurs
  • Personal Eventing Protocol (protocole d'événements personnels, XEP-0163): une sorte de Publish/Subscribe simplifié
  • Jingle (XEP-0166): Négociation de session pair à pair (P2P), avec un grand nombre d'applications possibles, la plus connue étant la visioconférence.
  • Serverless Messaging (Communication sans server, XEP-0174): permet, comme indiqué, de se passer des serveurs
  • Message Archive Management (gestion des archives des messages, XEP-0313): permet de récupérer des messages ou autre (ça fonctionne aussi avec publish/subscribe) selon certains critères comme une date. Utilisé notamment pour avoir votre historique de conversations sur votre serveur (et ainsi y accéder depuis tous vos clients).
 
Et dites-vous bien qu'on ne vient que de gratter la surface.
 
Plusieurs de ces extensions seront expliquées dans de futurs articles.
À noter aussi qu'on utilise souvent des noms courts pour désigner les extensions par exemple « MAM » pour « Message Archive Management ». Ces noms sont normalement indiqués en fin de XEP, dans les appendices (« Document information »): c'est le « short name » (nom court).
 
Avec toutes ces extensions, on va se retrouver avec des clients ou serveurs qui gèrent l'une ou l'autre, comment se mettre d'accord ? Eh bien grâce à une autre extension (mais tellement indispensable et couramment implémentée qu'on peut presque la considérer comme standard de base): « Service Discovery » (découverte de services, XEP-0030, nom court : « disco »)).
 
Le principe est simple, chaque client ou serveur ou composant (un composant est un service qui vient se greffer à un serveur, voir plus bas) dit qui il est, ce qu'il sait faire, ou les éléments associés.
 

qui il est

Une adresse XMPP (le jid) peut être utilisée par beaucoup de monde: un serveur, un client, un « bot » (robot, nom qu'on utilise pour un programme qui automatise des tâches, agissant souvent comme un client), une passerelle, etc.
 
Quand un client (ou autre) en voit une, il est utile de savoir à quoi on parle, par exemple pour afficher de telle ou telle façon dans l'interface (c'est grâce à cela que votre client peut afficher une passerelle d'une autre façon que les clients normaux).
 
C'est l'identité de disco qui permet ça, et elle donne une catégorie (par exemple « client » ou « serveur »), un type (dans client par exemple ça peut être « bot », « web », « game » — jeu —), et un nom libre (par exemple « ejabberd »). Vous avez une liste des différentes catégories et les types associés ici : https://xmpp.org/registrar/disco-categories.html.
 

ce qu'il sait faire

 
XMPP grâce à son côté extensible, est très riche en fonctionnalités, aussi il est indispensable de savoir ce que le logiciel avec lequel on discute est capable de faire. Ce sont les « features » (fonctionnalités) indiquées par disco, c'est pour cette raison que parfois quand vous discutez avec quelqu'un une icône est grisée, par exemple la visioconférence: cela indique que le client en face indique qu'il ne sait pas la faire, ou plus exactement n'indique pas qu'il sait la faire.
 
Ces fonctionnalités sont liées à des espaces de nommage (namespaces) qui sont indiqués dans les XEPs concernées, vous avez aussi une liste qui permet de retrouver une partie des XEPs depuis un espace de nommage ici : https://xmpp.org/resources/schemas.
 

les éléments associés

 
En plus de l'identité et des fonctionnalités disponibles, une entité XMPP peut avoir des éléments associés. Ce peut être un serveur qui indique que des salons de discussions sont disponibles à telle adresse, ou une passerelle vers tel réseau.

 

essayons

Pour que cela soit plus clair, prenons un exemple. « jp », l'interface en ligne de commande de Salut à Toi, permet d'obtenir le disco d'une entité avec la commande « jp info disco », essayons avec le serveur jabber.fr :
 
 
% 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]
 
 
On voit ici que jabber.fr sait gérer la version historique des vcards (vcard-temp, XEP-0054) ou les commandes ad-hoc (http://jabber.org/protocol/commands, XEP-0050), qu'on discute avec un serveur (server/im) qui s'appelle « ejabberd ». On voit également que plusieurs services sont disponibles, par exemple chat.jabberfr.org. Regardons de plus près :
 
% jp info disco chat.jabberfr.org
Features:
 
http://jabber.org/protocol/disco
http://jabber.org/protocol/muc
http://jabber.org/protocol/muc#unique
jabber:iq:browse
jabber:iq:last
jabber:iq:register
jabber:iq:time
jabber:iq:version
urn:xmpp:ping
vcard-temp
--
Identities:
 
Public Chatrooms (conference/text)
--
Items:
 
[...]
JabberFR (13) [jabberfr@chat.jabberfr.org]
[...]
 
 
On voit qu'on a affaire à un service de salons de discussions (conference/text), qui utilise le protocole « Multi-User Chat » (discussions multi-utilisateurs, http://jabber.org/protocol/muc), qui est à ce jour le seul disponible pour les discussions de groupes (nous y reviendrons). Les éléments « Items » contiennent ici la liste des salons, avec le nom, le nombre d'occupants, et le jid correspondant, j'ai tronqué la liste qui était très longue.
 
Dans les informations de jabber.fr, vous avez peut-être remarqué la section « extensions », il s'agit d'une XEP (la XEP-0128) qui permet d'étendre disco pour tout type d'informations, dans le cas d'ejabberd ici, c'est pour indiquer les adresses de contact du serveur, mais elles ne sont pas renseignées pour jabber.fr.
 
Ci-dessous, la fenêtre disco de Gajim:
 
disco chez Gajim
La première fois que j'ai essayé XMPP, avec Psi au début des années 2000, j'ai été un peu intimidé par le menu « service discovery », qui permet d'afficher quasi directement les informations que nous venons de voir. Ce genre de menu est souvent, à mon sens, affiché un peu trop « brut » dans les clients XMPP : utiliser disco directement (c.-à-d. en dehors de ce qui est automatisé par le client) relève déjà de l'utilisation avancée.
 
 
En bonus, je vais rapidement évoquer l'extension « software version » (version logicielle, XEP-0092) qui permet, comme son nom l'indique, de savoir à quel logiciel on parle, et le système d'exploitation utilisé. jp permet d'afficher ces informations avec « jp info version », essayons sur jabber.fr :
 
% jp info version jabber.fr
Client name: ejabberd
Client version: 2.1.13
Operating System: unix/linux 3.2.0
 
On connaît désormais la version d'Ejabberd utilisée, pratique quand on veut savoir si une fonctionnalité est présente, ou un bogue corrigé. Et cela fonctionne avec toute entité qui implémente la XEP, pas uniquement les serveurs:
 
% jp info version chat.jabberfr.org
Client name: MU-Conference
Client version: 0.9-svn (Jan 27 2014)
Operating System: Linux 3.2.0-4-amd64
 
Voilà, connaître les extensions permet de vraiment savoir ce qu'on peut faire avec un client ou un serveur. La prochaine fois je pense m'attaquer aux discussions de groupes, et voir ce qui change par rapport à IRC.

Parlons XMPP - épisode 2 - le cœur et les extensions

Maintenant qu'on sait de quoi on parle, voyons à quoi ressemble le cœur du protocole.
 
 
À la base XMPP c'est 3 (anciennement 2) RFCs: la 6120, la 6121, et la 6122 (il y en a d'autres, mais ces 3 là sont les principales). Elles expliquent tout le cœur comme l'envoi de messages, les informations de présence, les statuts, etc.
 
Sans trop entrer dans les détails qui vont concerner surtout les développeurs, on peut rapidement expliquer que XMPP se base sur 3 types d'éléments, ou « stanzas »:
 
  • <presence/> pour indiquer principalement… notre information de présence (parfois on y accroche aussi d'autres choses comme des infos sur notre avatar ou nos capacités, mais ne nous égarons pas). La présence est relayée par votre serveur à toutes les personnes à qui vous avez donné l'accès (voir plus bas).
      On peut associer un état et un message à notre présence. L'état peut être un des suivants (les noms peuvent changer selon votre client)
    • disponible (par défaut): vous êtes en ligne normalement
    • away (absent): vous êtes absent pour une courte période
    • chat (discussion): vous avez particulièrement envie de parler
    • dnd (do not disturb – ne pas déranger): vous êtes occupé (souvent appelé « busy » aussi dans les clients)
    • xa (eXtended Away – durablement absent): vous êtes absent pour une longue période
      Le message de statut permet spécifier en langage clair votre disponibilité (par exemple « je regarde un film, ne pas déranger »), même si en pratique c'est utilisé pour tout type de message (beaucoup de gens mettent une citation par exemple).
  • <message/> un envoi de message de type j'envoie et j'oublie. Il existe 5 types de messages :
    • chat (discussion): le plus connu, celui qui sert à la messagerie instantanée simple
    • error (erreur): celui-là est normalement géré par les logiciels directement, il se traduit souvent par un fenêtre vous indiquant dans votre client que quelque chose s'est mal passé
    • groupchat (discussion de groupe): comme « chat », mais pour les discussions à plusieurs. En pratique la différence ne concerne que les développeurs et cela devrait être transparent dans le client
    • headline (manchette): un message important, une annonce. Normalement, ces messages ne sont pas gardés hors ligne, aussi si vous n'êtes pas connecté au moment du message, vous ne devriez pas l'avoir. Ces messages ne sont pas faits pour y répondre. Un exemple typique est une annonce de maintenance du serveur imminente
    • normal : un type méconnu et pourtant intéressant. Il s'agit d'un message ayant généralement un sujet, et en dehors d'une conversation instantanée. Oui oui, exactement comme un courriel ! C'est plus ou moins son équivalent XMPP.
    À cela s'ajoute la gestion des « thread » (fils de discussion), mais nous en parlerons une autre fois.
  • <IQ/> (Info/Query – information/requête): utilisé pour tout ce qui est de type question/réponse (il est obligatoire de répondre à une requête <IQ/>, au pire par une erreur). Son utilisation concerne plutôt les développeurs, c'est la base de la plupart des fonctionnalités que vous utilisez : cet élément sert à dire « je veux connaître ou modifier telle information »
 
Je ne veux pas trop entrer dans les détails techniques, mais il me semble essentiel de connaître les différents types de messages et de présences pour bien comprendre son client.
 
À noter un point excellent avec XMPP, et largement sous exploité : XMPP sait nativement gérer les différentes langues, grâce à son héritage de XML (xml:lang). Autrement dit, vous pouvez spécifier un message normal ou de statut à la fois en français, en allemand et en slovaque. C'est un atout majeur que nous comptons bien exploiter dans Libervia.
 
Passons maintenant à une autre partie essentielle : la liste de contacts.
 
Dans le monde XMPP, on l'appelle « roster » (qui se traduit par « liste » ou « tableau de service »). À chaque contact que vous y ajoutez, vous pouvez associer 0, 1 ou plusieurs groupes (« famille », « amis », etc), un nom (donné par l'utilisateur et non le contact), ainsi qu'une information d'abonnement (« subscription »).
 
L'abonnement permet de savoir si vous avez autorisé votre contact à avoir votre information de présence, et si le contact vous a autorisé à voir la sienne. C'est pour cela que quand quelqu'un vous ajoute dans sa liste de contacts, votre client, par exemple Gajim, vous demande si vous l'autorisez à connaître votre information de présence. Il est tout à fait possible d'avoir autorisé un contact à vous voir sans qu'il ne vous autorise à le voir (et inversement évidemment), voir qu'aucun des deux ne soit autorisé à voir la présence de l'autre (mais je pense que la plupart des clients suppriment le contact du roster dans ce cas).
 
Les groupes sont associés aux contacts, et non l'inverse (ce n'est pas une liste  liste de groupes qui contiennent des contacts), c'est la raison pour laquelle il est impossible d'avoir un groupe sans contact associé (c.-à-d. vide).Là encore les groupes sont à mon sens sous-exploités dans le monde XMPP, nous y reviendrons.
 
 
Voilà pour aujourd'hui. J'ai finalement préféré couper la partie extensions pour le prochain article, pour éviter de trop charger.
 

Parlons XMPP - épisode 1 - les bases

Salut à Vous,
 
Bon, comme je trouve vraiment dommage que XMPP soit mal connu ou compris, j'ai décidé de commencer une série d'articles pour vous expliquer ce que c'est.
 
Ces articles sont destinés à un public averti, mais pas forcément de développeurs, et j'espère qu'il vous aidera à comprendre les intérêts de ce protocole et à mieux utiliser vos logiciels.
 
Étant développeur du projet Salut à Toi, je donnerai probablement souvent des exemples avec.
 
Donc commençons par les bases.
 
XMPP c'est quoi ? C'est un protocole de messagerie et de présence standard, et extensible (XMPP signifie « eXtensible Message and Presence Protocol », soit « protocole de présence et messagerie extensible »), c'est à dire qu'il est documenté et utilisé comme une référence (ici validée par un organisme de standardisation : l'IETF). Ceci permet à tous les logiciels qui l'utilisent de parler la même langue, et d'être interopérables. Il s'agit d'un protocole libre, c'est à dire que vous pouvez obtenir la documentation et l'utiliser gratuitement, sans restriction légale ou technique, et que vous pouvez l'améliorer ou le modifier (mais si vous déviez et que vous ne proposez pas vos modifications, vous risquez de perdre la compatibilité avec les autres logiciels).
 
XMPP est décentralisé et fédéré, c'est à dire que vous pouvez avoir des serveurs un peu partout, ils pourront (s'ils ne l'interdisent pas explicitement dans leur configuration) communiquer entre eux.
 
C'est un protocole populaire, de nombreux logiciels permettent de l'utiliser : en serveurs on peut citer Prosody, Ejabberd, Open Fire, Tigase, Mongoose.im, Metronome, etc. En client: Gajim, Poezio, Pidgin, Psi, Swift, Jappix, Movim, et bien sûr Libervia/Salut à Toi (je vous laisse chercher les sites officiels vous-même). Une liste plus complète (serveurs, clients et bibliothèques) est disponible ici: https://xmpp.org/xmpp-software/.
 
Si vous ne voulez pas installer un serveur chez vous, de nombreux serveurs publics sont disponibles: en France on peut citer ceux de l'APINC (jabber.fr, im.apinc.org, etc), de La quadrature de Net, etc. Une petite liste (la page n'est pas à jour, n'hésitez pas à contribuer !) est disponible ici en français, sinon vous pouvez regarder sur https://xmpp.net/directory.php ou http://www.jabberes.org/servers/ (oui il y en a beaucoup !). Mais je vous recommande très fortement d'installer votre propre serveur ou de vous approcher d'une association locale avec qui vous pouvez communiquer facilement : d'une part si vous installez vous-même, ça vous permet de mieux maîtriser vos données, et d'autre part si vous voulez une fonctionnalité en particulier, il vaut mieux pouvoir demander facilement aux administrateurs une mise à jour.
 
Bon maintenant qu'on sait tout ça, essayons de créer un compte.
 
Une fois un serveur installé ou un serveur public choisi, vous pouvez créer un compte. Vous aurez alors une adresse, un « jid » (pour Jabber ID, « Jabber » est l'ancien nom du procole, ce nom appartient désormais à une société privée, il est juste gardé ici pour des raisons historiques).
 
Cette adresse est de la forme nom_local@domaine.tld/ressource, ou en forme canonique (ce qu'on appelle le « bare jid ») nom_local@domaine.ext. Par exemple la mienne est goffi@jabber.fr . Celà ne vous rappelle rien ? Et oui ça ressemble beaucoup aux adresses de courrier électronique !
 
Mais alors c'est quoi la ressource ? La ressource est liée au logiciel client que vous utilisez pour vous connecter : XMPP a été pensé dès l'origine pour permettre à plusieurs clients de se connecter en même temps (il y a 10 ans, peu de protocoles de messagerie le permettaient, et se reconnecter ailleurs signifiait souvent la déconnexion du premier client), et cette ressource permet de les identifier. Autrement dit, vous n'avez une ressource que quand vous êtes connectés, et elle est différente pour chaque client que vous utilisez : si je me connecte avec Libervia, Gajim et Movim, j'aurais 3 ressources différentes.
 
Il y a eu plusieurs écoles pour nommer la ressource, parfois on s'en servait pour indiquer le lieu de connexion (« maison », « bureau »), les clients mettaient souvent leur nom par défaut (« gajim », « psi »). Aujourd'hui, il est admis qu'il vaut mieux avoir une ressource non prédictible, car sinon quelqu'un peut savoir si vous êtes connectés ou pas (même si vous ne souhaitez pas que ça se sache) en faisant une requête à cette ressource. Il vaut donc mieux laisser le serveur choisir la ressource pour nous.
 
Enfin, votre ressource est associée à une priorité: elle permet de déterminer, si plusieurs ressources sont connectées, laquelle va recevoir le message. Mais nous y reviendrons plus tard.
 
Dans le prochain épisode je vous parlerai des extensions et de la découverte de fonctionnalités.
 
Voilà, dites-moi si vous êtes intéressés par cette série, si cela vous semble trop technique, ou si vous avez des remarques ou des corrections à faire. Je publie la série en même temps sur DLFP, et le tout est sous licence CC By-SA, donc n'hésitez pas à réutiliser, diffuser ou modifier !

Campagne d'adhésion pour financer le développement de Libervia

Salut à vous !
 
 
Ça y est, on y est, c'est le lancement de la campagne d'adhésion à l'association « Salut à Toi ». Cette campagne, si elle réussit, va nous permettre de nous salarier et développer le projet pendant 1 an, de sortir une version stable pour la fin d'année, et de préparer plusieurs évolutions.
 
Avant tout un petit rappel, sur Libervia et Salut à Toi. Ci dessous une vidéo courte (3 min) expliquant le projet:
Libervia est donc un outil de communication (ou « réseau social » comme disent certains) qui se distingue par plusieurs points. Il est multi-interfaces, et non web uniquement, il se base sur un standard (XMPP) ce qui le rend compatible avec d'autres logiciels comme Gajim, Jappix ou Movim, et il suit une ligne éthique et philosophique claire, notamment expliquée dans son contrat social.
 
Le projet est déjà bien avancé et utilisable, il est disponible dans des distributions GNU/Linux comme Debian ou Arch (mais les versions commencent à dater, nous en avons une nouvelle proche de sortir), et vous pourrez voir en consultant le site officiel qu'il offre des fonctionnalités originales.
 
Nous souhaitons qu'il soit développé dans un cadre éthique et solidaire aussi nous cherchons à nous salarier à travers une association loi 1901 autogérée.
 
Si la campagne est un succès, nous prévoyons les évolutions suivante:
  • une version stable et utilisable par le grand public pour la fin d'année 2015
  • des passerelles vers d'autres réseaux libres, comme Diaspora*, SeenThis, ou SMTP
  • une version permettant des connexions anonymes (via TOR)
Ceci est réalisable en 2015. Pour l'année 2016 nous envisageons:
  • la création d'un boitier pré-installé, qu'il suffira de brancher sur sa connexion Internet
  • l'intégration du projet dans d'autres logiciels libres comme Blender, GIMP ou Inkscape, afin de pouvoir travailler avec ses contacts sans quitter lesdits logiciels. Cette partie est particuièrement excitante et ambitieuse, mais demandera beaucoup de travail.
 
Afin de ne pas surcharger ce billet je n'entrerai pas plus dans les details, nous avons rédigé une dépêche pour le site de référence linuxfr expliquant plus en longueur (et de façon plus technique) les projets à venir (je mettrai le lien quand la dépêche sera publiée). Le site officiel est bien sûr une autre source d'informations, et vous pouvez nous rejoindre sur le salon XMPP sat@chat.jabberfr.org.
 
Nous travaillons à plein temps sur le projet avec nos propres resources, aussi la question du financement se pose sérieusement. Si vous voulez soutenir un projet qui a de nombreuses possibilités, libre et éthique, c'est le moment ! http://salut-a-toi.org/adhesion.html
 
Vous pourrez nous rencontrer cet été:
  • à Pas Sage En Seine cette semaine: conférence « Libervia : repenser nos communications » jeudi 18 juin de 13h à 14h
  • au RMLL à Beauvais, avec 3 conférences et la présence au village toute la semaine:
    • conférence « Libervia : repenser nos communications » lundi 6 juillet de 14h40 à 15h20 (salle 124) ;
    • table ronde/débat sur les nouveaux médias avec Timothée Jaussoin (Edhelas) de Movim, Pouhiou (Framasoft), Luc Fievet (April), Arno* (SPIP/SeenThis), Souliane et moi pour SàT, le lundi 6 juillet de 16h20 à 18h (amphi Brunuel) ;
    • PubSub, microblogage et XMPP jeudi 9 juillet de 15h00 à 15h20 (salle 203/204).
  • en Allemagne les 22 et 23 août pour la FrOSCon (University of Applied Sciences Bonn-Rhein-Sieg), pas de conférence cette fois, mais un stand.
 

Maintenance le dimanche 26 avril 2015

Comme vous l’avez sûrement remarqué, nos certificats pour les domaines jabber.fr et jabberfr.org sont expirés. La plupart des clients affichent un message d’avertissement à chaque connexion à cause de ça.

De nouveaux certificats ont été générés, et seront mis en place ce dimanche 26 avril 2015 aux environs de 10h du matin, heure française, entraînant une coupure de quelques minutes.

Comme à notre habitude, vous serez informés de l’état de la maintenance par des mises à jour de ce billet. :)

Mise à jour du 26/04/2015 à 11h15 : après quelques péripéties avec le nouveau certificat, la maintenance est terminée !

Maintenance exceptionnelle le dimanche 29 mars 2015

Bonjour à tous !

Suite à une faille présente dans une bibliothèque que Prosody utilise, ce serveur a été redémarré en urgence. Pour plus d’informations sur cette faille, vous pouvez lire les notes de version de Prosody 0.9.8 (en anglais)

mu-conference, notre serveur de conférences, sera redémarré ce mercredi premier avril à 20h (et c’est pas une blague !) afin de corriger quelques problèmes de connexion.

Votre nouvel administrateur, Link Mauve. :)

Mise à jour du 01/04/2015 à 21h45 : mu-conference a été correctement relancé, la connexion à la base de données est rétablie.

Changement dans l’équipe d’administration du serveur JabberFR

Bonjour,

Suite à une décision unanime des administrateurs du serveur JabberFR, une nouvelle personne rejoint l’équipe : il s’agit d’Emmanuel Gil Peyrot (Link Mauve). Certains d’entre vous le connaissent déjà vu qu’il est un membre actif de JabberFR.

J’en profite également pour officialiser le départ de Grégoire Menuel (omega). Merci à toi pour toutes ces années de bonheur. Dif tor heh smusma.

L’équipe d’administration est donc actuellement composée de deux personnes : Link Mauve et moi-même (elghinn).

Maintenance exceptionnelle le dimanche 22 mars 2015

Une maintenance exceptionnelle du serveur de JabberFR, entraînant l’arrêt complet de tous les services, aura lieu dans la journée.

Vu le caractère exceptionnel, pas d’heure de début ni d’heure de fin, et encore moins de programme. Plus d’informations en fin de journée.

Mise à jour de 12h00 : Mise à jour de prosody vers la 0.9.7 et désactivation du mod legacyauth.

Astuce du jour: utiliser Konqueror pour avoir un aperçu temps réel.

Salut à vous,


comme je fais actuellement de l'édition de XEP (extension XMPP), je dois utiliser les outils fournis par la XSF (XMPP Standards Foundation) en console. Moi ça me va, je peux utiliser mon vim habituel, avec syntastic qui me dit quand il y a une erreur, etc. Seulement j'aimerais bien avoir un aperçu en temps réél de ce que j'édite. Pas de soucis, Konqueror vient à la rescousse, car il a le bon goût d'être pilotable via D-Bus.

J'entre la commande magique suivante dans une console:

$ while true; do; inotifywait -e modify xep-proto-namespace-delegation.xml; echo transformation; xalan -in xep-proto-namespace-delegation.xml -xsl xep.xsl  -out xep-proto-namespace-delegation.html -html; echo rafraichissement; qdbus $(qdbus org.kde.konqueror\*) /konqueror/MainWindow_1 reload; done

et maintenant, à chaque enregistrement de mon fichier, Konqeror m'affichera l'aperçu en cours.

Explications:

while true; do;

ça c'est facile, on tourne en boucle jusqu'à ce que je presse C-c pour tout stopper.

inotifywait -e modify xep-proto-namespace-delegation.xml;

Cette commande très pratique permet de réagir à un évenement inotify. inotify est une fonction du noyau Linux qui fournit des notifications en cas d'évenement. Là je demande à la commande de bloquer jusqu'à ce que le fichier xep-proto-namespace-delegation.xml que je suis en train d'éditer soit modifié. En d'autres termes, ça bloque jusqu'à ce que je fasse mon :w dans vim.

echo transformation; xalan -in xep-proto-namespace-delegation.xml -xsl xep.xsl  -out xep-proto-namespace-delegation.html -html;

Là on est dans la partie spécifique à XMPP, j'indique que je veux transformer mon fichier xml en HTML (xalan est un outil qui utilise XSLT pour transformer de l'XML, le xep.xsl étant fourni par la XSF). Le echo étant bien sûr juste pour m'indiquer qu'on fait la transformation.

echo rafraichissement; qdbus $(qdbus org.kde.konqueror\*) /konqueror/MainWindow_1 reload;

Ici on a la partie intéressante. D'abord j'indique avec le echo qu'on va faire un « rafraichir » sur le Konqueror en cours. Le problème c'est que le nom de service de Konqueror n'est pas toujours le même, c'est org.kde.konqueror-[pid du konqueror en cours]. Il serait assez facile de retrouver le pid, mais ici je préfère utiliser une fonctionnalité de qdbus pas forcément connue (qdbus étant très mal documenté), à savoir l'utilisation du métacaractère (wild card) « * » pour chercher tous les noms de services.

Ici donc, $(qdbus org.kde.konqueror\*) nous donne le nom du service voulu (à supposer qu'il n'y a qu'un Konqueror qui tourne). Nous utilisons à nouveau qdbus pour appeler la méthode « reload » de Konquy (il est possible d'utiliser D-Feet pour retrouver facilement le nom et le chemin de la méthode).

Et nous finissons la boucle avec done. Voilà, plus qu'à appuyer sur [entrée] et dégainer votre vim favori.

Bien évidemment, j'applique ici à l'édition de XEP parce que je suis en plein dedans, mais vous pouvez vous en servir pour, par exemple, faire un aperçu Markdown (avec la commande... markdown), ou pour tout ce qui se transforme en (X)HTML.

Salut à Toi disponible en docker + passage à la radio

Salut à vous,

nous venons de mettre en place des images Docker pour simplifier l'installation et l'utilisation de Salut à Toi/Libervia.

Pour ceux qui ne connaissent pas, Docker est un logiciel de gestion de conteneurs, une sorte de chroot boosté. En gros l'idée c'est que vous distribuez un système complet avec toutes les versions des dépendances qui vont bien, et que vous faites tourner le tout de manière isolée mais sur un noyau Linux existant, avec un impact faible sur les performances.

Dans notre cas c'est idéal, car Salut à Toi est pour le moment complexe à installer (surtout Libervia: on y travaille, mais on a besoin de faire bouger les standards XMPP pour ça, et ça prend du temps).

Avec Docker, l'installation est très simple, et en prime nous avons fait un script pour faciliter encore tout ça.

Pour installer et lancer Libervia, il vous suffit d'entrer la commande suivante:

wget http://repos.goffi.org/sat_docs/raw-file/tip/docker/libervia_cont.sh && chmod a+x libervia_cont.sh

Qui va télécharger et rendre exécutable le script de gestion du conteneur Libervia. Ensuite, et si Docker est bien installé chez vous, il vous suffit d'entrer:

./libervia_cont.sh

Le téléchargement la première fois devrait prendre quelques minutes, ensuite le tout est executé avec quelques instructions sur l'utilisation.

Vous pourrez ainsi tester la version en cours de développement de Libervia. pour mettre à jour, il suffit d'entrer:

./libervia_cont.sh update

Vous aurez tous les details ici (en anglais seulement pour le moment, toute aide à la traduction bienvenue): http://wiki.goffi.org/wiki/Docker/en

N'hésitez pas à nous signaler si quelque chose ne fonctionne pas comme prévu ou est mal expliqué (le mieux étant de venir sur le salon XMPP de Salut à Toi: sat@chat.jabberfr.org).

Sinon je n'avais pas donné le lien ici: j'ai été invité il y a quelques semaines par radio « Ici et maintenant », une radio libre parisienne, avec d'autres acteurs du libre comme Benjamin Bayart (FDN, minitel 2.0), Julien et Valérian (Jappix), Éric et Stéphane (Franciliens.net), Thuban (Host@Home), et Tanguy (Planet auto-hébergement). L'émission est longue (3h30), et divisée en 2 parties principales, celle qui cause de SàT est à partir de 2:20. Vous la trouverez ici (ou mieux via bittorrent).

Salut à Toi (à nouveau) à la radio demain (samedi) à 14h

Salut à vous,

un rapide message pour vous annoncer que j'ai été gentiment invité à participer à « Cyberculture », une émission de radio « Ici et maintenant ». Le thème de l'émission sera l'initiation à « l'internet libre » en présentant des outils. Au programme du beau monde:

Donc ce samedi 27, RDV sur 95.2 FM si vous êtes à Paris, ou sur le web: http://icietmaintenant.com (écoute en direct dans le menu).

Pour mémoire j'avais déjà été invité à l'émission Symbiose pour parler de Salut à Toi, émission passé notamment sur divergence FM: http://symbiose.bonnes-ondes.fr/ep/...

Enregistrement SRV pour XMPP sur les DNS de Gandi

Si vous lisez la documentation sur les enregistrements SRV pour XMPP, vous verrez qu’il est indiqué de mettre quelque chose comme ça dans votre zone DNS :

_xmpp-client._tcp.example.net. 86400 IN SRV 5 0 5222 example.net.
_xmpp-server._tcp.example.net. 86400 IN SRV 5 0 5269 example.net.

Manque de bol, ca ne marche pas si votre DNS est chez Gandi. Il faut mettre plutôt ceci :

_xmpp-client._tcp 86400 IN SRV 5 0 5222 example.net.
_xmpp-server._tcp 86400 IN SRV 5 0 5269 example.net.

Vous pouvez vérifier vos enregistrement SRV avec ce site (Attention, la propagation des modifications de votre DNS peut prendre du temps)

J'aime(2)Ferme-la !(0)

Related Posts: