Aujourd'hui nous allons expliquer dans les grandes lignes comment fonctionnent « PubSub » et « PEP », et voir à quoi cela peut servir. Cet article va reprendre en partie ce que j'ai dit à la conférence « PubSub, microblogage et XMPP » en juillet dernier aux RMLL.
PubSub signifie « Publish/Subscribe » (Publication/Abonnement), c'est un mécanisme qui permet à une ou plusieurs personnes de publier toutes sortes d'informations sur un endroit connu (qu'on appelle un nœud) et aux personnes qui le désirent de s'abonner, c'est à dire d'avoir accès au contenu et d'être averti des modifications, le tout avec un système d'accès simple. Il s'agit du patron de conception « observateur/observable » décentralisé et appliqué à XMPP.
Le fonctionnement est expliqué dans la XEP-0060, c'est une des XEPs les plus longues de XMPP mais le principe est relativement simple à comprendre. Sans reprendre le long glossaire du document, expliquons quelques termes :
- le service PubSub est l'entité qui gère le mécanisme de publication, d'autorisation, d'abonnement, de notification. C'est une entité XMPP et un jid y est donc associé, c'est à lui que vous faites toutes les requêtes pour un nœud donné.
- le nœud est un espace associé à une publication. On peut associer ça à l'adresse d'un flux Atom.
- un « item » (élément) est une publication dans un nœud. On peut associer ça à un article dans un flux Atom.
- cet « item » contient un « payload » (charge utile), c'est à dire un contenu significatif qui dépend de la fonctionnalité utilisée. En effet la XEP-0060 décrit un mécanisme générique et souple, qui est ensuite utilisé dans des cas pratiques par d'autres extensions.
Un service PubSub est généralement un composant de votre serveur, mais ça peut-être n'importe quelle entité : votre serveur lui-même (c'est le cas avec PEP que nous allons voir ci-dessous), ou un client voire votre client lui-même (mais c'est assez rare – je n'ai jamais vu de client le faire –, car en général on utilise le service de son serveur).
Le mécanisme général est très simple et centré sur les nœuds : chaque entité (associée à un jid) à un rôle lié à ce nœud selon qu'elle l'ait créé, qu'elle soit publieur, abonné, banni ou sans lien avec le nœud. À ces rôles sont donnés des autorisations : le droit d'écrire (avec le « publish model » ou modèle de publication) et le droit en lecture (avec l'« access model » ou modèle d'accès).
Reprenons de manière un peu plus formelle. Les rôles dont nous avons parlé sont appelés « affiliations », et on peut avoir les suivantes:
- owner (propriétaire): en général celui qui a créé le nœud
- publisher (publieur): celui ou ceux (il peut y en avoir plusieurs) qui ont accès en écriture
- publish-only (publication seulement): droit d'écriture mais pas de lecture, c'est un cas peu fréquent.
- member (membre): quelqu'un qui est abonné au nœud
- none (rien): l'entité n'a pas de lien avec le nœud
- outcast (banni): l'entité a été explicitement interdite d'accès au nœud
La section 4.1 de la XEP-0060 fourni un tableau qui montre les autorisations selon l'affiliation. Ainsi on voit que le propriétaire peut publier ou configurer un nœud.
Les modèles d'accès (pour la lecture) définis dans la XEP-0060 sont les suivants:
- open (ouvert, public): tout le monde peut lire le nœud
- presence (présence – oui je traduis même pour un seul accent –) : si une entité est autorisée à voir la présence du publieur, alors elle peut accéder au nœud
- roster (liste de contacts): si une entité est dans un groupe défini (dans la configuration du nœud) de la liste de contacts du service pubsub, elle a accès au nœud.
- whitelist (liste blanche): des entités sont explicitement autorisées dans la configuration du nœud
Et rapidement les modèles de publication:
- publishers (publieurs): quelqu'un qui a l'affiliation publieur peut écrire
- subscribers (abonnés): n'importe quel abonné peut écrire
- open (ouvert/libre): tout le monde peut écrire
Il faut bien noter une chose essentielle dans PubSub : quand la combinaison autorisation/abonnement/configuration le permet, on reçoit une notification immédiatement quand un élément est publié, modifié ou supprimé. Autrement dit on n'est plus du tout dans l'analogie avec un flux Atom – où on doit aller vérifier régulièrement qu'il n'y a rien de nouveau –, on est prévenu si nécessaire. Ceci est beaucoup plus efficace, rapide, et économe en ressources.
Voilà pour la base. La XEP défini d'autres choses qu'il n'est pas forcément pertinent d'expliquer ici, comme les métadonnées ou les inscriptions temporaires. On peut toutefois s'arrêter sur les collections, qui ne sont que mentionnées dans la XEP-0060 mais décrites en détails dans la XEP-0248. Elles permettent de faire des arbres de nœuds, et ainsi de représenter des données avec des relations entre elles. Des exemples valent parfois mieux qu'un long discours: les collections peuvent être utilisées pour représenter un système de fichiers sur un disque dur, ou un arbre généalogique.
Tout ceci est souple, générique, puissant, et relativement facile à utiliser par un client. Mais la XEP étant très longue, et l'implémentation de la partie service plus complexe, les implémentations ont mis du temps à arriver (et encore aujourd'hui elles sont très inégales). Comme PubSub peut être intéressant même sans tout le mécanisme, une version simplifiée est décrite dans la XEP-0163: « Personal Eventing Protocol » (Protocole d'évènements personels).
Cette dernière se base sur PubSub, mais définit les règles suivantes qui simplifient beaucoup :
1 compte (jid) = 1 service : probablement la règle la plus importante, elle évite d'avoir à chercher un service PubSub associé à un jid, puisque le service est l'adresse canonique (« bare jid ») de l'entité. Ainsi pour la microblogage (XEP-0277), il suffit de connaître le jid de la personne – le nœud étant défini dans la XEP – pour retrouver ses publications.
1 publieur par nœud : le propriétaire et le publieur sont le même, et il n'y a qu'un publieur par nœud. On se coupe ainsi de l'édition collaborative par souci de simplification, et il faudra utiliser PubSub pour ce genre d'applications.
accès par présence par défaut : sans rien toucher, il suffit d'avoir quelqu'un dans sa liste de contacts (et qui a accès à la présence) pour qu'il soit autorisé à voir nos publications
notifications filtrées sur l'intérêt exprimé : pour éviter d'être submergé de notifications, une entité/un client doit explicitement indiquer qu'il est intéressé par tel ou tel nœud
options par défaut au plus simple
PEP était utilisé au début pour des événements (sans grand intérêt à mon sens) comme l'humeur ou la musique en cours d'écoute, mais depuis son utilisation a évolué.
Voici, pour finir, quelques exemples d'utilisation de PubSub ou PEP:
- enregistrement de données publiques ou semi-publiques (XEP-0222), par exemple une clef publique de chiffrement
- enregistrement de données privées (XEP-0223), très utile pour n'importe quelle donnée de petite taille
- les marque-pages (XEP-0048) utilisés pour les salons de discussions utilisent PEP (la XEP-0048 a été modifiée après l'apparition de PEP pour s'y adapter)
- le microblogage bien entendu (XEP-0277), qui utilise PEP et utilise du Atom pour sa « charge utile » (« payload ») et un accès en général public. Les commentaires sont sur un nœud PubSub séparé, en général avec un modèle de publication par abonnement.
- la XEP-0214 utilise PubSub et les collections pour faire un dépôt de fichiers
- le futur protocole de discussions de groupe « MUC 2 » devrait se baser sur PubSub
PubSub pourrait aussi être utilisé pour placer des points sur une carte, faire un wiki, organiser des événements, ou encore gérer et surveiller une batterie de serveurs qui nous préviendraient en cas de problème.
Je reviendrai sûrement plus tard sur tout ça pour expliquer le microblogage ou d'autres extensions.
La prochaine fois, je pense vous parler de Jingle (mais pas de la partie vidéo-conférence). J'espère qu'à ce stade vous commencez à comprendre que XMPP n'est pas une technologie, mais un ensemble de technologies coordonnées et qui se réutilisent les unes les autres quand nécessaire.
J'ai un peu réduit le rythme des articles ces derniers temps car je travaille sur mon projet, et qu'une partie a été traduite en anglais avec l'aide de pas mal de monde (merci encore !), tout cela prend du temps.
Si vous venez à la fête de l'huma ce week-end, vous pourrez me trouver au village du libre, où Parinux me prête gentiment un bout de stand (merci aussi !). Je n'y serai pas en permanence, car je compte aussi profiter un peu de la fête :)
# Movim
Posté par Yuul B. Alwright . Évalué à 2.
Comment fonctionne le lecteur de news de Movim?
J'imagine que pour la souscription c'est du PubSub, mais pour la mise à jour des nœuds?
PS: Un grand merci pour tes articles sur XMPP. Ils sont excellent.
[^] # Re: Movim
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Si Edhelas passe par là il te répondra plus précisément, mais je suppose que ça récupère le flux Atom régulièrement, que ça adapte le contenu à ce que demande la XEP-0277 et que ça re-publie le contenu derrière, avec une notification s'il y a du nouveau.
En plus de permettre d'avoir tes flux Atom dans ton client XMPP, cette méthode permet d'être notifié régulièrement et allège la charge sur le serveur: si 1000 personnes suivent un flux, au lieu d'avoir 1000 requêtes toutes les 5 à 30 min, tu as un seul service qui fait les requêtes toutes les - disons - 5 min, et qui qui notifiera les 1000 clients XMPP s'il y a du nouveau, et uniquement s'il y a du nouveau.
Pour le client XMPP c'est transparent, il s'abonne à un nœud normalement (enfin je n'ai pas utilisé la passerelle de Movim, mais je suppose que c'est comme ça).
[^] # Re: Movim
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Que se passe-t-il en cas d'échec à notifier quelqu'un ? Il n'est pas notifié ? Il est notifié plus tard ? (pour comparer avec Atom où si tu rates une lecture/analyse du flux, tu te rattrapes à la prochaine, avec éventuellement une perte d'info si le flux défile très vite).
[^] # Re: Movim
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Les notifications sont envoyées avec des <message/>, de type j'envoie et j'oublie, donc tu ne sais pas si la notification a échoué (enfin un serveur peut te retourner une erreur, mais ça n'est pas obligatoire, contrairement à <iq/> ou tu dois avoir une réponse, cf l'épisode 2). Donc sur le coup tu ne t'en rendras pas compte (en pratique si un message échoue, c'est très probablement que ta connexion a échoué, et donc tu vas t'en rendre compte tôt ou tard).
Par contre quand tu récupères les nouveaux items à la connexion suivante, tu rattrapes l'info perdue. Dans une implémentation PubSub basique, tu ne peux que tout récupérer, ou les X derniers items. Dans ce cas il faudra comparer ton dernier id pour voir si tu n'a rien raté, c'est pas super. Par contre tu as des extensions comme « PubSub Since » (XEP-0312) ou Message Archive Management (XEP-0313) qui permettent de récupérer les items depuis ta dernière déconnexion, c'est plus efficace.
[^] # Redodance
Posté par Alex G. . Évalué à 2.
Une autre question sur la lancée de ta réponse : est que dans XMPP les autres nœuds stockent des infos d'un autre nœud (redondance). Je veux dire est-ce que si ton serveur XMPP est down, j'ai des chances de pouvoir récupérer le dernier contenu d'un autre serveur (et dans quelles conditions) ?
C'est une question qui me taraude un peu car quand on parle de distribué et qu'on l'associe à utilisateurs final, la redondance me semble un gros plus, qui permet de moins dépendre d'un serveur (je pense à SàT notamment).
[^] # Re: Redodance
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Salut,
je vois à peine ton message (je rentre tout juste de la fête de l'huma). Alors de base il n'y a pas de redondance (c'est ton service pubsub qui gère les sauvegardes), mais rien n'empêche d'en faire une, il suffit qu'un autre service pubsub s'abonne à un nœud (et qu'ils soit autorisé à le lire) pour qu'il soit synchronisé. Après ce qu'il serait bien, c'est d'avoir une liste de nœuds à voir en cas de problème sur le principal, une XEP pourrait se charger de ça.
De toute façon c'est une question qu'il faudra aborder un jour où l'autre: si tu as un boîtier à la maison (comme celui qu'on veut faire), il serait sage d'avoir une sauvegarde extérieur en cas de vol, perte, ou problème sérieux.
[^] # Re: Redodance
Posté par Alex G. . Évalué à 1. Dernière modification le 14 novembre 2015 à 11:28.
-- effacé --
[^] # Re: Movim
Posté par edhelas (site web personnel) . Évalué à 2.
C'est exactement ça ;)
Sachant que sur Movim il y a aussi la possibilité de faire le truc dans les deux sens, de générer une page HTML simple + son flux Atom à partir d'un flux Pubsub (petit exemple https://nl.movim.eu/?q=grouppublic&s=blabla.movim.eu&n=random).
# MUC 2
Posté par Yuul B. Alwright . Évalué à 2.
Que sait-on déjà au sujet de MUC 2? Qu'apportera-t-il?
[^] # Re: MUC 2
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Je n'ai pas encore vu passer de protoXEP (nom d'une XEP avant sa publication par la XSF) sur le sujet, mais il y a eu plusieurs discussions à le sujet, notamment au dernier XMPP summit.
L'idée c'est d'avoir système compatible avec l'actuel, mais de corriger ses quelques défauts, notamment:
pouvoir se connecter avec un même pseudo depuis un même jid avec sur plusieurs clients/appareils. C'est le plus gros point à corriger
j'ai cru comprendre qu'il était question de passer les présences à la trappe: elles génèrent un gros trafic, et des extensions comme les états de discussions (chat states, XEP-0085) permettent de savoir si quelqu'un prête attention ou pas à la conversation. Pour ma part je ne suis pas 100% convaincu par ça, pouvoir dire explicitement qu'on est occupé est intéressant à mon avis.
il a été question sur la liste standard@ de supprimer les salons anonymes et semi anonymes (voir l'épisode 4 pour des explications). L'argument est qu'on peut désormais utiliser une connexion temporaire si on veut être anonyme (pas au sens Tor mais au sens on ne dévoile pas son jid), et que connaître le jid permet de s'assurer qu'on parle à la même personne d'une fois sur l'autre.
permettre de faire une couche de compatibilité est un point essentiel.
Et sinon je viens de me souvenir que j'avais déjà répondu à cette question, tu peux lire ce commentaire.
# XMPP ou Jabber
Posté par Yuul B. Alwright . Évalué à 2. Dernière modification le 08 septembre 2015 à 17:24.
Finallement, on doit dire XMPP ou Jabber quand on parle du réseau fédéré?
(￣ω￣) ?
[^] # Re: XMPP ou Jabber
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Il y a guerre des religions sur le sujet, certains disent que Jabber c'est le réseau fédéré et XMPP le protocole.
A priori le nom « jabber » appartient désormais à une société privée, et il n'est pas libre de l'utiliser, aussi il faut parler d'XMPP. Les logiciels qui utilisaient jabber avant peuvent le garder pour des raisons historiques (cas de ejabberd par exemple), mais les nouveaux ne doivent pas. J'ai vu quelqu'un se faire refuser l'ajout de son logiciel sur la liste officielle parce qu'il y avait « jabber » dedans (de mémoire il a été ajouté après renommage).
Donc voilà, pour ma part je ne parle que de XMPP, sauf à l'oral si je vois que la personne ne connaît pas, parfois Jabber parle plus.
[^] # Re: XMPP ou Jabber
Posté par Yuul B. Alwright . Évalué à 2.
Si le nom Jabber n'est plus utilisable, ne devrait-on pas en trouver un autre plutot que de ré-utiliser XMPP? Un nom simple, court, explicite et bien vendeur?
XMPP, c'est un bon nom pour un protocole, mais pour un service c'est moyen. Ça peut aussi apporter de la confusion si d'autres services (e-mail, IoT, etc) se mettent à utiliser XMPP.
Ce serait l'occasion de définir une série de XEP à supporter et de versionner tout ça.
Par exemple:
- E-Talk 1: Fédéré, basé sur les RFC de XMPP ainsi que quelques XEP (MUC, Jingle, PEP, etc)
- E-Talk 2: E-Talk 1 + PubSub et MAM
- Etc
[^] # Re: XMPP ou Jabber
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
C'est un vieux débat sans vraiment de réponse. Je ne pense pas que c'est le nom qui va donner plus de succès à XMPP (le succès est déjà là depuis longtemps), mais plutôt des clients, et mon petit doigt me dit que c'est en bonne voie de ce côté ;)
XMPP intéresse surtout les développeurs, on peut le comparer à HTTP sur ce plan (c'est pas joli non plus HTTP, mais ça ne choque personne). Le seul intérêt que je vois, c'est pour dire que c'est compatible. C'est vrai que ça me gêne qu'on parle de réseau « Movim », « Jappix » ou « Libervia » quand c'est le même protocole derrière et que c'est compatible. Là le logo peut aider. Et puis après tout y'a tout un tas de noms imbitables qui passent très bien dans le grand public comme « USB », « VGA » ou « DVD ».
Et sinon il y a déjà une XEP qui commence à dater et qui indique les extensions à supporter pour un client moderne (la XEP-0312), il est question d'en refaire une à jour avec les différents type d'utilisation principaux (discussion, vidéo, transfert de fichier, etc).
[^] # Re: XMPP ou Jabber
Posté par Jehan (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 08 septembre 2015 à 19:06.
Oui je pense que c'est surtout cela. Et ce n'est pas petit selon moi. C'est comme dire qu'on envoie un "email" à quelqu'un. Tout le monde (ou presque, même ça se perd) comprend et n'a pas besoin de demander quel logiciel utiliser (ni ne se demande tout court si les fournisseurs vont pouvoir communiquer, que ce soit Google, Yahoo, votre FAI…).
De même quand on parle de page web, les gens savent y aller, même pourtant sans comprendre ce qu'est un navigateur web, en confondant internet, leur navigateur et Google comme une seule et même chose, et sans même comprendre ce qu'est une adresse web (ils vont taper dans le moteur de recherche, ou cliquer sur un lien car ils ont formés la relation "texte bleu" = "page web" dans leur esprit).
Par contre en messagerie ou assimilé, les gens en sont encore à se poser des questions: je t'envoie un message = sur Facebook? Twitter? Sur Kakao Talk? Sur Gmail (car on ne parle plus de GTalk d'ailleurs, le concept de messagerie instantané est enfoui dans l'UI du webmail et les concepts mélangés; à la limite, certains diront "hangout" pour parler d'une discussion vidéo, ce qui n'est d'ailleurs plus du XMPP, si je ne m'abuse)?
Il n'y a pas de mot pour te dire que je t'envoie un message sur ton adresse XMPP. Et c'est assez gênant car ça enferme les gens dans les divers silos propriétaires, où même lorsque ces services utilisent en fait XMPP, sont fédérés et donc compatibles, la plupart des gens ne s'en rendent pas compte (et donc s'auto-enferme). Par exemple je suis sûr que presque personne sur gmail ne tentera d'inscrire mon adresse XMPP (non @gmail.com) dans ses contacts d'IM car cela leur paraîtra évidemment impossible.
Je pense que les termes qui marchent sont souvent un skeuomorphisme avec un petit plus pour le rendre "high tech". Par exemple dans mes deux exemples: le mail (courrier postal), avec un 'e' ajouté; ou une page (comme une page blanche physique) avec le terme hype "web". C'est la raison pour laquelle pendant des années, quand j'espérais pouvoir aider à populariser XMPP, je parlais juste d'IM pour (Instant Messaging) messagerie instantanée, un terme générique qui était déjà populaire et compris par beaucoup en espérant que l'association puisse se faire IM = XMPP, sans même que les gens ne s'en rende compte.
Ça n'a jamais pris, notamment parce j'étais le seul à essayer de faire cette association (forcément, ça ira pas loin!), tous les autres promoteurs parlant soit de XMPP (un terme barbare et technique), soit de Jabber (qui n'est pas un mot générique, ni n'en est dérivé, et avait donc peu de chance de se faire reprendre dans le langage courant, car il ne se fait pas remarquer par rapport aux marques déposées par les grosses sociétés pour des messageries proprios).
Enfin, je sais que tu me diras que XMPP fait bien plus que "juste" de la messagerie instantanée (on en a discuté aux RMLLs, je me souviens!), et je pense que ça n'importe pas. Les "pages" web sont de nos jours bien plus que des pages blanches (concept très statique). Elles sont dorénavant dynamiques, voire même sont devenues de véritables applications (au point que les technologies derrière sont désormais utilisées pour du desktop, ou en langage principal sur certains OS mobiles, etc.). Pourtant on parle toujours de "page", comme si c'était statique. L'analogie ne tient plus, mais ça ne choque personne, et ce terme générique a toutefois permis d'unir tout le monde sur un seul "web" sans même qu'ils s'en rendent compte, alors que pas mal de sociétés ont essayés à l'époque de créer leur propre web proprio et fermé, avec leurs propres technologies. Les sociétés ont perdus sur le web. À l'heure actuelle, ils sont en train de gagner dans l'IM (et cela crée un morcellement des réseaux).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Commentaire supprimé
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 08 septembre 2015 à 21:14.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: XMPP ou Jabber
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
arf, désolé pour les fautes, je faisais autre chose en même temps, et c'est trop tard pour modifier. version corrigée:
Il y a un mot, probablement le plus important à connaître, qui passe bien c'est « jid ». Il porte un peu à confusion parce qu'il y a encore « jabber » dedans (et ça ne changera pas). Je dis que j'utilise « XMPP », mais uniquement quand je fais des confs techniques, que je suis aux RMLL ou à PSES, sinon j'évite de plus en plus d'utiliser ce terme technique.
plutôt que dire « c'est quoi ton adresse courriel ? » on peut/pourra dire « c'est quoi ton jid ? ». On pourra même appeler ça courriel dans le futur, peu importe que ça ne soit plus du SMTP en dessous.
Mais je suis globalement d'accord avec ce que tu dis.
On avait discuté avec Nyco et Edhelas de l'utilisation du logo XMPP comme symbole de compatibilité (voire de pouvoir cliquer dessus et de voir une liste de projets compatibles, un peu comme les « ring » internet des années 90).
[^] # Re: XMPP ou Jabber
Posté par rakoo (site web personnel) . Évalué à 2.
Il faut croire que Cisco a le droit alors, parce que leur produit de messagerie instantanée s'appelle tout simplement Jabber
(C'est une vraie daube, soit dit en passant. J'ai peur que les gens associent Jabber (le protocole) à un truc tout naze)
[^] # Re: XMPP ou Jabber
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Ah ben oui ils ont le droit, c'est eux la société privée en question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.