index.md 24KB
title: Sortir le Web des silos
url: https://clochix.net/marges/170417-silos
hash_url: f7f3a2d06a
Avec le récent succès de Mastodon, je trouve utile de ressortir un billet écrit en 2010 décrivant les technologies utilisées par Status.net, son lointain ancêtre. Cet article avait alors été publié sur mon carnet Web, qui n'est plus accessible (il est hébergé par Gandi en http, alors que j'utilise désormais HSTS pour exiger https sur l'ensemble des sous-domaines de clochix.net. Il faudrait que j'exporte une version statique de ce carnet et l'héberge ici même… dès que j'aurais 5 minutes.)
Citation(s) extraite(s) de « sortir le Web des silos » par Clochix
Sortir le Web des silos
Alors que de nombreux auteurs de carnets s'étaient assuré du contrôle de leurs données en installant les logiciels nécessaires sur leur propre serveur, l'avènement du micro-blogging et la mode des flux de statuts a ramené tout le monde, geeks y compris, vers des silos : Facebook et Twitter, ou identi.ca pour les intégristes. La sortie de StatusNet 0.9 il y a quelques semaines pourrait bien changer la donne, grâce à son introduction de OStatus, un protocole ouvert et décentralisé permettant d'interagir avec les statuts d'utilisateurs postés sur des serveurs dans le monde entier. Désormais, héberger des pensées, liens et autres bribes sur son propre serveur, tout en continuant la conversation avec les utilisateurs hébergés sur d'autres serveurs, devient possible. OStatus permet de sortir des silos en autorisant une architecture décentralisée qui n'a plus grand chose à envier aux architectures centralisées actuelles.
Cerise sur le gâteau, mais qui pour moi n'a pas de prix: StatusNet 0.9 a levé la limitation à 140c qui, depuis que Twitter a arrêté l'envoi des tweets par SMS dans nos contrées, n'a vraiment plus de raison d'être.
Pour citer Evan Prodromou, OStatus est bâti au dessus d'une pile de composants, formats d'échanges et protocoles de communication :
- Atom pour les flux;
- ActivityStreams pour décrire les activités sociales;
- PubSubHubbub (PuSH pour les intimes) pour les notifications en temps réel;
- Salmon pour la conversation;
- WebFinger pour décrire les services disponibles : les flux et les points d'entrée de PuSH et de Salmon;
Toutes les communications entre les serveurs utilisent HTTP, dans le cadre d'une "architecture orientée service", c'est à dire que l'on communique simplement avec des services en appelant l'URL de leur point d'entrée.
Tentative de présentation rapide de ces différents composants.
# Des formats
# Atom
Le format de base pour décrire des publications regroupées en collections, les flux. Je vous renvoie à mon article d'il y a quelques mois. Atom est extensible, c'est donc le format de base idéal sur lequel bâtir des flux que l'on enrichira d'autres informations.
# Activity Streams
Activity Streams est une proposition de norme visant à définir un format pour décrire des activités. Une activité est une action réalisée par un auteur sur un objet. Activity Streams se présente comme une extension du format Atom, c'est à dire que les informations sur l'activité peuvent enrichir un flux Atom. Le format est développé et a déjà été adopté par quelques jeunes startups comme Facebook, Google, Microsoft, MySpace, on peut donc espérer qu'il aura un certain avenir.
Deux spécifications sont en cours de rédaction, l'une décrivant le format lui-même, l'autre proposant des IRI pour des types d'actions (marquer comme favori, apprécier, entrer en contact, rejoindre, publier, partager, étiqueter…) et de cibles (article, commentaire, endroit, etc) classiques.
Pour l'instant, ce protocole est essentiellement utilisé dans StatusNet pour les communications entre serveurs. Par exemple, si l'utilisateur toto du serveur toto.org décide de suivre titi du serveur titi.net, à la fin du processus, après les différents contrôles, le serveur toto.org enverra au point d'entrée du serveur titi.net une notification contenant un enregistrement d'activité:
<?xml version="1.0" encoding="UTF-8"?> <feed xmlns="http://www.w3.org/2005/Atom" xmlns:activity="http://activitystrea.ms/spec/1.0/"> <author><name>toto</name> <uri>http://toto.org/toto</uri></author> <entry>
<id>follow:totoid:titiid:timestamp</id> <title>toto is following titi</title> <content type="html">toto is following titi</content> <activity:verb>http://activitystrea.ms/schema/1.0/follow</activity:verb> <activity:object> <activity:object-type>http://activitystrea.ms/schema/1.0/person</activity:object-type> <id>http://titi.net/titi</id> <activity:object>
</entry> </feed>
# Threading, géo-localisation…
StatusNet implémente également d'autres extensions du format Atom:
- Atom Threading pour lier des contenus entre eux au sein de fils, en permettant de définir, pour chaque entrée, deux séries de liens : les IRI des entrées auxquelles elle répond, et les IRI de ses réponses;
- GeoRSS permet elle d'ajouter des données géométriques et géographiques à un flux. Elle est utilisée ici pour donner les coordonnées, latitude et longitude, des différents objets (localisation habituelle de l'auteur, localisation spécifique de chaque entrée: georss:point45.5088375 -73.587809/georss:point;
- Atom Média pour décrire des contenus multimédias;
# Des protocoles
# PubSubHubSub
Le protocole PubSubHubbub, ou PuSH utilise un concentrateur, ou hub pour permettre de notifier en temps réel d'évènements. Il implémente les concepts de PubSub et de WebHooks dont j'avais déjà parlé et que j'utilisais dans le projet Sixties (bibliothèque PHP pour jouer avec les fonctions PubSub d'un serveur XMPP).
Le mécanisme est le suivant:
- un service désirant publier des contenus crée des points d'entrée dans un concentrateur. Ce sont des URL permettant de s'abonner aux mises à jour des contenus;
- il rend publique la liste de ces points d'entrée. Par exemple via la balise dans un flux Atom;
- les utilisateurs qui souhaitent être notifiés de la publication de nouveaux contenus dans le flux ont deux solutions : soit recharger le flux à intervalles réguliers (polling, comme le gamin sur la banquette arrière répétant inlassablement « à quelle heure on arrive ? »), soit s'abonner au Hub. Pour cela, il leur suffit d'envoyer une requête de souscription à l'adresse de son point d'entrée. Cette requête contient une URL de rappel;
- lorsqu'un évènement survient sur le serveur d'origine, il en informe le Hub. Celui-ci interroge alors éventuellement le serveur pour récupérer plus d'informations sur l'évènement, puis notifie l'ensemble des abonnés en postant le contenu aux URL de rappel associées à chaque abonnement.
L'ensemble des communications est réalisée en HTTP et utilise le format Atom.
StatusNet embarque son propre Hub, il n'est donc pas nécessaire de passer par des services tiers. Ainsi, pour être prévenu immédiatement de la publication d'un nouveau statut, il suffit d'envoyer une requête à l'adresse du hub contenu une URL à appeler. Pour être notifié de mes mises à jours sur identi.ca, un simple GET ressemblant à cela suffit : http://identi.ca/main/push/hub?hub.callback=http://www.toto.net/callback_url/&hub.topic=http://identi.ca/main/push/hub&hub.mode=subscribe (pour sécuriser la transaction, le protocole définit un mécanisme de challenge, d'échange de clés, etc, je n'entre pas dans les détails).
# Salmon
Salmon vise à notifier un contenu que du contenu en rapport a été publié. Pour utiliser le protocole, un flux doit fournir l'URL d'un point d'entrée à appeler lorsqu'une réponse est publiée. On peut préciser deux URL, l'une pour les réponses (par exemple les commentaires), l'autre pour les références. Un flux pourra contenir ce type de liens:
<feed xmlns='http://www.w3.org/2005/Atom'>
(…)
<link rel="http://salmon-protocol.org/ns/salmon-replies" href="http://example.org/all-replies-endpoint"/>
<Link rel="http://salmon-protocol.org/ns/salmon-mention" href="https://example.com/mention-handler" />
(…)
</feed>
Lorsqu'un serveur publie une réponse à un contenu publié sur un autre serveur (commentaire sur un article ou réponse à un statut par exemple), le serveur crée une entrée Atom au format Atom Threading et la publie à l'URL fournie dans le flux d'origine, via une requête HTTP POST. Le serveur d'origine peut alors s'il le désire publier la réponse et notifier tous les abonnés via PuSH. La spécification de Salmon prévoit un mécanisme de signature pour lutter contre le spam et différentes autres protections. Le protocole permet ainsi à des commentaires de remonter le flux jusqu'à sa source, d'où la référence au saumon, pour être ensuite partagé avec tous les abonnés au contenu initial.
Salmon me semble particulièrement intéressant car il répond à au moins deux problématiques:
- la fragmentation des contenus produits par un utilisateurs: un utilisateur peut désormais héberger sur son propre serveur ses réponses à des contenus publiés partout sur le Net. Il en garde le contrôle;
- la fragmentation des discussions : de multiples références à un article dans d'autres articles sont remontées à la source et, pour peu qu'icelle joue le jeu, partagées avec tous les utilisateurs qui la suivent;
# WebFinger
WebFinger part du constat que l'on est plus habitué, pour désigner une personne, à utiliser une adresse mail qu'une url. Ou du moins une adresse du type user@server. Malheureusement, à la différence des URL, les adresses mail ne permettent pas d'en savoir plus sur leur propriétaire, par exemple son identité, les adresses des services qu'il utilise, etc. Choses que permet une URI donnant accès par exemple à une page Web ou un profil FOAF.
WebFinger est donc un protocole permettant à partir d'une adresse de type user@server d'obtenir des méta-données sur l'utilisateur qu'elle désigne. Ces méta-données sont exprimées au format XRD. XRD est un vocabulaire créé par l'OASIS pour décrire toutes les méta-données de n'importe quelle ressource. Il est plus générique que FOAF, spécialisé dans la description des personnes et de leurs liens.
WebFinger s'appuie sur plusieurs autres protocoles en cours de discussion au sein de l'IETF:
- Defining Well-Known URIs propose de regrouper données de service d'un domaine dans un répertoire .well-known situé à la racine de ce domaine. Par exemple les fichiers destinés aux robots d'indexation, le plan du site, l'icône, etc;
- host-meta: Web Host Metadata propose que les méta-données d'un domaine soient stockées au format XRD dans un fichier host-meta à l'intérieur de ce dossier;
- LRDD: Link-based Resource Descriptor Discovery utilise un lien link pour référencer des méta-données sur un document. Ce lien peut être dans les entêtes HTTP d'une réponse à une requête, ou une balise LINK dans un document XML quelconque. Dans le cas des fichiers XRD de description d'un domaine, le lien pointera vers un template permettant d'obtenir des informations sur une ressource : par exemple
Le mécanisme utilisé par WebFinger pour obtenir un profil à partir d'une adresse est le suivant:
- transformer l'adresse mail en une XRI, un identifiant universel de ressource1. Cela se fait simplement en la préfixant de acct: pour 'account'';
- récupérer le fichier de description du domaine. Soit pour l'adresse acct:clochix@identi.ca le fichier https://identi.ca/.well-known/host-meta. On notera au passage que l'adresse mail n'a pas à exister. clochix@identi.ca n'est pas une adresse mail, mais l'identifiant de mon compte sur identi.ca;
- rechercher dans ce fichier le lien de type lrrd possédant un template : ;
- récupérer la description des données de l'utilisateur via ce template. On obtient un fichier XRD décrivant le profil de l'utilisateur.
# En pratique
Google fournit ce type d'information pour tous les utilisateurs de Gmail :
- GET https://gmail.com/.well-known/host-meta
on obtient le fichier suivant:
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns=‘http://docs.oasis-open.org/ns/xri/xrd-1.0’xmlns:hm='http://host-meta.net/xrd/1.0'>gmail.com/hm:Host
<Title>Resource Descriptor</Title>on peut alors consulter le profil de l'adresse toto@gmail.com à l'URL http://www.google.com/s2/webfinger/?q=acct:toto@gmail.com. Soit, pour quelqu'un ayant un profil public et activé Buzz, quelque chose comme:
<?xml version='1.0'?>
acct:toto@gmail.com http://www.google.com/profiles/toto
Ce qui rappelle au passage que Google est fournisseur OpenID. Le fichier contient également les liens vers le profil Google, dont les informations sont disponibles dans plusieurs formats, y compris FOAF et des micro-formats comme hCard et XFN, et le flux des mises à jour de Buzz.
Le même fichier est disponible sur toute installation de StatusNet 0.9. Par exemple, la description de mon compte sur identi.ca:
http://identi.ca/main/xrd?uri=acct:clochix@identi.ca
<XRD>
<Subject>acct:clochix@identi.ca</Subject>
<Alias>http://identi.ca/user/82435</Alias>
<Link rel="http://webfinger.net/rel/profile-page" type="text/html" href="http://identi.ca/user/82435"/>
<Link rel="http://schemas.google.com/g/2010#updates-from" type="application/atom+xml" href="http://identi.ca/api/statuses/user_timeline/82435.atom"/>
<Link rel="http://microformats.org/profile/hcard" type="text/html" href="http://identi.ca/clochix/hcard"/>
<Link rel="http://gmpg.org/xfn/11" type="text/html" href="http://identi.ca/user/82435"/>
<Link rel="describedby" type="application/rdf+xml" href="http://identi.ca/clochix/foaf"/>
<Link rel="http://salmon-protocol.org/ns/salmon-replies" href="http://identi.ca/main/salmon/user/82435"/>
<Link rel="http://salmon-protocol.org/ns/salmon-mention" href="http://identi.ca/main/salmon/user/82435"/>
<Link rel="http://ostatus.org/schema/1.0/subscribe" template="http://identi.ca/main/ostatussub?profile={uri}"/>
</XRD>
On trouve ici les liens vers mon profil, encore une fois disponible à plusieurs formats, ma timeline, les points d'entrées pour Salmon et pour s'abonner à mes mises à jour via OStatus.
# OStatus
OStatus s'appuie sur les précédents protocoles pour définir un format d'échange entre des serveurs.
# Les statuts
Chaque statut correspond à une activité au format Activity Streams, donc à une entrée Atom. L'action retenue est la publication (post) d'un objet qui peut être une note, c'est à dire un court billet ne contenant qu'un corps (à la différence d'un article qui contient lui également un titre et un résumé), un statut ou un commentaire. Notes et statuts sont similaires, la différence est sémantique, le contenu d'un statut se rapportant à son auteur quant une note peut traiter de n'importe quel sujet.
Un statut peut être lié à :
- d'autres contenus auxquels il répond, via Atom Threading s'il constitue une réponse : /thr:in-reply-to
- des personnes : lorsque je m'adresse à quelqu'un;
- d'autres statuts s'il fait partie d'une conversation:
# Les flux
L'activité d'un utilisateur est regroupée au sein de flux Atom. Chaque flux doit posséder un point d'entrée PuSH fournissant l'URL où s'abonner à ses mises à jour. Il peut également fournir des point d'entrée Salmon où être notifié des réponses et des mentions.
Par exemple, voici un extrait du flux d'Evan Prodromou, le créateur de StatusNet :
<?xml version="1.0" encoding="UTF-8"?> <feed xml:lang="en-US" xmlns="http://www.w3.org/2005/Atom"> <id>http://evan.status.net/api/statuses/user_timeline/1.atom</id> <title>evan timeline</title> <author><name>evan</name> <uri>http://evan.status.net/user/1</uri>
</author> <link href="http://evan.status.net/" rel="alternate" type="text/html"/> <link href="http://evan.status.net/main/push/hub" rel="hub"/> <link href="http://evan.status.net/main/salmon/user/1" rel="http://salmon-protocol.org/ns/salmon-replies"/> <link href="http://evan.status.net/main/salmon/user/1" rel="http://salmon-protocol.org/ns/salmon-mention"/> <link href="http://evan.status.net/api/statuses/user_timeline/1.atom" rel="self" type="application/atom+xml"/> (…)
# Les communications
Les communications entre les serveurs utilisent WebFinger pour découvrir les adresses des flux des utilisateurs, PuSH et Salmon pour échanger des messages.
Lorsqu'un utilisateur publie un nouveau statut, son serveur notifie l'ensemble des abonnés de la mise à jour via PuSH.
Les serveurs recourent à Salmon pour échanger entre eux des évènements concernant leurs utilisateurs:
- lorsqu'un utilisateur publie un contenu à l'attention d'un autre utilisateur (en utilisant par exemple la syntaxe @toto qui se traduira par un link rel="ostatus:attention" dans le flux), son serveur envoie une notification au serveur du destinataire via le point d'entrée Salmon;
- idem pour les réponses;
- lorsqu'un utilisateur s'abonne ou se désabonne aux mises à jour d'un autre utilisateur, rejoint ou quitte un groupe, ajoute le statut d'un autre utilisateur à ses favoris ou le re-publie, son serveur notifie de même le serveur de l'utilisateur ou du groupe concerné.
Ouf ! Le repas était copieux, il va falloir un peu de temps pour assembler les pièces du puzzle et digérer tout ça. Mais je suis pour la première fois depuis longtemps optimiste en ce qui concerne les silos de données : bien sûr OStatus n'attaquera pas la suprématie de Facebook et Twitter, mais pour qui souhaite reprendre la main sur ses flux, une solution existe à présent qui me semble crédible, ou en passe de le devenir. Ne reste plus qu'à attendre que Facebook et Twitter implémentent OStatus pour permettre au monde libre de dialoguer avec leurs prisonniers. Vont-ils le faire ?