- IndieWeb est une alternative centrée sur les personnes au web dominé par les entreprises, ainsi qu’une communauté, qui vise à préserver contenus, identité et conversations sur un domaine personnel tout en se connectant aux réseaux sociaux lorsque c’est utile
- À partir de son propre domaine, il combine de petits standards comme microformats2,
rel="me", Webmention, IndieAuth et Micropub pour rendre le HTML lisible par les machines et prendre en charge l’authentification, la publication et les conversations entre sites - Les 23 millions de pages de GeoCities et plus de 50 millions de morceaux de MySpace ont disparu ; selon une étude de Pew Research en 2024, 38 % des pages web qui existaient en 2013 étaient inaccessibles dix ans plus tard
- POSSE consiste à publier d’abord l’original sur son propre site puis à le diffuser sur des plateformes externes ; Backfeed renvoie les likes, réponses et repartages externes vers l’original via Webmention afin de préserver toute la conversation sur un domaine personnel
- Sur le site réel, Webmention, h-entry, h-card et
rel="me"ont été appliqués, mais Micropub, IndieAuth et WebSub ont été écartés car ils ne correspondaient pas au flux de travail existant avec Git et Markdown, ni au délai de publication de 24 heures ; plutôt que d’adopter toutes les spécifications, il est préférable d’appliquer progressivement les technologies nécessaires
Le web que vise l’IndieWeb
- IndieWeb se définit comme une « alternative centrée sur les personnes au web d’entreprise » et ressemble davantage à un socle idéologique accueillant diverses approches et divers projets qu’à un logiciel ou framework particulier
- En 2010, après avoir participé au Federated Social Web Summit à Portland, Aaron Parecki et Tantek Çelik ont conclu qu’il fallait une approche centrée sur les créateurs plutôt que sur les protocoles
- Le premier IndieWebCamp a eu lieu à Portland en 2011, puis s’est tenu chaque année dans différentes régions du monde
- Au Homebrew Website Club, les participants se réunissent pour améliorer leur site web personnel
- Les trois piliers de l’IndieWeb sont les suivants
- Propriété du contenu : le contenu publié sur le web doit appartenir à l’éditeur, et non à une entreprise
- Meilleure connectivité : il doit être possible de diffuser ses articles sur plusieurs plateformes et de ramener les réponses et likes externes vers son propre site
- Contrôle : il faut pouvoir publier et lire dans le format souhaité, tout en conservant des URL pérennes
- Il n’interdit pas l’usage des réseaux sociaux en soi, mais s’oppose aux écosystèmes fermés qui enferment contenus et interactions
Silos et disparition des contenus web
- Un silo est généralement un site web centralisé exploité par une entreprise commerciale, qui revendique des droits sur les contenus fournis par les utilisateurs ou en limite l’accès
- Participer nécessite un compte propre à chaque service
- Seuls les comptes du même service peuvent interagir entre eux
- Des conditions d’utilisation restrictives, des exigences de licence sur les contenus, le blocage de l’indexation par les moteurs de recherche et des obstacles à l’import/export peuvent s’y ajouter
- Quand un silo ferme, les contenus des utilisateurs peuvent disparaître avec lui
- GeoCities a été fermé par Yahoo le 26 octobre 2009, entraînant la disparition de 23 millions de pages
- MySpace a perdu en 2019, lors d’une migration de serveurs, plus de 50 millions de morceaux publiés par 14 millions d’artistes au cours de ses 12 premières années
- Google+ a fermé en avril 2019
- Posterous, FriendFeed, Vine, Yahoo Groups, TinyLetter, Cohost, entre autres, figurent aussi dans la liste des services fermés
- Même si un silo ne ferme pas, les contenus web peuvent disparaître
- Selon une étude de Pew Research en 2024, 38 % des pages web qui existaient en 2013 étaient inaccessibles dix ans plus tard
- Le principe de réponse n’est pas de ne pas utiliser les réseaux sociaux, mais de placer la copie canonique du contenu sur un domaine que l’on contrôle
Les 11 principes de la communauté
- Les 11 principes ne sont pas un ordre de priorité et ne constituent pas non plus une obligation à remplir intégralement
- Posséder ses données : placer contenus, métadonnées et identité sur son propre domaine et conserver un accès sur le long terme
- Utiliser et publier des données visibles : donner la priorité aux humains puis aux machines, et ne pas créer d’API séparée si les données peuvent être intégrées au HTML
- Construire ce dont on a besoin : créer des outils pour soi-même, réellement, plutôt que pour des utilisateurs hypothétiques dont l’existence est incertaine
- Utiliser directement : utiliser chaque jour ce que l’on a créé et vérifier que cela mérite qu’on en dépende
- Documenter : consigner processus, idées et code sur son propre site afin d’aider les autres et son futur soi
- Publier en open source : ce n’est pas obligatoire, mais cela aide les autres à rejoindre plus vite le web indépendant
- L’UX avant les protocoles : définir d’abord l’expérience utilisateur, puis n’utiliser que les protocoles les plus simples et les plus petits qui la prennent en charge
- Modularité : créer de petits composants faiblement couplés pour éviter la dépendance à un appareil, langage ou plateforme donné
- Pérennité : construire des technologies web qui n’obligent pas à jeter le travail existant tous les quelques années au nom du progrès
- Pluralité : encourager délibérément plusieurs approches afin de bâtir une communauté plus résiliente qu’une monoculture technique
- Plaisir : préserver l’expression personnelle étrange et intéressante, comme sur le web des années 1990
Une architecture technique qui commence par le domaine personnel
- Utiliser son propre domaine comme identité principale en ligne est le prérequis de toute la configuration
- Même en changeant d’hébergement ou de CMS, conserver le domaine permet de préserver liens, lecteurs et référencement
- C’est aussi la condition minimale reconnue par la communauté pour participer à l’IndieWeb
- Plutôt qu’une plateforme unique, l’IndieWeb utilise de petites spécifications combinables entre elles ; l’index officiel des spécifications les classe selon leur historique d’implémentation et leur diffusion
microformats2 : utiliser HTML comme API
- microformats2 rend le contenu lisible par les machines en ajoutant des classes CSS au HTML existant, sans fichier ni API séparés
h-*: objet racinep-*: texte brutu-*: URLdt-*: datee-*: HTML inclus
- h-card représente l’identité personnelle — nom, URL, photo, etc. — et permet aux applications d’afficher un profil à côté des publications et d’identifier l’utilisateur
- Contrairement à Gravatar, basé sur l’e-mail, il fonctionne à partir du domaine
- h-entry est le composant central du contenu IndieWeb : il indique le titre, l’auteur, la date de publication, le corps d’un billet, etc.
- h-feed regroupe plusieurs h-entry pour faire de la page de liste HTML elle-même un flux auquel on peut s’abonner
- L’ensemble forme une architecture où le « site web est l’API » : microformats pour la lecture, Micropub pour l’écriture
rel="me" et vérification d’identité distribuée
rel="me"déclare que la cible d’un lien représente la même personne que la page actuelle- Lorsque le site web et les profils externes se lient mutuellement avec
rel="me", une vérification d’identité mutuelle est possible sans autorité centrale- Mastodon utilise cette structure pour afficher un badge de vérification vert sur un domaine
- Threads, PixelFed, GitHub, Keybase et Wikipedia la prennent aussi en charge
- RelMeAuth délègue la preuve d’identité à un fournisseur OAuth lié depuis la page d’accueil, comme GitHub, afin de s’authentifier auprès de services avec une URL personnelle
- C’est la base de services comme IndieLogin
Webmention : des conversations entre sites web
- Webmention est une W3C Recommendation depuis le 12 janvier 2017 ; succédant à Pingback, il transmet commentaires, likes, réponses et repartages entre sites, sans plateforme
- La procédure d’envoi est la suivante
- La publication émettrice contient un lien vers l’article cible
- Le serveur émetteur trouve l’endpoint de réception dans l’en-tête HTTP
Linkde l’article cible ou dans le<link rel="webmention">du HTML - Il envoie une requête POST ne contenant que
source, l’article émetteur, ettarget, l’article cible - Le serveur récepteur télécharge
sourceet vérifie qu’il contient réellement un lien verstarget - Il analyse le h-entry de
sourcepour distinguer réponse, like ou repartage, puis affiche le nom et la photo de l’auteur via h-card
- Chaque site devient un nœud, et les liens entre sites constituent le graphe social, mais les problèmes de spam et de modération subsistent
- Vouch déplace le coût du filtrage vers l’émetteur en transmettant comme troisième paramètre un site garant, déjà connu du récepteur et contenant un lien vers le domaine émetteur
- Salmention propage les fils de discussion en faisant renvoyer par la publication d’origine des Webmentions mises à jour aux participants lorsqu’un commentaire reçoit une réponse
- Pour les sites statiques sans backend, webmention.io reçoit les Webmentions à leur place et fournit une API de consultation
- Il peut être utilisé avec des générateurs de sites statiques comme Hugo, Jekyll ou Eleventy
Connexion et publication basées sur le domaine
- IndieAuth utilise une URL personnelle comme identité de connexion au lieu d’un compte Google ou Facebook
- Il s’appuie sur OAuth 2.0 et identifie utilisateurs et applications par des URL
- DNS remplace l’enregistrement préalable des clients, et PKCE, qui empêche le vol de jetons d’accès, est obligatoire
- Le service trouve le serveur d’authentification dans le
rel="indieauth-metadata"de la page utilisateur et, une fois l’authentification terminée, vérifie le contrôle de cette URL - Les modes d’authentification peuvent inclure mot de passe, e-mail, RelMeAuth, etc.
- Micropub est une W3C Recommendation depuis mai 2017 et sépare le logiciel du site de l’interface de publication
- Des clients web, iOS et Android peuvent créer, modifier et supprimer des publications sur un domaine personnel
- Au lieu de MetaWeblog et AtomPub, qui partageaient des mots de passe, il utilise des jetons OAuth obtenus via IndieAuth
- Il ne crée pas de vocabulaire séparé : il sérialise et transmet des propriétés h-entry comme
h=entryetcontent
Flux temps réel et lecteurs découplés
- WebSub, auparavant appelé PubSubHubbub, est une W3C Recommendation depuis janvier 2018
- Au lieu que les abonnés interrogent périodiquement le serveur, l’éditeur signale les nouveaux articles à un hub, qui les transmet immédiatement aux abonnés via webhook
- Il réduit la charge serveur et supprime le délai de mise à jour ; Feedly, NewsBlur et d’autres le prennent en charge
- Microsub est la spécification la plus récente, encore à l’état de brouillon, et sépare les applications de lecture sociale en deux couches
- Le serveur gère les abonnements, la collecte et l’analyse des flux, ainsi que la normalisation des données
- Le client n’affiche que l’interface de lecture, peut rivaliser sur l’UX, et les informations d’abonnement peuvent être déplacées entre clients
- En combinant la publication de réponses via Micropub et les notifications de Webmention, on obtient une architecture de lecteur social IndieWeb complète
POSSE, PESOS et Backfeed
- POSSE est la stratégie recommandée : publier d’abord sur son propre site, puis diffuser à l’extérieur
- Les copies externes incluent un lien vers l’original, afin que les lecteurs puissent continuer à lire sur les plateformes existantes tandis que l’éditeur conserve la copie canonique
- Même si une plateforme ferme ou bloque le compte, l’original reste disponible
- Tantek Çelik a créé le terme en 2012 ; Cory Doctorow et Molly White, entre autres, l’utilisent
- L’effet par lequel des sites de spam recopient aussi le lien vers l’original lorsqu’ils copient un article est appelé « aïkido Internet »
- PESOS est l’approche inverse : publier d’abord dans un silo, puis copier sur son propre site pour archivage
- On peut utiliser des applications de silo abouties et continuer à publier même si son site personnel est indisponible
- Mais le contenu est soumis dès le départ aux conditions du silo, la copie sur le site personnel n’est pas canonique, et elle hérite aussi de contraintes comme les limites de caractères ou les liens
t.co
- Backfeed renvoie vers l’original, via Webmention, les likes, réponses et repartages reçus par les copies externes
- Bridgy observe les copies sur Mastodon, GitHub, Flickr, Reddit et Bluesky, puis envoie une Webmention pour chaque interaction
- Au final, toute la conversation survenue sur les plateformes externes peut être conservée sur le domaine personnel
Relation avec le Fediverse et RSS
- Webmention, Micropub, WebSub et ActivityPub sont tous issus du W3C Social Web Working Group, mais suivent des philosophies différentes
- Le Fediverse fédère des serveurs et représente l’identité sous la forme
@user@instance; si l’on n’exploite pas sa propre instance, on dépend d’un autre opérateur- L’exploitation d’une instance implique un coût élevé de modération et de maintenance, appelé admintax
- L’IndieWeb fédère des sites web et utilise le domaine personnel comme identité ; la fédération est traitée comme un canal de diffusion parmi d’autres
- Bridgy Fed convertit h-card, h-entry et Webmention vers ActivityPub et l’AT Protocol de Bluesky, et inversement
- Un domaine personnel devient un compte Fediverse de la forme
@example.com@example.com - On peut rechercher et suivre ce compte depuis Mastodon, et les réponses reviennent à la publication d’origine via Backfeed
- Un domaine personnel devient un compte Fediverse de la forme
- L’IndieWeb considère que RSS et Atom nécessitent de maintenir une copie XML séparée du HTML, ce qui crée un coût de maintenance et un risque d’incohérence
- Certains fichiers Atom sont jusqu’à 4,5 fois plus volumineux que le HTML correspondant
- L’expérience est également médiocre lorsqu’un humain ouvre directement un lien de flux
- L’alternative h-feed utilise le HTML lui-même comme flux, mais très peu de lecteurs la prennent en charge
- Il est donc recommandé de fournir h-feed pour l’environnement IndieWeb, et RSS/Atom pour les lecteurs ordinaires
Ordre de démarrage
- Getting Started recommande l’ordre suivant
- Obtenir un domaine : l’utiliser comme identité principale en ligne et ne choisir la protection de la confidentialité WHOIS que si l’on fait pleinement confiance au fournisseur
- Configurer l’hébergement : les débutants peuvent utiliser des services managés comme GitHub Pages, Netlify ou Neocities ; les plus expérimentés peuvent s’auto-héberger
- Créer des pages : générateur de site statique, HTML écrit à la main ou CMS, peu importe ; il n’existe pas de technologie officielle
- Appliquer POSSE : diffuser sur d’autres plateformes avec un lien vers l’original
- Ajouter microformats : mettre
rel="me"sur la page d’accueil et h-entry sur les publications - Valider : vérifier progressivement rel-me, h-card et h-entry avec IndieWebify.me
- Participer à la communauté : même s’il ne s’agit que d’une seule page, partager ce que l’on a créé et le documenter sur le wiki pour les prochains utilisateurs
- IndieMark est une échelle de progression destinée aux développeurs qui veulent adopter l’approche étape par étape
Mise en œuvre réelle et fonctionnalités exclues
- Les éléments suivants ont été appliqués au site réel
- Envoi et réception de Webmentions : automatiser la tâche quotidienne qui signale les liens externes dans les nouveaux articles, tout en laissant 24 heures pour corriger d’éventuelles fautes
- Les Webmentions reçues sont utilisées dans la liste de références à la fin de chaque article, séparément des commentaires gérés par e-mail
- h-entry sur tous les articles, h-card sur la page d’accueil, avec validation via mf2py
- Dans le pied de page, Mastodon, GitHub et Org Social sont liés avec
rel="me"afin d’obtenir les badges de vérification
- Les éléments qui ne correspondaient pas aux besoins ni au flux de travail existant ont été écartés
- Micropub·IndieAuth : l’éditeur et Git constituent l’interface de publication, et les articles sont rédigés en Markdown versionné ; aucun endpoint de publication séparé n’est donc nécessaire
- WebSub : comme la publication est volontairement retardée de 24 heures, la diffusion en temps réel ne justifie pas la complexité
- h-feed : le template des cartes d’article est aussi réutilisé ailleurs, par exemple dans des zones de recommandation au sein du corps, ce qui pourrait amener les parseurs à détecter des h-entry ambiguës ; RSS remplit déjà suffisamment ce rôle
Des pratiques qui dureront plus que la technologie
- Le HTML ordinaire est le format le plus durable pour rendre l’intégralité du contenu lisible même sans JavaScript
- Il faut concevoir des URL que l’on peut maintenir durablement, selon le principe « Cool URIs don't change »
- Sur le site réel, les anciennes URL continuent de fonctionner même lorsque le slug d’un article change
- Il n’est pas nécessaire de quitter les silos d’un seul coup : une transition progressive est possible, en publiant d’abord sur son propre site selon les types de contenu
- Il faut aussi envisager une pérennité extrêmement longue
- On peut envisager un « dead man's switch » qui transmet les clés du site à une personne de confiance après sa mort
- Il faut aussi régler la question de savoir qui paiera le domaine une fois l’opérateur disparu
- Exploiter avec plaisir un site personnel imparfait et singulier correspond mieux aux principes de l’IndieWeb qu’un template parfait mais ennuyeux à maintenir
1 commentaires
Avis sur Hacker News
Si l’IndieWeb veut du contenu, l’enfouir sous un empilement technique complexe est exactement l’inverse de ce qu’il faut faire.
Cet ensemble de protocoles est, en pratique, inutilisable pour 90 % des utilisateurs ; si l’on veut privilégier l’expérience de publication, il faut une solution en un clic, utilisable immédiatement.
Dès qu’on exige la ligne de commande, Docker ou l’édition manuelle de HTML/CSS, on crée une barrière que la plupart des gens ne franchiront pas ; en l’état, cela ressemble davantage à NerdNet qu’à IndieWeb.
micro.blog, un point d’entrée emblématique en un clic, propose pour 5 dollars par mois un site personnel avec les fonctionnalités IndieWeb modernes.
La plupart des personnes intéressées aujourd’hui étant des développeurs qui veulent construire elles-mêmes, les articles liés au sujet peuvent paraître très techniques, mais l’arrivée de non-développeurs est aussi un changement souhaité par la communauté. David Shanske développe depuis dix ans des extensions WordPress intégrant des outils IndieWeb par défaut : https://profiles.wordpress.org/dshanske/#content-plugins
Il n’est pas non plus nécessaire d’utiliser toutes les technologies pour faire de l’IndieWeb. On peut commencer par son propre domaine, créer des pages en HTML, Markdown, Django, etc., puis ajouter progressivement les microformats et Webmention ; à n’importe quelle étape, cela peut être considéré comme un site IndieWeb.
Internet était meilleur avant de devenir un Walmart mondial, quand des gens intéressants s’y rassemblaient d’eux-mêmes.
Internet aussi a toujours commencé par des choses difficiles mais amusantes, créées par des geeks, avant de devenir progressivement plus faciles à utiliser pour le grand public. L’IndieWeb en est encore à ses débuts ; s’il survit, la démocratisation suivra naturellement, donc pour l’instant il faut les laisser construire davantage.
Le problème, c’est l’économie. Les solutions en un clic sont utiles, mais l’IndieWeb résout un problème idéologique plutôt qu’un problème urgent pour les utilisateurs, ce qui rend difficile de trouver des clients capables de financer l’investissement ou les coûts d’exploitation du service.
micro.blog est ce qui s’en rapproche le plus, mais c’est un service centralisé qu’on ne peut pas exploiter sur sa propre infrastructure ; il est compatible avec les protocoles, sans être un outil IndieWeb complet.
Il existe des possibilités, comme les journaux d’activité d’agents ou des outils de publication pour capteurs et serveurs, mais sans demande utilisateur réelle, cela semble difficile à transformer en service fini.
Il faut encourager les gens à créer ce qu’ils veulent plutôt qu’à se soumettre à ce qui est populaire. Les métiers du marketing, qui se concentrent sur des stratégies de rente et du lobbying plutôt que sur la création de valeur réelle, rendent la société plus mauvaise et devraient donc être moins nombreux.
La façon de penser de Nostr me semble plus proche de POSSE que Mastodon ou AT Protocol, et je la préfère.
Si je tiens régulièrement un blog, que je possède mon domaine et mes billets, mais que ce ne serait pas de l’IndieWeb parce que j’utilise WordPress, alors on finit de toute façon par dépendre d’entreprises. D’anciens blogs créés avec Blogger sont encore là, presque dix ans plus tard.
Posséder soi-même son serveur n’est pas réaliste. S’il s’agit d’un serveur virtuel, il sera dans le cloud d’Amazon ou de Microsoft ; même avec un serveur physique, il faut le placer dans le datacenter d’une entreprise, et il est difficile de gérer soi-même l’onduleur et une connexion Internet permanente.
Les alternatives existantes se contentent généralement de courir après la nostalgie des années 1990, au point qu’il est difficile d’y voir une utilité au-delà d’un bref moment nostalgique, mais cette approche semble différente.
Elle embrasse le web moderne tout en permettant aux créateurs de contrôler pleinement leur propre espace. Quand j’aurai du temps, j’aimerais faire participer mon blog myzopotamia.dev à l’IndieWeb.
indiekit fournit en réalité par défaut l’ensemble des fonctionnalités IndieWeb. Je l’utilise sur https://rmendes.net et je travaille aussi à l’implémenter dans https://textcaster.app.
Le problème de non-répétition (DRY) des flux RSS me semble exagéré. Quel que soit le framework open source utilisé, je ne me souviens pas avoir eu de problème pour générer automatiquement un flux RSS.
h-entry, devoir gérer deux versions du même contenu plus du XML a souvent été frustrant.RSS a été inventé juste avant la révolution du balisage sémantique qui a suivi la fin des mises en page en tableaux, ce qui était un mauvais timing.
Sur un site qui se revendique IndieWeb, voir un CV de l’auteur, une photo de visage professionnelle, une présentation mettant en avant des parcours dans des institutions prestigieuses et un blog élégant me met mal à l’aise.
C’est un peu comme entrer dans une boutique de vêtements lumineuse d’un centre commercial haut de gamme, où tous les produits portent un symbole anarchiste, puis s’apercevoir de près que les étiquettes de prix frôlent les quatre chiffres.
Un site personnel peut être ce que l’on veut. Le mien devient lui aussi chaque année plus personnel et centré sur mes hobbies depuis que je n’ai plus besoin de chercher un emploi, mais un site reste le produit de la société dans laquelle vit la personne, et il faut aussi gagner sa vie.
La vie professionnelle fait aussi partie de ce qui me constitue, et comme je suis indépendant, on pourrait m’appeler travailleur indépendant ; je ne vois pas en quoi ce serait mauvais.
L’IndieWeb ne rejette pas le professionnalisme ; il considère que le contenu vous appartient et doit survivre aux plateformes. Une photo de visage, un CV et un blog soigné sont acceptables ; ce qui est critiqué, c’est de les enfermer dans une plateforme qui peut fermer, vendre vos données ou disparaître.
Rendre le contenu lisible par les machines sans fichiers parallèles ni API était, à la base, un problème qu’il n’était presque pas nécessaire de résoudre.
Comme les ontologies précédentes, cela ne sert à rien aux visiteurs humains et ne fait que nourrir en données des acteurs hostiles.
Ce serait bien de partager régulièrement d’autres blogs que l’on aime. L’IndieWeb repose sur le bouche-à-oreille et la curation humaine, donc des billets du type « ce que j’ai apprécié ce mois-ci » sont utiles.
Il faut aussi faire des compliments généreux, envoyer des remerciements par e-mail et lancer des conversations. Un site statique sans suivi des utilisateurs peut donner l’impression de parler dans le vide, donc les e-mails de lecteurs sont très encourageants.
Comme il s’agit d’un site personnel, ce n’est pas grave s’il est imparfait ou bizarre, et tout le contenu n’a pas besoin d’être un flux chronologique. On peut organiser son espace comme on le souhaite, à la manière d’un jardin numérique.
Je me demande si tu savais que le domaine
.devest la propriété de Google.