- Hardcore IndieWeb consiste à conserver les originaux de ses contenus ainsi que le HTML publiable et les ressources web sur ses propres appareils, afin de ne pas confier son identité ni le contrôle de ses contenus à un fournisseur de service
- En suivant le processus de publication façon années 1990 — prévisualiser le HTML dans un navigateur puis l’envoyer vers un hébergeur — on peut exploiter un site sans CMS, SSG, framework, CLI ni abonnement mensuel
- Il suffit d’un éditeur de texte, d’un outil SFTP et d’un hébergeur web ; sur NearlyFreeSpeech.net, un site statique peut être exploité pour 0,01 $ par jour, avec un rechargement possible à partir de 0,25 $
- On peut gérer directement sous forme de fichiers la page d’accueil, les articles individuels, les archives et le flux Atom, modifier la structure et le design page par page, et ne transférer que les fichiers modifiés
- Même si l’hébergeur disparaît, le site finalisé peut être remis en ligne tel quel ailleurs ; mais plus on ajoute d’outils, plus les dépendances augmentent, et conserver les originaux locaux ainsi que la version publiée est la condition pour préserver son indépendance
L’indépendance exigée par Hardcore IndieWeb
- IndieWeb est une approche pratique visant à posséder directement son identité et ses contenus sur le web, en s’affranchissant du contrôle externe des entreprises
- Un service de blog par abonnement peut aussi aider à participer à l’IndieWeb, mais si les contenus résident principalement dans la base de données et sur les serveurs d’un tiers, l’indépendance n’est pas totale
- Même s’il est possible d’exporter dans un format ouvert, on ne contrôle pas entièrement ses contenus tant que l’on utilise le service
- Cette approche convient davantage aux personnes qui veulent une indépendance et un contrôle complets sur leurs contenus qu’à celles qui sont satisfaites des services existants
- Hardcore IndieWeb applique aux principes existants de l’IndieWeb des critères concrets de contrôle et de portabilité
- Si les contenus ne se trouvent pas principalement sur son propre disque dur, il est difficile de dire qu’on les contrôle entièrement
- Si l’on ne possède pas sur son disque dur une copie du HTML publié et des ressources web, le site n’est pas dans un état pleinement portable
- Si un service ferme et qu’il devient impossible d’exporter les données, une propriété théorique des contenus ne suffit pas à y accéder ni à les transférer
- Même si l’on veut quitter un service à cause des actions de son exploitant, il peut être nécessaire de trouver un autre service prenant en charge le format exporté, ou de convertir les contenus et de changer d’outils et de procédures
- En disposant localement des originaux des contenus et de la version publiée finalisée, on peut préserver contrôle et portabilité même dans ces situations
Processus de publication web façon années 1990
- Hardcore IndieWeb suit la méthode de publication simple des débuts du web
- Rédiger le contenu sur son disque dur
- Le prévisualiser dans un navigateur web
- Quand le résultat convient, l’envoyer vers l’hébergeur web, puis répéter au besoin
- En dehors du domaine, les seuls éléments nécessaires sont un éditeur de texte, un outil de transfert de fichiers et un hébergeur web
- Aucun environnement de programmation, IDE, framework, shell, outil CLI ni abonnement mensuel n’est nécessaire
- Des connaissances en HTML sont nécessaires, mais elles peuvent s’acquérir avec des ressources comme HTML for People, et il est possible de commencer avec quelques balises et du copier-coller
- Les SaaS, CMS, SSG, langages de balisage et systèmes de templates complexes sont optionnels ; la méthode simple consistant à publier directement des fichiers fonctionne toujours
Outils nécessaires et hébergement
- N’importe quel éditeur de texte peut convenir s’il peut enregistrer des fichiers sur le disque
- Adam Newbold utilise Nova, qui prend aussi en charge le transfert de fichiers
- On peut trouver d’autres options dans la liste des éditeurs de texte
- Pour le transfert de fichiers, il faut un outil prenant en charge SSH ou SFTP
- FileZilla est une option compatible avec plusieurs systèmes d’exploitation
- Comme hébergeur de site statique, NearlyFreeSpeech.net est recommandé ; il permet une exploitation pour 0,01 $ par jour
- Adam Newbold utilise ce service depuis 2008
- Il est possible de créditer son compte à partir de 0,25 $ et d’ajouter un site
static, non-production - Dans l’onglet
Sites, sélectionner le nom du site permet de consulter les informations de connexion pour le transfert de fichiers - Un sous-domaine gratuit est fourni, et un domaine personnel peut être ajouté dans l’onglet
Domains
- NearlyFreeSpeech n’est pas indispensable ; tout autre hébergeur web proposant un hébergement de fichiers statiques de base peut aussi convenir
Préparer un site existant et le HTML
- Si un site ou blog existant est au format HTML, il est facile de commencer directement
- S’il fonctionne dans un autre format, selon le service, il peut être possible de l’exporter ou de le convertir en HTML
- Pour un blog volumineux, il est préférable d’utiliser un outil de conversion
- Pour un petit site, on peut relire les articles et créer directement les fichiers HTML
- On peut préférer Markdown, mais HTML est le langage du web, et il est parfois plus simple de travailler en HTML pur que de lutter avec un parseur Markdown
- S’il est difficile de concevoir un design depuis zéro, on peut télécharger et modifier des designs et templates gratuits comme ceux de HTML5 UP
Les fichiers qui composent un blog
- Un blog classique se compose d’une page d’accueil, d’articles, de pages d’archives et d’un flux, que l’on peut gérer directement sans service de blog dédié
-
Page d’accueil
- On peut y placer librement l’intégralité ou une partie des derniers articles, plusieurs articles, ou du contenu qui n’est pas un article
- Pour afficher un article récent, il suffit d’en copier le contenu et d’ajouter un lien vers sa page indépendante
- Pour conserver les 5 articles les plus récents, coller le nouvel article en haut et supprimer le plus ancien en bas
- Sans les contraintes d’un CMS, d’un SSG ou d’un moteur de templates, on peut modifier la structure et la présentation de chaque page
- Le fichier de la page d’accueil doit s’appeler
index.htmlet être placé à la racine web - La racine web de NearlyFreeSpeech est
/home/public
-
Articles de blog
- Chaque article devient une page web ; on peut le rédiger en copiant le fichier d’un article précédent, puis en lui donnant un nom de fichier unique et un nouveau contenu
- La structure des fichiers sur le disque se reflétant dans les URL, il faut organiser les dossiers selon le schéma d’adresses souhaité
- Pour utiliser le chemin
/blog/, créer un dossierblogà la racine web - On peut utiliser des noms de fichiers fondés sur un slug, comme
the-best-lunch-i-ever-had.html - En plaçant un
index.htmldans le dossier propre à un article, on peut masquer l’extension.htmldans l’URL - Gérer les articles comme des fichiers HTML indépendants, plutôt que comme du Markdown ou des entrées de base de données, permet de leur donner à chacun un style, une apparence, une mise en page et une personnalité différents
- L’habitude voulant que tous les articles aient le même aspect vient des outils de publication modernes ; avec du HTML fait à la main, il n’est pas nécessaire de la suivre
-
Pages d’archives
- Créer un dossier portant un nom comme
archive, y placer unindex.html, puis rédiger la liste des articles - Le tri et l’organisation sont libres, et il est aussi possible de mettre en avant certains articles préférés en haut de la page
- Créer un dossier portant un nom comme
Gérer directement un flux Atom
- Un flux RSS n’est pas un système spécial, mais un fichier enregistré sur le disque ; il peut donc être modifié directement avec un éditeur de texte
- On peut copier l’exemple de flux figurant sur la page Atom de Wikipédia) et démarrer avec un fichier
feed.xml- Atom est compatible avec RSS et largement pris en charge
- Remplacer
example.com,<title>,<subtitle>et autres valeurs par son propre domaine et ses propres informations - Créer un
<entry>pour chaque article à inclure dans le flux, puis renseigner la date, l’heure, le titre, le résumé, etc. - Pour
<id>, utiliser un nouvel UUID obtenu via UUID Generator
- Le flux finalisé peut être collé dans le W3C Feed Validation Service afin de vérifier qu’il peut être parsé
- Si des erreurs sont trouvées, le service de validation indique les éléments à corriger
Publication et mises à jour
- Lors de la première publication, se connecter au serveur avec un programme de transfert de fichiers et copier l’ensemble du site vers l’hébergeur web
- Ensuite, il suffit de transférer uniquement les fichiers nouveaux ou modifiés
- Les éléments généralement mis à jour sont la page d’accueil, le nouvel article, le flux et la page d’archives
- Le processus de publication peut se résumer à glisser-déposer des fichiers locaux vers le serveur distant
Portabilité et limites des outils supplémentaires
- Comme le site finalisé se trouve sur son propre ordinateur, si l’hébergeur existant disparaît, il peut être téléversé tel quel chez un autre hébergeur
- Il n’est pas nécessaire de gérer une faille de sécurité majeure dans un logiciel de blog ni des dépendances liées à un SSG, et l’on peut contrôler directement tous les aspects de ses contenus
- Conserver ce processus tel quel suffit à continuer d’exploiter un site web totalement indépendant
- On peut ajouter des outils et des procédures pour faciliter le flux de travail, mais chaque outil ajouté crée aussi une nouvelle dépendance
- Si les originaux des contenus se trouvent sur ses propres appareils et que l’on possède une copie complète du site publiable, les conditions de Hardcore IndieWeb sont remplies
L’autonomie de manipuler directement le HTML
- Le processus essentiel consiste à écrire directement du HTML et à l’envoyer sur un serveur web
- Les couches technologiques, procédures et niveaux d’attente ajoutés au cours des 30 dernières années ont complexifié le travail web et conduit à déléguer le contrôle et l’indépendance à d’autres
- Même en utilisant des services IndieWeb, si l’on confie à leur exploitant l’unique copie de toute sa présence web, on n’est pas totalement indépendant
- Hardcore IndieWeb n’est pas une méthode pour tout le monde, mais elle convient à celles et ceux pour qui il importe de savoir qui détient leurs écrits, où ils sont publiés et sous quelle forme
- Manipuler directement le HTML et copier les fichiers vers son propre espace d’hébergement web offre une expérience directe et autonome qui reconnecte avec le plaisir du web des débuts
1 commentaires
Avis sur Hacker News
J’héberge des sites statiques gratuitement sur GitHub Pages et Cloudflare Pages depuis longtemps, et j’en suis très satisfait. Même en payant NearlyFreeSpeech, on reste dépendant d’un hébergement tiers, donc l’auto-hébergement ne semble pas apporter beaucoup de valeur au-delà de la satisfaction technique
L’important, c’est de gérer directement des ressources comme le HTML et les images sous forme de simples fichiers sur disque. Grâce à l’intégration Git, on a aussi des sauvegardes externes, et un push vers
masterdepuis VS Code publie le site en moins de 30 secondes, ce qui est bien plus pratique qu’autrefois avec FTP/SFTPNearlyFreeSpeech est aussi un bon service, mais ce n’est pas complètement indépendant. Pour se rapprocher au plus près de l’indépendance sans disposer de sa propre infrastructure Internet, on peut faire tourner un site depuis chez soi avec du port forwarding ou comme service caché Tor
Configurer les ports dans
torrcn’est pas difficile, mais les visiteurs ont aussi besoin de Tor Browser, et il est compliqué d’expliquer que le site se trouve sur le « dark web ». Pouvoir l’exploiter chez soi sur son propre matériel tout en masquant l’IP du serveur est intéressant, et il est surprenant que ce soit moins répandu dans la sphère du web indépendant. On peut aussi rediriger un domaine classique vers une adresse.onionBeaker Browser, qui permettait de créer et d’héberger des sites directement dans le navigateur, a disparu, mais des outils comme un plugin de création de sites pour Tor pourraient aider à la diffusion
.onionsont simples à lancer, plus sûrs que le web classique, et peuvent même tourner sur un téléphoneNanogram: https://gitlab.com/here_forawhile/nanogram
Spreadsheet Server: https://gitlab.com/here_forawhile/spreadsheet
Library Server: https://gitlab.com/here_forawhile/libraryserver
Torum: https://gitlab.com/here_forawhile/torum
.oniondepuis l’Internet classique. Onion-Location permet à un site HTTPS classique d’annoncer son service Onion, et Alt-Svc permet une découverte et une bascule automatiques sans action particulière de l’utilisateurÀ l’avenir, des connexions Onion basées sur DNS ou DNSSEC sont aussi envisageables : https://onionservices.torproject.org/research/proposals/usab...
myfirstnamelastname.comet devoir transmettre une adresse.onionaléatoire de 56 caractères puis faire installer Tor Browser sur un téléphoneDans tout ça, le principal obstacle à la propriété du contenu reste le nom de domaine, qui coûte environ 6 dollars par an, même à bas prix. Un site statique peut être hébergé gratuitement dans d’innombrables endroits, et pour un particulier, les offres gratuites de CDN suffisent largement
Plus important que l’auto-hébergement du serveur lui-même, il y a la possession d’un identifiant unique qu’est le domaine ; l’endroit vers lequel pointe ce domaine compte bien moins
C’est amusant de voir le fait de mettre ses propres fichiers sur un serveur web traité comme un concept nouveau
Les compétences pour s’auto-héberger existent toujours, mais les mentalités sont devenues exclusivement orientées cloud
public_htmlpour avoir immédiatement un site web personnel. Cela ne veut pas dire qu’il faut continuer à écrire du HTML entièrement à la main, mais à l’époque, c’était une manière rapide et naturelle de participer au webUn compte Unix permettait aussi de voir si un ami était connecté avec
fingeret d’avoir des discussions en tête-à-tête avectalkouytalk, et cela semblait magique même quand l’ami était assis au terminal d’à côtéSi NearlyFreeSpeech à 0,01 $ par jour signifie une exploitation 100 % indépendante, cela ne semble pas très différent de l’hébergement statique de Vercel, Netlify, GitHub ou Cloudflare.
L’article n’explique pas quoi faire lorsqu’on a besoin d’une base de données, d’un formulaire de feedback, d’aperçus pour les réseaux sociaux ou de SEO ; peut-être que cette absence fait justement partie des conditions du « web indépendant »
J’avais besoin d’un domaine pour un site d’événement, et Infomaniak fournissait aussi 10 Mo de stockage avec le domaine. Pour environ 5 euros par an, avoir à la fois le domaine et le site n’est pas une mauvaise affaire
J’ai créé un plugin JavaScript de commentaires qui stocke toutes les données dans un dépôt Git : https://github.com/est/req4cmt. Il fonctionne avec n’importe quel service Git prenant en charge HTTP, s’exécute sur un Cloudflare Worker gratuit, et la sauvegarde comme la migration se résument à
git cloneetpushIl existe aussi un projet alternatif à Twitter basé sur Git : https://github.com/est/gitweets
La démo est ici : https://f.est.im/, avec aussi la prise en charge des commentaires via Git notes. Grâce à Cloudflare Workers et GitHub Pages, le tout est entièrement gratuit
sdf.org est utile pour les développeurs qui veulent apprendre Unix directement. Il me semble qu’ils proposent un compte shell gratuit sur NetBSD Unix, et qu’avec un petit don unique on pouvait obtenir de l’espace web et des fonctionnalités supplémentaires
Comme le nom de connexion devient le sous-domaine de l’espace web, il faut le choisir avec soin
Je suis content que les sites qui avancent ce genre d’arguments ne soient pas hébergés sur Cloudflare ou GitHub Pages
Je préfère apprendre et posséder le processus plutôt que dépendre d’un outil particulier. Il suffit d’apprendre à produire du HTML avec des outils comme Pandoc à partir de formats faciles à lire et écrire comme Markdown, puis à téléverser ou synchroniser le HTML, le CSS et le JavaScript vers un service d’hébergement, ainsi qu’à posséder un domaine et à relier le DNS à GitHub Pages ou Cloudflare Pages
Comme on ne dépend d’aucun outil, service, plateforme ou entreprise en particulier, on peut déplacer les fichiers de contenu ailleurs à tout moment. Le processus de conversion du Markdown source en HTML peut être automatisé avec un générateur de site statique
Connaître le HTML est utile et amusant, mais cela n’a pas besoin d’être une condition indispensable pour « exploiter un site de manière 100 % indépendante ». On peut fonctionner pour 0 dollar par mois sur GitHub et Cloudflare, puis migrer ailleurs si le service ferme ou devient payant
Si l’on veut posséder le processus et viser une indépendance totale, il faut pouvoir comprendre et manipuler directement les langages du web. Les générateurs de sites statiques comme Nikola sont pratiques, mais si l’on ne comprend pas leur sortie ou qu’on ne peut pas la modifier soi-même, on reste dépendant d’un outil tiers.