ActivityPub : le W3C fera-t-il (enfin) le printemps des médias sociaux partagés ?

On peut dire sans trop se tromper que l’information n’a pas été particulièrement relayée – voire a particulièrement intéressé… – la communauté informatique. En début d’année, le W3C, consortium « international » (de droit US pour le « siège ») à portée normative et « politique » (au sens du débat public), intègre ActivityPub en recommandation. Signe d’un début à la fois de reconnaissance et de la qualité du travail accompli par ses créateurs.

Pourtant ActivityPub développe une logique dans l’air du temps, tentant une fois de plus d’inventer un standard suffisamment large pour réunir tous les usages sociaux « classiques » que je réunis ici sous trois grandes familles :

• one-to-all → microblogging et contenus publics ;
• one-to-one → interactions sociales – poke, like, et autres j’aime –, messagerie privée ;
• all-to-one → commentaires, flux d’actualités.

ActivityPub permet aussi, dans une moindre mesure, de disposer d’une sorte d’accès à des ressources et publications internes : agendas, brouillons, contacts, etc.

ActivityPub n’est pas à proprement parler une création, mais un nouvel usage, en cela une variante spécialisée, qu’est Activity Streams – c’est-à-dire en bon français un flux d’activité.

Résumons en trois points, les intérêts et les menaces qu’offre ce nouvel outil fort intéressant s’il est massivement adopté.

En résumé rapide, ActivityPub n’est pas un protocole comme HTTP ou le couple IMAP/SMTP. Il s’agit d’une interface afin d’utiliser une API, un framework – en résumé un cadre. Il n’offre ni grammaire, ni syntaxe sur lesquelles reposeraient les échanges. ActivityPub se sert de l’existant – le format JSON pour la représentation des données notamment.

En cela, ActivityPub pourrait être vite, mais mal résumé comme une sorte de clone en JSON de XMPP (déjà quelques articles peuvent traîner pour les mettre côte à côte… une réalité d’usages probablement, mais une hérésie technique assurément).

La différence repose sur un fait simple, que XMPP utilise XML mais en définit sa propre grammaire et bien davantage qu’une simple logique d’échange. XMPP n’indique pas particulièrement un usage, mais une procédure d’échange. Les deux peuvent être étendus dans leur domaine.

ActivityPub mixe les approches et ressemble dans le travail actuel à une version très aboutie d’une API type REST entre différents acteurs, dans un cadre global. Car il utilise les termes d’actions de HTTP (requêtes GET et POST notamment). Nous verrons plus loin combien cela a son importance et la chance que cela représente pour l’adoption large d’ActivityPub.

Concrètement, un serveur permet à un compte utilisateur, lié à un domaine en particulier, d’avoir un profil. Exemple : julien@actpub.truc.com. Sur ce serveur, l’équivalent de deux dossiers – ou deux endpoints, c’est selon –, donne accès à une boîte entrante et une boîte sortante. Exactement comme les débuts des courriels. La différence, c’est qu’un message peut être n’importe quelle activité sociale ou privée…

Un compte utilisateur peut être alimenté soit directement par un usage humain (à travers n’importe quel logiciel qui supporte ActivityPub – ou en ligne de commande si c’est votre trip !), soit un bot, qui va par exemple crawler pour vous des données.

Le serveur lié au domaine, communique – et c’est là où l’on sort du cadre habituel des réseaux sociaux à la Twitter ou Facebook – avec une fédération (le terme est important !), où les profils peuvent être dupliqués (julien@actpub.truc.com ↔ julien@actpub.bidule.com), ou interagir avec un autre réseau / un autre utilisateur qui utilise ActivityPub (mathieu@actpub.chouette.fr ↔ julien@actpub.truc.com).

Ce sont donc les serveurs qui, sur « ordre » des utilisateurs du compte utilisateur, iront faire soit leurs emplettes ailleurs, soit être destinataire d’une information. L’identification unique, comme pour les courriels ou NNTP, repose sur un couple nom d’utilisateur / domaine, à savoir une URI ; ici sous la forme d’une URI : http://actpub.truc.com/julien.

L’unicité du domaine sur le Web et l’unicité du compte utilisateur sur le serveur créent une unicité pour chaque compte sur l’ensemble des domaines du Web – et par extension sur Internet.

Un accès par URL, donne un accès soit en lecture, soit en écriture, soit les deux, en fonction de qui demande, à des « piles » de contenus :

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Person",
  "id": "http://actpub.truc.com/julien/",
  "name": "Julien Garderon",
  "preferredUsername": "Nothus",
  "summary": "En reprise d'études par alternance dans une entreprise énergétique",
  "inbox": "http://actpub.truc.com/julien/inbox/",
  "outbox": "http://actpub.truc.com/julien/outbox/",
  "followers": "http://actpub.truc.com/julien/followers/",
  "following": "http://actpub.truc.com/julien/following/",
  "liked": "http://actpub.truc.com/julien/liked/"
}

…voire rajouter des lignes :

