? Sortir le Web des silos (archive)

Source originale du contenu

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 « » 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 :

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:

# 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:

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:

# 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:

Le mécanisme utilisé par WebFinger pour obtenir un profil à partir d'une adresse est le suivant:

  1. transformer l'adresse mail en une XRI, un identifiant universel de ressource1. Cela se fait simplement en la préfixant de acct: pour 'account'';
  2. 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;
  3. rechercher dans ce fichier le lien de type lrrd possédant un template : ;
  4. 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 :

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é à :

# 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:

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 ?