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.

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

(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…

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/

Oups, désolé j'étais passé à côté de ce commentaire...

Alors il y a déjà une implémentation (faite par nous) pour Prosody, et je suppose qu'elle doit marcher pour Metronome aussi vu que c'est un fork.

Nous sommes en contacts avec un des dévs principaux de Ejabberd qui s'est montré intéressé aussi, et au dernier XMPP summit l'équipe de MongooseIM (fork de Ejabberd) était également intéressée, donc tout ça est encourageant.

Maintenant ce qui change vraiment, c'est que d'une part ces 2 XEPs sont beaucoup plus faciles à implémenter qu'un serveur pubsub complet, et d'autre part une fois implémentée, nous ne serons plus bloqués pour les évolutions futures: si une nouvelle XEP sort, nous pourrons l'implémenter nous-même pour tout le monde d'un coup et en profiter directement. Donc la situation n'est pas du tout la même qu'avec PEP.


author website

Salut Goffi,

Une petite question concernant cette conférence que je viens de visionner: les XEP 0355 et 0356 ont-ils une chance d'être implémentés assez rapidement par des serveurs? Est-ce que vous avez des contacts avec des devs des serveurs principaux dans ce sens?

Sinon, on risque de se retrouver dans la même situation que pour PEP, non?

(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).

(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.

Ah je ne connaissais pas, bien.

Note que tu peux utiliser un « contenu étendu » dans ton message, c'est à dire un message qui transporte autre chose qu'un texte à afficher (cf https://tools.ietf.org/html/rfc6120... pour les détails). Comme ça tu peux en envoyer plus souvent, et les autres clients ignoreront le namespace qu'ils ne connaissent pas.

Une autre option est d'utiliser PEP: ton serveur est un client XMPP avec PEP, et il transmet les infos sur son état de cette façon.

Tu n'es pas le premier à me parler de monitoring serveur, je me demande si ça ne vaudrait pas le coup d'ajouter des commandes spécialisées pour ça dans SàT et jp...


author website

Merci pour les pistes :)
De mon côté cet après midi je suis tombé sur Jimbo : http://www.darkcoding.net/software/...

La mise en place est facile mais reste à configurer les infos remontées, et surtout éviter d'envoyer un nouveau msg toutes les 5min et privilégier à la place une mise jour du status (plus discret à mon goût)

En Python il y SleekXMPP et Twisted/Wokkel (qu'on utilise avec SàT) qui sont actifs, ça peut valoir le coup de réécrire.

Mais sinon le monitoring, il peut être plus simple/rapide d'utiliser un client en ligne de commande, ou un bot déjà existant. Nous avons un client en ligne de commande pour ça par exemple (jp), et on l'utilise sur notre salon pour voir les commits mercurial en temps réél. Pour envoyer un message il suffit de faire « echo ton_message | jp message ton_jid@domaine.tld ».


author website

Oui je me doute...
C'était un script en python que j'avais récupéré sur un blog.
Je l'ai utilisé des années, et j'ai tjrs été surpris que XMPP ne soit pas plus démocratisé à ce niveau (monitoring).

Un jour, je m'y repencherai sans doute :)

Hedy: quelle bibliothèque utilisais-tu ? Quel langage ? Tu devrais demander conseil soit chez Debian, soit sur jdev (salon anglophone des développeurs XMPP, il y a aussi une liste de diffusion, tu as tous les liens sur https://xmpp.org/participate/discus...). Il y a probablement des salons francophones qui peuvent t'aider aussi, selon le langage utilisé.


author website

Merci pour cette série de billets des plus intéressante :)
J'ai autrefois utilisé XMPP pour monitorer certaines infos de mes serveurs depuis mon roaster : load average, espace disque restant...
Malheureusement depuis Wheezy, mon bout de script a cessé de fonctionner pour une raison obscure et je n'ai pas réussi à remettre le nez dedans.
C'était à la fois léger et efficace :)

(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.

Ça commence à être bigrement intéressant.

Est-ce qu'on peut avoir un exemple de XEP qui est une blague? Je suis curieux de l'humour des XMPPistes.

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.
 

Charpy: oui, c'est dans les extensions qu'il y a tout ce qui est autre que la messagerie (et désolé ton commentaire n'apparaît que maintenant, je ne l'avais pas vu il était passé en spam, même chose pour Sangfroid)


author website

Pour suivre mon commetaire fait au premier article, je constate que finalement c'est surtout une "simple" messagerie, avec gestion de la dispo des personnes. Donc pour l'instant peu d'ajout par rapport à IRC, qui doit êtr une bonne dizaine d'année plus ancien, mais j'attend de voir ce que réservent les extensions!

Bonne continuation pour cette série!

Merci pour ces articles, c'est tout à fait compréhensible, tout en restant un peu technique. Nickel, hâte d'avoir la suite.
XMPP, c'est la vie


author website

okso: c'est souvent dans l'autre sens qu'il faut se poser la question, la pertinence de développer quelque chose en partant d'une feuille blanche, alors qu'il y a déjà un standard libre et éprouvé en place. Enfin je ne suis pas contre l'expérimentation non plus.

Stephanou: Tu peux déjà regardé ce vieux billet que j'avais écrit: http://www.goffi.org/post/2011/01/1...


author website

Comme le premier article, celui est très clair et accessible sans problème au novice.

J'espère que la question du message dit "normal" sera développée. Si vraiment XMPP offre aussi une fonction de type email, c'est vraiment excitant !

Chouette article ! J'ai hâte de lire la suite car je m'interroge sur la pertinence de XMPP face à tous les nouveaux "protocoles sociaux".

Un des gros intérêts de passer sur XMPP, c'est qu'après on peut utiliser des logiciels différents avec le même compte. Movim, Gajim ou Libervia vont fonctionner tous les 3 sans créer un nouveau compte derrière.

Donc c'est peut-être un nouveau compte à régler, mais beaucoup plus universel que la plupart des réseaux existant.


author website

Je suis d'accord avec Ginko. XMPP ca a l'air bien mais ca va etre dur de convaincre tout le monde de changer encore une fois de messagerie.

Ok pour moi. Très intéressant et très clair. Merci !

Impatient d'avoir la suite. A la limite ce qu'il me faudrait en plus c'est un article sur comment convaincre ses contacts (en particulier les moins "techniques") d'utiliser XMPP ah ah.

Cette partie est peut-être un poil trop technique, c'est difficile de placer le curseur. Je m'adresse à un publi averti, donc j'essaye d'expliquer comme ça se passe en dessous mais ça n'est pas obligatoire, n'hésitez pas à me dire ce qui est trop difficile pour que j'adapte les prochains articles. Par exemple parler de RFC et de <IQ/>  n'est vraiment pas indispensable.


author website
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 !

Charpy: je vais faire un article sur les discussions de groupe (à la IRC) pour expliquer les différence, je pense l'épisode 4 ou 5.

Pour les captures, tu peux chercher des images sur les noms de clients que j'ai cité, ou regarder le notre: http://salut-a-toi.org/screenshots....


author website

Pareil, très intéressé! Parce que je n'ai jamais capté exactement ce qui est possible de faire avec.

Je maitrise bien IRC, par contre. Que peut-on faire en plus / en moins avec XMPP ?

On pourrait avoir une capture d'écran pour voir de quoi ca a l'air?

Oui, j'en demande beaucoup :x

Très intéressant !
J'ai hâte de lire la suite.

raleur: (j'en suis un aussi t'inquiuètes ;)) au pire tu as le flux RSS, ou j'ai mis une version sur DLFP ==> http://linuxfr.org/users/goffi/jour... Je pourrais changer le thème de dotclear, mais là je vais bientôt passer mon blog sur Libervia, donc ça vaut pas le coup de passer du temps dessus.


author website

J'ai toujours voulu en savoir un peu plus sur XMPP sans jamais prendre le temps de lire (trop de chose a faire)

Je vais suivre cette serie en esperant comprendre de quoi il s'agit. Merci d'avance

Très bon article de présentation, c'est juste dommage de devoir lire ça sur un bloc de 474px de large ...
(je sais que c'est pas la faute de l'auteur, mais Dotclear ...)

Oui sur les premières parties j'explique les bases, ceux qui connaissent ne vont pas apprendre grand chose. N'hésitez pas à demander si y'a des sujets en particulier qui vous intéressent.

Stephanou: je pense que XMPP a tout ce qu'il faut pour remplacer l'e-mail, j'avais d'ailleurs écrit un billet à ce sujet il y a longtemps: http://www.goffi.org/post/2011/01/1...


author website

C'est très interessant, à titre personnel j'ai commencé à m'interesser à Jabber il y a peu en faisant des recherches sur d'éventuels subsituts à l'email.

Ce sujet m'intéresse énormément, mais j'ai jamais eu l'occasion de développer avec. J'espère que la suite gagnera en profondeur.
Belle initiative.


author website

Intéressant comme série. Surtout sachant que ça vient de quelqu'un qui maîtrise le sujet sur le bout des doigts.
Je n'ai pas appris grand-chose cette fois-ci, mais j'attends impatiemment la suite...

C'est pas que j'aime les téléphones, mais j'ai un petit côté curieux et mon dernier téléphone premier prix a lâché dans des circonstances pour le moins mystérieuses (et pile 2 mois après la fin de la garantie). Manque de bol, ça tombe à un moment où je n'ai pas de ligne fixe ni Internet, et où j'ai besoin d'être joignable.

C'est pas que j'aime acheter des trucs un peu gadgets, mais on parle de Firefox OS en ce moment. Vu qu'il y a un téléphone à vraiment pas cher, et que j'envisage de porter « Salut à Toi » sur cette plate-forme, c'est l'occasion.

Premier essai: une boîte qui fait parler d'elle pour sa campagne de pub sexiste actuellement (j'ai commandé avant ladite campagne). Tout se passe normalement, confirmation, j'attends un peu. Et je reçois un gentil courriel qui me traite de pirate (potentiel), et me demande tenez-vous bien: une photocopie recto-verso de ma carte d'identité et un justificatif de domicile, rien que ça ! Y'a des gens qui acceptent ça sérieusement ? En tout cas j'ai gentiment annulé ma commande et été voir ailleurs, en laissant un message pour l'occasion.

Deuxième essai plus concluant, j'ai tout de même perdu une semaine au passage, à un moment où j'avais besoin d'être joignable...

Le gadget arrivé, je peux tester. Pas trop de commentaires sur le téléphone, ce sont tous des clones aujourd'hui de toute façon.

Ça démarre, le petit renard/panda avec sa queue en feu est joli, ça donne une impression de fini, c'est sympatoche. On me demande si je veux être géolocalisé: bon on me demande c'est déjà ça, mais pourquoi ? Je réponds bien évidemment non. Plus tard la page d'accueil me le redemandera, je ne sais pas pourquoi, mais je sais que ça ne me plait pas du tout. Petit message sur les logiciels libres et l'esprit d'ouverture, j'aime bien.

Après ça ressemble à du très classique: des boutons, des applications. J'ai le regret de voir des saletés comme fb et twitter pré-installées, je suppose que ça vient du constructeur et je supprime. Le système de recherche est pas mal.

Je vérifie la version, c'est Firefox OS 1.3. Je regarde rapidement le « firefox marketplace », là encore du très classique. Je regrette beaucoup l'absence d'indication « logiciel libre »: ça m'aiderait à choisir beaucoup plus sereinement ce que je peux installer. C'est d'autant plus malheureux que Mozilla en fait son cheval de bataille. F-droid devrait être pris en exemple ici, non seulement tout est libre dessus, mais en plus on a des liens vers le code source, et les « anti-fonctionnalités » (espionnage, publicité, etc) sont indiquées clairement.

Aussi j'ai l'impression que beaucoup « d'applications » sont en fait des sites webs déguisés, et là ça me ferait une belle jambe d'avoir du libre. J'espère que Firefox OS ça ne veut pas dire tout avoir sur des serveurs distants: je veux des vrais logiciels sur mon téléphone, qui marchent hors ligne.

Je cherche une application de navigation GPS, qui gère au possible le hors ligne, Evernav me semble la plus adaptée. C'est une application très basique de navigation, qui se proclame la seule sur Firefox OS qui fait de la navigation avec indication des tournants. Il est marqué « fonctionne sans connexion », bien je cherche justement de la navigation hors ligne. La description n'est pas traduite, et l'application n'est pas disponible en français... moi ça ne me gêne pas, mais je pense que ça ne doit pas être le cas de tout le monde.

En pratique, l'application est quasi inutilisable: la « navigation hors ligne » est en fait un cache et je ne vois pas trop comment on peut lui indiquer quelles cartes on veut précisément. Je n'ai pas pu trouver ce que je cherchais, pas gégé. En plus la création d'un compte est obligatoire pour utiliser le guidage  (!), j'en ai fait un vite fait en utilisant une adresse jetable, mais le principe m'énerve. L'application est propriétaire et payante. Bref, je n'aime pas du tout et supprime.

L'application installée de base, « Here » de Nokia arrive à trouver ce que je cherche, et le chemin est calculé facilement. Mais il n'y a pas de guidage, et là encore c'est du proprio. Au moins la création de compte n'est pas obligatoire.

Un des intérêts principaux d'un ordiphone pour moi, c'est d'avoir une application de guidage qui fonctionne hors ligne, et qui ne m'espionne pas. OsmAnd~ (la version compilée par F-droid) est parfaite de ce point de vue, j'espère la voir portée sur Firefox OS (ce qui devrait être possible avec emscripten, l'application étant en C++, mais ça va sûrement demander beaucoup de travail). L'absence d'un équivalent est un frein majeur pour utiliser Firefox OS de mon point de vue.

En dehors de ça, l'absence de copier/coller ne me gêne pas, l'absence d'écriture par les gestes un peu plus mais ça n'est pas indispensable. Par contre l'absence de bouton « retour » qui oblige a chercher dans l'application l'équivalent me gêne *énormément*, je ne comprends pas cette décision de Mozilla. C'est peu intuitif, pas pratique du tout, voire carrément insupportable.

Au niveau téléphonie ça marche comme on l'attend, rien à dire. Ah si je n'ai pas réussi à avoir les détails d'un message (heure de réception), je n'ai trouvé que l'heure du début de la conversation, ce qui est assez gênant pour un message du type « on se retrouve dans 20 min ».

À noter aussi des redémarrages intempestifs, problème de jeunesse qu'on pouvait prévoir, mais dommageable sur une version stable en production. Enfin je suis dév, je sais ce que c'est.

J'ai voulu faire une mise à jour pour voir si ça corrigeait ça, rien d'officiel sur le site du constructeur (ma 1.3 semble la plus récente), je cherche donc sur le net et tombe sur un billet de développeur qui m'indique comment faire. Aïe, il faut windows et je n'en ai pas... La faute au constructeur encore une fois, mais c'est plus que malheureux. Tant pis je tente le coup en téléchargeant quand même et en tentant de flasher moi même. M'intéressant assez peu aux téléphones, je n'ai pas encore l'habitude des archi Android (Firefox OS utilisant la même base), mais je trouve rapidement de quoi faire: fastboot est disponible dans ma Debian, et m'évite l'installation du SDK Android à la main. Dans l'archive pour rooter le téléphone, je trouve des images notamment pour les partitions recovery, boot et system. Les deux premières se flashent sans soucis, mais pas moyen d'envoyer la 3ème, probablement à cause de sa taille. Résultat, je n'ai plus de partition système, et mon téléphone ne boot bien évidemment plus (ma faute, pas celle de Mozilla ou du constructeur :)).

Ne voyant pas de solution simple pour rattraper le coup avec Firefox OS, je décide de temporairement passer à CyanogenMod, à l'aide de cette version, je l'installe sans les google apps.

Au final, je me retrouve avec tout ce que je veux: F-Droid, OsmAnd~, j'ai pu récupérer mes contacts grâce à SlightBackup, et je n'ai pas de compte google lié au téléphone. Le port marche très bien et c'est fluide, et en plus les application Firefox OS peuvent marcher via Firefox dispo sur F-Droid. Je ne vois pas pour le moment ce que Firefox OS m'apporte de plus au niveau vie privée. Aussi, il ne faut pas oublier que l'utilisation d'un téléphone portable est déjà une grave atteinte à la vie privée, et que l'opérateur sait à tout moment où on se trouve avec ces saletés :(.

Enfin bref, je salue tout de même l'arrivée de Mozilla qui reste une boîte en qui j'ai à peu près confiance, et l'effort des équipes de dév, je pense juste que c'est encore jeune. Je reviendrai sûrement rapidement à Firefos OS, ne serait-ce que pour porter « Salut à Toi ».

Ce que j'aimerais:

  • une indication « logiciel libre » dans le gestionnaire d'applications (enfin « marketplace » pour son terme commercial)
  • une vraie application libre de navigation hors ligne, un port de OsmAnd~ serait idéal
  • la possibilité de coder en python. Pour le moment je vois 2 solutions: un transpileur à la Pyjamas, ou le port de Python (déjà fait) via emscripten, reste à voir si on peut accéder à tout le nécessaire pour une véritable application, et ce que donnent les performances. Un port de Kivy serait idéal.
  • un bouton « retour » !!!
  • moins important, mais agréable: la possibilité d'écrire avec des gestes

et bien sûr, je suis très gêné par l'accord entre Mozilla et Foxconn, même si j'ai conscience que mon téléphone premier prix vient de là et qu'il n'a pas dû être fait dans des conditions de travail exemplaires. J'ai un peu honte de financer ça en l'achetant :(. La solution idéale serait de jeter ces fichus téléphones aux chiottes, mais c'est une autre histoire.

Ceci dit, je pense que Mozilla est assez proche d'arriver à quelque chose de pas trop mal, et je souhaite bon courage aux équipes qui bossent dessus. Je vais suivre de plus ou moins loin l'évolution, et tenter de développer dessus sous peu j'espère.

Merci pour ce retour complet et instructif !


author website