"documents" : " http://actpub.truc.com/julien/documents/", 
"films" : " http://actpub.truc.com/julien/films/", 
...

En cela, comprendre ActivityPub revient à comprendre le fonctionnement des courriels entre les MTA – Mail Transfer Agent – et les MDA – Mail Delivery Agent –. Voir le schéma suivant :

Votre courriel est légitime non pas parce que MUA – comme l’est Thunderbird – porte directement le courriel au MTA de votre destinataire, parce que les MTA « filtrent » et gèrent cette partie (avec une question de « confiance » entre MTA et de files d’attente) et que votre MUA porte votre courriel au MTA qui est associé au domaine duquel le courriel semble partir.

Au point même que ActivityPub impose des champs JSON type TO ou CC, qui doivent être recopiés pour la diffusion !

Ainsi une INBOX d’un compte utilisateur, peut être écrite par un serveur de la fédération (c’est-à-dire qui respecte la forme ActivityPub). À l’inverse, au travers de votre serveur, vous pouvez « interroger » l’OUTBOX d’un autre profil pour récupérer ce à quoi vous avez le droit.

Une requête type (ici pour un like), issue de la documentation du W3C, est très éclairante :

POST /outbox/ HTTP/1.1
Host: dustycloud.org
Authorization: Bearer XXXXXXXXXXX
Content-Type: application/ld+json; profile="https://www.w3.org/ns/activitystreams"
{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "@language": "en"
    }
  ],
  "type": "Like",
  "actor": "https://dustycloud.org/chris/",
  "name": "Chris liked 'Minimal ActivityPub update client'",
  "object": "https://rhiaro.co.uk/2016/05/minimal-activitypub",
  "to": [
    "https://rhiaro.co.uk/#amy",
    "https://dustycloud.org/followers",
    "https://rhiaro.co.uk/followers/"
  ],
  "cc": "https://e14n.com/evan"
}

Évidemment, au-delà de l’unicité de l’identité du compte utilisateur – encore une fois, ce n’est pas nécessairement seulement un seul humain qui est derrière –, une série d’identifiants pour chaque contenu est générée pour éviter les doublons.

La réponse à une telle requête, peut-être une ressource ou simplement un retour HTTP suivant les canons du protocole :

HTTP/1.1 201 Created
Location: https://dustycloud.org/likes/345

De la même façon, vous aurez noté l’entête Authorization avec une valeur « bearer » permettant l’utilisation, la souplesse et l’efficacité des JSON Web Token, ou encore la très grosse machinerie avec OAuth2.0. L’insertion d’ActivityPub dans un contexte plus large, sans ouverture de nouveaux ports sur le réseau et simplement avec quelques manipulations pouvant être réalisées par des langages de haut niveau (PHP par exemple), conjointement avec HTTPS, a tout du client idéal pour diffuser des interactions sociales.

Ou même, soyons fous, remplacer le traditionnel accès par IMAP/POP3 par votre navigateur favori (vive Firefox)… !

Après cette période d’enchantement technique, place à certaines réalités. Car il y en a, et pas des moindres.

Avec les monnaies « virtuelles cryptographiques » – comprenez Bitcoin et autres cryptomonnaies –, le développement toujours plus étendu des Haas/SaS (dans l’univers de l’informatique de salon, du jeu ou des services en ligne : shadow pc, instances virtualisées, web services, etc.), la question de la décentralisation et de son corollaire de la dématérialisation pour les utilisateurs (des réseaux sociaux, et de tous les outils numériques) se fait toujours plus pressante. Ces derniers ne sont plus que des utilisateurs réduits à la plus simple expression du terme.

Avec parfois des illusions fortes, tenaces, pour ces mêmes utilisateurs, qui voient dans la décentralisation un (forcément) meilleur contrôle de leurs données privées et de la (grande) discrétion sur l’usage des services ; quand ce n’est pas un mythe de fausse liberté « démocratique » d’une monnaie tout à fait dématérialisée (en réalité le poids du consensus d’un registre…). Cet exemple illustre le mythe d’une informatique détachée d’une réalité physique et matérielle. Tant que le serveur n’est pas sous votre contrôle, pas la peine d’être un GAFA pour aller sur la pente de la vente ou du recel de données privées. L’aspect logiciel « libre » (et/ou la gratuité qui y est souvent associée, comme la décentralisation), n’est pas une garantie. Un logiciel a une installation, un contexte, un environnement, qui peuvent être délétères directement (choix d’administration, d’intégration) ou indirectement (failles ou mauvaises pratiques).

Pire : d’un point de vue juridique, la multiplication d’instances privées, sans structures juridiques claires et réelles, prive l’utilisateur d’avoir a minima un visage sur lequel débattre et développe une incertitude juridique quant à « l’offre technique » à laquelle il est inscrit. Quels que soient les types d’outils utilisés : le grand public donne alors à l’opérateur du réseau – souvent des FAI dont ce n’est historiquement et culturellement pas le métier, à une entreprise privée et donc avec des objectifs bien différents d’institutions publiques d’une société civile –, le rôle de modérateur en dernier ressort.

