RSC : et si le web social n'avait jamais eu besoin d'un nouveau protocole ?

Depuis vingt ans, chaque tentative de « réinventer » le web social commence par la même étape : inventer un protocole. XMPP, OStatus, ActivityPub, AT Protocol, Nostr. À chaque fois la promesse est la même, à chaque fois le coût d’entrée est le même : il faut que tout le monde adopte la nouvelle plomberie avant que quoi que ce soit ne circule.

RSC part d’une hypothèse inverse, presque provocante dans sa banalité : la plomberie existe déjà, elle s’appelle RSS, et elle n’a jamais cessé de fonctionner.

RSC signifie Really Simple Conversations. C’est un fil social (une timeline vivante) dans lequel les messages publiés sur l’instance et les messages publiés ailleurs, sur le site personnel de quelqu’un d’autre, sont des citoyens strictement égaux. Tout circule en flux ouverts : les billets, mais aussi les réponses, les fils entiers, et même les corrections apportées après publication.

Le problème : l’application est propriétaire de la relation

La difficulté des réseaux sociaux fermés n’est pas seulement qu’ils hébergent vos contenus. C’est qu’ils hébergent le lien entre vous et vos lecteurs.

Vos billets sont chez eux, vos abonnés sont chez eux, et surtout le fil de discussion qui relie les deux est chez eux. Le jour où la plateforme change ses règles, ferme son API ou disparaît, ce n’est pas votre archive que vous perdez en premier : c’est votre capacité à continuer une conversation commencée.

Le blog, lui, a toujours été l’inverse. Vous publiez chez vous, un flux RSS sort de chez vous, et n’importe qui peut le lire sans autorisation. Ce modèle a survécu à Google Reader, aux jardins clos, aux algorithmes. Il est encore là.

Ce que RSS n’a jamais vraiment su faire, en revanche, c’est la conversation. On pouvait suivre. On ne pouvait pas répondre, ni voir un fil se reconstituer entre plusieurs sites.

C’est exactement ce trou que RSC essaie de combler.

L’idée en une phrase

Une réponse est un billet. Un billet voyage en RSS. Donc une conversation peut voyager en RSS.

Le reste n’est que de l’ingénierie.

Comment une conversation traverse plusieurs sites

Prenons trois instances indépendantes, hébergées par trois personnes différentes, sans rien de commun sauf le web.

1. Une conversation commence sur rsc.rmdes.be. Le billet part dans le flux de l’instance.
2. Alice, sur alice.rmdes.be, lit ce flux et répond. Sa réponse est un billet chez elle, qui sort dans son propre flux, en portant une référence au billet d’origine.
3. Bob, sur bob.rmdes.be, lit la réponse d’Alice et rejoint le fil depuis son site.
4. Le fil complet revient, reconstitué, sur l’instance de départ.

Trois serveurs indépendants. Aucune API partagée. Aucun compte commun. Une seule conversation.

Techniquement, le rattachement repose sur trois éléments transportés dans le flux : l’identifiant stable du billet (guid), la source qui l’a publié, et la référence au message parent (source:inReplyTo, doublée du standard RFC 4685 thr:in-reply-to).

Le point délicat, ce sont les arrivées dans le désordre. Sur le web ouvert, une réponse peut très bien être récupérée avant le message auquel elle répond, parce que le flux du parent est interrogé moins souvent. RSC choisit ici l’honnêteté plutôt que le silence : une réponse orpheline reste visible avec le contexte qu’elle transporte, au lieu d’être jetée, et elle se rattache automatiquement à son parent dès que celui-ci arrive.

Ce qui rend la chose vivante plutôt que différée

Une objection classique au RSS : c’est lent, on interroge les flux toutes les quinze minutes, ça ne fait pas un réseau social.

C’est vrai du RSS des lecteurs de flux. Ce n’est pas vrai du RSS complet.

Deux mécanismes anciens et peu utilisés changent tout :

• WebSub : au lieu d’attendre que les abonnés viennent lire, l’éditeur pousse la nouveauté vers eux.
• rssCloud : le mécanisme de notification de Dave Winer, du même esprit.

RSC utilise les deux, dans les deux sens : il pousse ses nouveautés, et il accepte de recevoir celles des autres. La fédération est donc immédiate, pas seulement périodique. Dans l’interface, la timeline se met à jour en direct via SSE (Server-Sent Events), et continue de fonctionner sans JavaScript, où les onglets redeviennent de simples liens.