Ainsi tout comme pour les cryptomonnaies, la décentralisation ne résout pas le problème de la régulation qui est posée, certes sous une autre forme mais avec les mêmes conséquences, par les géants du Web : protection de la vie privée et respect de la propriété privée (face au vol des clés, pas de « réparation » possible), sécurité et sûreté des installations, coût énergétique pour l’environnement, financement (ou non) par la publicité des services, lutte contre le harcèlement / place et limites de la liberté d’expression, etc.

Le mieux étant l’ennemi du bien, se poser la question en termes de philosophie d’implémentation technique sans celles d’éthique de la pratique, de la légitimité du contrôle et du respect des lois nationales en vigueur, n’offre pas beaucoup d’intérêt pour l’usager d’un service…

Ce n’est pas la première fois qu’un protocole ou un cadre promettra – à raison, n’en doutons pas pour l’instant – monts et merveilles. Et échouera face aux habitudes, à la déroute d’une normalisation qui fera de l’outil un « machin » poussif et déjà poussiéreux lorsque la procédure sera terminée.

XMPP résume cela : des contraintes de réseaux (ouverture de ports), une faiblesse dans l’utilisation du XML (mal usité, car bien trop usité ?), une réinvention de la roue (il s’agit d’un protocole « complet » et évolutif→ pas de limite mais aussi pas d’interopérabilité simple !). Pourtant, XMPP a le même esprit, antérieur à ActivityPub, de cette volonté de décloisonner le Web et plus largement Internet.

XMPP a pu s’imposer çà et là – notamment la téléphonie IP/visioconférence ou l’échange de données en entreprise ; loin d’être anecdotique mais notre sujet n’est pas là – ; mais pour le « grand public », il n’offre pas la « simplicité » d’un Twitter ou d’un Facebook, directement utilisables parce ce sont des services complets, prêts à la demande. J’insiste : soit par le navigateur, soit par une application claire et disponible partout (fixe, mobile), mise à jour et maniable. Ni leur poids respectif, avec Apple et Google en plus, dans l’usage : d’ailleurs, toutes ces entreprises ont abandonné le protocole au profit de leur propre API, dans un intérêt économique, portant un coup dur au développement par XMPP comme relais des plateformes entre elles.

Pourtant XMPP n’est pas mauvais en soi et je ne voudrais pas qu’il soit mal compris à la lecture de cet article sur son rôle : il est utilisé et très utilisé certes, mais il est condamné à l’environnement professionnel par l’usage, son absence réelle d’utilisation suffisamment large pour le rendre vraiment « grand public » et adopté par les développeurs de réseaux sociaux alternatifs et les administrateurs de serveurs. C’est sa trop grande ambition de départ qui le condamne à être « un de plus ».

Ne doutons pas enfin que c’est l’adoption d’un protocole par des puissances économiques et donc indirectement par les utilisateurs internes et externes (salariés ou clients) qui permet à une technologie d’être totalement adoptée à l’aune de toute une société. Pas grâce à son intelligence ou sa beauté.

ActivityPub a des chances de réussir peut-être davantage que XMPP vis-à-vis du grand public. Par sa simplicité plus grande, par utilisation possible de serveurs tels qu’Apache et donc la possibilité d’utiliser des serveurs mutualisés fournissant déjà un service sur lequel se greffer… Car probablement le défi est là : faire accepter non pas une nouvelle technologie, mais un usage commun sur des plateformes existantes. Un usage commun qui doit faire face à des réalités que nous n’avons pas tous un serveur indépendant, des super-compétences techniques, du temps et de l’énergie à passer à régler tel ou tel détail d’un programme ou d’un réseau. Qu’il y a un avant, que beaucoup ne veulent pas modifier / remettre en cause.

ActivityPub n’a pas ce problème de par sa nature même, et il est d’ailleurs adopté par quelques « grands noms » des réseaux sociaux décentralisés, particulièrement Mastodon (alternative à Twitter) ou Peer-Tube (alternative à… YouTube, gagné !).

ActivityPub risque – je dis bien « risque » – de réussir parce qu’il utilise le port 80 pour HTTP et le port 443 pour HTTPS, des ports déjà largement usités ; parce que le programme qui l’implémente peut tourner en Python, en PHP, en C, en Java, en JavaScript/V8, en ce que vous voulez ; parce qu’il est pour le client, possible de l’implémenter dans une page Web en JavaScript et dans une base locale avec IndexedDB : après tout, ce n’est jamais que du JSON ; parce qu’il reprend une logique des courriels, qui est une « bonne » logique pour gérer le filtre et les files d’attente dans les échanges de contenus (que reprenait XMPP avec quelques spécificités).

Oui, ActivityPub risque de réussir et à terme d’emmener beaucoup de monde avec lui. Mais sans effacer des menaces inhérentes au Web contemporain qu’il maintient.

Nous tenons à remercier f-leb pour la relecture orthographique de ce tutoriel.