Les corrections voyagent aussi

C’est un détail qui dit beaucoup sur la philosophie du projet.

Quand un auteur corrige un billet déjà publié, RSC ne réécrit pas silencieusement l’histoire : il conserve un historique de révisions consultable. Et parce que le billet voyage sous un identifiant stable accompagné d’un marqueur atom:updated, chaque instance qui l’avait déjà ingéré détecte la modification à la lecture suivante, met à jour sa copie, et enregistre elle aussi sa révision.

La correction se propage donc partout où le billet est allé, sans remonter artificiellement en haut de la timeline. Tout cela en RSS ordinaire.

La filiation : Dave Winer et Textcasting

RSC ne prétend rien inventer. Il assemble.

Le projet s’inscrit dans le sillage de Textcasting, le manifeste de Dave Winer, dont l’exigence centrale est simple : un texte doit voyager avec sa mise en forme et son sens intacts, du logiciel d’écriture jusqu’au lecteur, sans être aplati par la plateforme du milieu.

Concrètement, chaque billet local est publié selon un double contrat : le HTML rendu et assaini pour les lecteurs, et le Markdown source à côté. Celui qui reçoit choisit ce dont il a besoin.

L’interopérabilité avec rss.chat, le projet de conversation en RSS de Winer, est réelle et testée dans les deux sens : RSC consomme son firehose avec l’attribution correcte des auteurs et le fil complet, et émet le même vocabulaire, si bien que son propre outil de parcours de fils lit les conversations RSC sans la moindre modification mais pour l’instant la fédération ne fonctionne qu’entre instance RSC car la fédération n’est pas encore implémentée chez rss.chat (même si des forks travaille déjà à l’interopérabilité entre instance rss.chat)

Le reste de la généalogie est du même ordre : la communauté IndieWeb pour les microformats, JSON Feed par Manton Reece et Brent Simmons, OPML pour importer et exporter une liste d’abonnements comme on l’a toujours fait avec une blogroll.

Ce qui fonctionne déjà, et ce qui manque

Le projet est en pré-version, mais pas au stade de la maquette. Fonctionnent aujourd’hui de bout en bout : la timeline unifiée à quatre onglets (local, fédéré, personnel, public), la publication et l’édition, les fils de discussion, les abonnements à n’importe quel flux RSS, Atom ou JSON, l’import et l’export OPML, la découverte de flux à partir d’une simple page HTML, les comptes (invité, mot de passe ou lien magique) et la fédération en temps réel.

Restent à venir : la connexion IndieAuth, la publication via Micropub, les Webmentions, et une meilleure récupération des médias depuis les flux externes.

Côté administration, chaque instance garde la main sur ses comptes, ses sources, ses limites et sa modération, avec un journal d’audit. La gouvernance fait partie du produit, elle n’est pas une réflexion après coup.

L’installer chez soi

Le code est sous licence MIT, sans édition « entreprise » séparée ni dépendance à un service hébergé. La démonstration publique et l’instance que vous pouvez lancer sont exactement le même logiciel.

git clone https://github.com/rmdes/rsc.git
cd rsc && make up

En production, un make prod-env puis make prod-up suffisent : le tout tourne derrière Caddy, qui obtient et renouvelle le certificat HTTPS automatiquement. Les données sont dans SQLite, chez vous.

L’architecture est volontairement modeste : un service core sans interface (Hono, Node, SQLite) qui possède les flux, l’ingestion, la reconstruction des fils et les points d’entrée de fédération ; et une application web (SvelteKit) qui est la seule chose que les navigateurs touchent. Le cœur ne publie aucun port et n’est joignable qu’à travers ce partage.

Ce que ça dit, au fond

Le web social n’a jamais disparu. Il a été recouvert.

Les silos n’ont pas gagné parce qu’ils étaient techniquement supérieurs, mais parce qu’ils ont rendu l’entrée gratuite et la sortie coûteuse. RSC est une tentative de rendre la sortie aussi simple que l’entrée : la même commande vous fait essayer et vous fait partir avec vos données.

Ce n’est pas une révolution technique. C’est une remise en service.

Démo : rmdes.be · Code : github.com/rmdes/rsc · Licence MIT