Eine vollständig unabhängige Website für 15 Won pro Tag betreiben

 (neatnik.net)
3 Punkte von GN⁺ 22 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Hardcore IndieWeb ist ein Ansatz, bei dem die Originale der Inhalte sowie veröffentlichbares HTML und Web-Assets auf den eigenen Geräten liegen, statt Identität und Kontrolle über Inhalte einem Dienstanbieter zu überlassen
  • Wer dem Publikationsprozess der 1990er folgt — HTML im Browser vorab ansehen und dann zum Host hochladen — kann eine Website ohne CMS, SSG, Framework, CLI oder monatliches Abo betreiben
  • Benötigt werden nur ein Texteditor, ein SFTP-Tool und ein Webhost; bei NearlyFreeSpeech.net lässt sich eine statische Website für 0,01 US-Dollar pro Tag betreiben und ab 0,25 US-Dollar Guthaben aufladen
  • Landingpage, einzelne Beiträge, Archiv und Atom-Feed werden direkt als Dateien verwaltet; so lassen sich Struktur und Design pro Seite ändern und nur geänderte Dateien übertragen
  • Selbst wenn ein Host verschwindet, kann die fertige Website unverändert anderswo hochgeladen werden; je mehr Tools man hinzufügt, desto mehr Abhängigkeiten entstehen jedoch — lokale Originale und veröffentlichte Versionen sind die Voraussetzung für Unabhängigkeit

Die Unabhängigkeit, die Hardcore IndieWeb verlangt

  • IndieWeb ist ein praktischer Ansatz, um Identität und Inhalte im Web selbst zu besitzen und sich externer Kontrolle durch Unternehmen zu entziehen
  • Auch abonnementbasierte Blog-Dienste können bei der Teilnahme am IndieWeb helfen, doch wenn Inhalte hauptsächlich in der Datenbank und auf den Servern anderer liegen, ist das nicht vollständig unabhängig
    • Selbst wenn sie in offenen Formaten exportiert werden können, hat man während der Nutzung des Dienstes keine vollständige Kontrolle über die Inhalte
    • Der Ansatz eignet sich eher für Menschen, die vollständige Unabhängigkeit und Kontrolle über ihre Inhalte wollen, als für jene, die mit bestehenden Diensten zufrieden sind
  • Hardcore IndieWeb wendet auf bestehende IndieWeb-Prinzipien konkrete Kriterien für Kontrolle und Portabilität an
    • Wenn Inhalte nicht primär auf der eigenen Festplatte liegen, lässt sich schwer von vollständiger Kontrolle sprechen
    • Wenn keine Kopie des veröffentlichten HTML und der Web-Assets auf der Festplatte liegt, ist die Website nicht vollständig portabel
  • Geht ein Dienst pleite und ein Export der Daten ist nicht mehr möglich, kann man trotz nominellem Eigentum an den Inhalten nicht mehr darauf zugreifen oder sie umziehen
  • Will man einen Dienst wegen des Verhaltens des Betreibers verlassen, muss man unter Umständen einen anderen Dienst finden, der das exportierte Format unterstützt, oder Inhalte konvertieren sowie Tools und Abläufe ändern
  • Liegen die Originale der Inhalte und die fertige veröffentlichte Version lokal vor, bleiben auch in solchen Situationen Kontrolle und Portabilität erhalten

Web-Publishing im Stil der 1990er

  • Hardcore IndieWeb folgt der einfachen Publikationsweise aus den frühen Tagen des Webs
    1. Inhalte auf der Festplatte erstellen
    2. Im Webbrowser vorab ansehen
    3. Bei Zufriedenheit zum Webhost hochladen und bei Bedarf wiederholen
  • Neben einer Domain braucht man nur Texteditor, Dateiübertragungstool und Webhost
  • Eine Programmierumgebung oder IDE, ein Framework, eine Shell, CLI-Tools oder ein monatliches Abo sind nicht nötig
  • HTML-Kenntnisse sind erforderlich, lassen sich aber mit Ressourcen wie HTML for People erwerben; mit wenigen Tags und Kopieren und Einfügen kann man bereits loslegen
  • Komplexe SaaS-, CMS-, SSG-, Markup-Sprachen- und Template-Systeme sind optional; die einfache Methode, Dateien direkt zu veröffentlichen, funktioniert weiterhin

Benötigte Tools und Hosting

  • Als Texteditor eignet sich alles, was Dateien auf der Festplatte speichern kann
  • Für die Dateiübertragung braucht man ein Tool mit Unterstützung für SSH oder SFTP
    • FileZilla ist eine Option, die mehrere Betriebssysteme unterstützt
  • Als Host für statische Websites wird NearlyFreeSpeech.net empfohlen; der Betrieb ist für 0,01 US-Dollar pro Tag möglich
    • Adam Newbold nutzt diesen Dienst seit 2008
    • Man kann das Konto ab 0,25 US-Dollar aufladen und eine static, non-production-Website hinzufügen
    • Wählt man im Tab Sites den Namen der Website aus, sieht man die Login-Daten für die Dateiübertragung
    • Eine kostenlose Subdomain wird bereitgestellt; eigene Domains lassen sich im Tab Domains hinzufügen
  • NearlyFreeSpeech ist nicht zwingend; auch andere Webhosts mit einfachem Hosting für statische Dateien kommen infrage

Vorhandene Website und HTML vorbereiten

  • Wenn eine bestehende Website oder ein Blog im HTML-Format vorliegt, ist der Einstieg einfach
  • Wird derzeit ein anderes Format genutzt, kann je nach Dienst nach HTML exportiert oder konvertiert werden
    • Für größere Blogs sind Konvertierungstools meist geeigneter
    • Bei kleineren Blogs kann man die Beiträge noch einmal durchgehen und HTML-Dateien direkt erstellen
  • Markdown mag bevorzugt werden, doch HTML ist die Sprache des Webs; manchmal ist reines HTML einfacher, als sich mit Markdown-Parsern herumzuschlagen
  • Wer nicht von Grund auf designen möchte, kann kostenlose Designs und Templates wie HTML5 UP herunterladen und bearbeiten

Dateien, aus denen ein Blog besteht

  • Ein typischer Blog besteht aus Landingpage, Beiträgen, Archivseite und Feed und lässt sich ohne speziellen Blog-Dienst direkt verwalten

  • Landingpage

    • Man kann den neuesten Beitrag vollständig oder teilweise, mehrere Beiträge oder auch Inhalte, die keine Beiträge sind, frei platzieren
    • Um den neuesten Beitrag anzuzeigen, kopiert man den Inhalt und fügt einen Link zur eigenständigen Seite hinzu
    • Um die letzten fünf Beiträge beizubehalten, fügt man neue Einträge oben ein und entfernt den ältesten unten
    • Ohne die Einschränkungen von CMS, SSG oder Template-Engine lassen sich Struktur und Darstellung auf jeder Seite ändern
    • Die Datei der Landingpage muss index.html heißen und im Web-Root liegen
    • Das Web-Root bei NearlyFreeSpeech ist /home/public

  • Blogbeiträge

    • Ein Beitrag wird als eine Webseite erstellt; man kann die Datei eines früheren Beitrags kopieren und einen eindeutigen Dateinamen sowie neue Inhalte einfügen
    • Die Dateistruktur auf der Festplatte spiegelt sich in der URL wider, daher ordnet man Ordner passend zur gewünschten Adressstruktur an
    • Für den Pfad /blog/ erstellt man im Web-Root einen Ordner blog
    • Slug-basierte Dateinamen wie the-best-lunch-i-ever-had.html sind möglich
    • Legt man in einem eigenen Ordner pro Beitrag eine index.html ab, kann die Erweiterung .html in der URL verborgen werden
    • Verwaltet man Beiträge nicht als Markdown- oder Datenbankeinträge, sondern als eigenständige HTML-Dateien, kann jeder Beitrag einen eigenen Stil, ein eigenes Erscheinungsbild, Layout und Persönlichkeit bekommen
    • Die Konvention, dass alle Beiträge gleich aussehen müssen, stammt von modernen Publikationstools; bei selbst erstelltem HTML muss man ihr nicht folgen

  • Archivseite

    • Man erstellt einen Ordner mit einem Namen wie archive, legt darin eine index.html ab und schreibt eine Liste der Beiträge
    • Sortierung und Aufbau sind frei; Lieblingsbeiträge können auch separat oben auf der Seite hervorgehoben werden

Atom-Feed direkt verwalten

  • Ein RSS-Feed ist kein besonderes System, sondern eine Datei, die auf der Festplatte gespeichert wird und sich mit einem Texteditor direkt bearbeiten lässt
  • Man kann den Beispiel-Feed auf der Atom-Seite von Wikipedia) kopieren und als Datei feed.xml starten
    • Atom ist mit RSS kompatibel und wird breit unterstützt
    • Werte wie example.com, <title> und <subtitle> werden durch die eigene Domain und eigene Informationen ersetzt
    • Für jeden Beitrag im Feed erstellt man einen <entry> und trägt Datum, Uhrzeit, Titel, Zusammenfassung und weitere Angaben ein
    • Für <id> verwendet man eine neue UUID vom UUID Generator
  • Den fertigen Feed kann man in den W3C Feed Validation Service einfügen, um zu prüfen, ob er geparst werden kann
    • Werden Fehler gefunden, zeigt der Validierungsdienst, welche Punkte zu korrigieren sind

Veröffentlichung und Updates

  • Bei der ersten Veröffentlichung verbindet man sich mit einem Dateiübertragungsprogramm mit dem Server und kopiert die gesamte Website zum Webhost
  • Danach müssen nur neu entstandene oder geänderte Dateien übertragen werden
    • Typische Aktualisierungen betreffen Landingpage, neuen Beitrag, Feed und Archivseite
  • Der Veröffentlichungsprozess kann so einfach sein wie das Ziehen lokaler Dateien auf einen Remote-Server

Grenzen von Portabilität und zusätzlichen Tools

  • Da die fertige Website auf dem eigenen Computer liegt, kann sie unverändert zu einem anderen Host hochgeladen werden, falls der bisherige verschwindet
  • Man muss keine schwerwiegenden Sicherheitslücken von Blog-Software oder SSG-Abhängigkeiten verwalten und kontrolliert alle Aspekte der Inhalte selbst
  • Allein durch Beibehalten dieses Ablaufs kann man weiterhin eine vollständig unabhängige Website betreiben
  • Es lassen sich Tools und Abläufe hinzufügen, die den Workflow unterstützen, doch mit jedem zusätzlichen Tool entsteht eine neue Abhängigkeit
  • Wenn die Originale der Inhalte auf dem eigenen Gerät liegen und eine vollständige Kopie der veröffentlichbaren Website vorhanden ist, sind die Bedingungen des Hardcore IndieWeb erfüllt

Autonomie durch direkten Umgang mit HTML

  • Der Kernprozess besteht darin, HTML direkt zu schreiben und auf einen Webserver hochzuladen
  • Die in den vergangenen 30 Jahren hinzugekommenen technischen Schichten, Abläufe und Erwartungshaltungen haben Webarbeit komplizierter gemacht und Kontrolle sowie Unabhängigkeit an andere abgegeben
  • Auch bei Nutzung von IndieWeb-Diensten ist man nicht vollständig unabhängig, wenn die einzige Kopie der gesamten Webpräsenz einem Dienstbetreiber anvertraut wird
  • Hardcore IndieWeb ist nicht für alle, eignet sich aber für Menschen, denen wichtig ist, wer ihre Texte besitzt und wo und in welcher Form sie veröffentlicht werden
  • Der direkte Umgang mit HTML und das Kopieren von Dateien in den eigenen Webhost-Bereich bieten eine unmittelbare, autonome Erfahrung, die wieder an die Freude des frühen Webs anknüpft

Verwandte Beiträge

1 Kommentare

 
GN⁺ 22 시간 전
Meinungen auf Hacker News

  • Ich habe statische Websites kostenlos auf GitHub Pages und Cloudflare Pages gehostet und bin sehr zufrieden damit. Selbst wenn man NearlyFreeSpeech bezahlt, bleibt man letztlich von Hosting durch Dritte abhängig, daher scheint Self-Hosting abgesehen von der technischen Befriedigung keinen großen Mehrwert zu haben
    Wichtig ist, dass man Assets wie HTML und Bilder direkt als einfache Dateien auf der Festplatte verwaltet. Dank Git-Integration gibt es außerdem externe Backups, und wenn ich aus VS Code nach master pushe, ist alles innerhalb von 30 Sekunden veröffentlicht — viel bequemer als früher mit FTP/SFTP

    • GitHub Pages und Cloudflare Pages haben den Vorteil, dass die Website den Betreiber wahrscheinlich überlebt. Beim Self-Hosting kommt es ohne Nachfolgeplanung irgendwann zwangsläufig zu einem Ausfall durch abgelaufene Domain oder gekündigte Karte, während kostenlose Dienste höchstens möglicherweise verschwinden
    • Der Unterschied, dass man bei Bezahlung nicht das Produkt, sondern der Kunde ist, ist ziemlich groß
    • Mein Blog läuft genauso: https://gigatexal.blog

  • NearlyFreeSpeech ist ebenfalls ein guter Dienst, aber nicht vollständig unabhängig. Wenn man ohne eigene Internet-Infrastruktur der Unabhängigkeit möglichst nahe kommen will, kann man eine Website von zu Hause per Port-Forwarding oder als Tor Hidden Service betreiben
    Wenn man in torrc den Port konfiguriert, ist das nicht schwierig, aber Besucher brauchen ebenfalls den Tor Browser, und es ist umständlich zu erklären, dass die Seite im „Dark Web“ liegt. Dass man sie mit eigener Hardware von zu Hause betreiben und die Server-IP verbergen kann, ist interessant, und es überrascht, dass das in der unabhängigen Webszene nicht weiter verbreitet ist. Man kann auch eine normale Domain auf eine .onion-Adresse umleiten
    Beaker Browser, mit dem man Websites direkt im Browser erstellen und hosten konnte, wurde eingestellt, aber Werkzeuge wie ein Site-Baukasten-Plugin für Tor könnten die Verbreitung fördern

    • .onion-Dienste lassen sich einfach starten, sind sicherer als das normale Web und laufen sogar auf dem Smartphone
      Nanogram: 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
    • Der Tor Browser unterstützt Onion-Location und Alt-Svc, damit .onion-Adressen aus dem normalen Internet entdeckt werden können. Onion-Location kündigt einen Onion-Service über eine normale HTTPS-Website an, und Alt-Svc entdeckt und wechselt automatisch ohne zusätzliche Nutzeraktion
      Künftig könnten auch Onion-Verbindungen auf Basis von DNS oder DNSSEC möglich sein: https://onionservices.torproject.org/research/proposals/usab...
    • Perfektion ist der Feind des Guten. In einer Realität, in der man auch von Providern und Hardware-Herstellern abhängt, ist NearlyFreeSpeech ein risikoarmer Kompromiss, hat das Vertrauen der Nutzer nicht missbraucht, und die Kosten sind praktisch vernachlässigbar
    • Tor ist kein Browser, sondern ein Dienst. Der Tor Browser ist nur ein Komfortpaket aus datenschutzorientiertem Browser und Tor-Dienst, daher kann man Tor-Sites auch auf einem Headless-Server ohne Browser betreiben
    • Hidden Services sind selten, weil sie Besuchern zu viel Aufwand abverlangen. Zwischen myfirstnamelastname.com weiterzugeben und eine zufällige 56-stellige .onion-Adresse zu vermitteln und zusätzlich noch den Tor Browser auf dem Handy installieren zu lassen, liegt ein großer Unterschied in der Zugänglichkeit

  • Das größte Hindernis in diesem Zusammenhang ist der Domainname, den man für den Besitz von Inhalten braucht; selbst günstig kostet er etwa 6 Dollar im Jahr. Statische Sites lassen sich an unzähligen Orten kostenlos hosten, und für Privatpersonen reicht die kostenlose CDN-Stufe aus
    Wichtiger als Self-Hosting des Servers ist es, den Domainnamen als eindeutigen Identifikator zu besitzen; wohin diese Domain zeigt, ist deutlich weniger wichtig

    • Software Engineering wurde von klugen Leuten vorangetrieben, die Dinge nicht aus Notwendigkeit, sondern aus Neugier ausprobierten. Beim Einstellen habe ich Neugier und Tatkraft immer höher gewichtet als Abschlüsse
    • 6 Dollar im Jahr sind etwa 0,016 Dollar pro Tag — teurer, aber immer noch günstig
    • Ich weiß gar nicht, an welcher Stelle der Artikel eigentlich vorgeschlagen hat, den Server selbst zu hosten

  • Es ist komisch, dass das Hochladen eigener Dateien auf einen Webserver behandelt wird, als wäre es ein neues Konzept

    • Wir leben in einer Zeit, in der viele Menschen nicht einmal wissen, was eine Datei ist, daher ist es wichtig, diesen Geist weiterzutragen
    • Es ist bedauerlich, dass sich das gesamte Internet in ein Monster verwandelt hat, das von einigen wenigen Großunternehmen gehostet und kontrolliert wird, sodass sogar ein neues Konzept namens IndieWeb nötig wurde. Dateihosting sollte kein Privileg sein, sondern von Anfang an eher einem Menschenrecht nahekommen
      Die Technik fürs Self-Hosting existiert weiterhin, aber die Denkweise hat sich vollständig in Richtung Cloud verschoben
    • Früher musste man nur Dateien in den Ordner public_html legen, und schon hatte man sofort eine persönliche Website. Das heißt nicht, dass man HTML weiterhin von Hand schreiben muss, aber damals war das ein schneller und natürlicher Weg, am Web teilzunehmen
      Unix-Konten boten mit finger sogar die Möglichkeit zu sehen, ob Freunde eingeloggt waren, und mit talk oder ytalk Chats von Person zu Person — selbst wenn der Freund am Terminal nebenan saß, fühlte es sich magisch an
    • Ich hoffe, Kinder lernen irgendwann wieder Hardware kennen

  • Wenn NearlyFreeSpeech für 0,01 Dollar pro Tag eine „100 % unabhängige Betriebsweise“ sein soll, wirkt es nicht groß anders als statisches Hosting bei Vercel, Netlify, GitHub oder Cloudflare.
    Im Artikel steht nicht, wie man mit Datenbanken, Feedback-Formularen, Social-Media-Vorschauen oder Suchmaschinenoptimierung umgeht; vielleicht gehört gerade dieses Fehlen zu den Bedingungen eines „unabhängigen Webs“.

    • Bei NearlyFreeSpeech kann man PHP und Datenbanken nutzen.
    • Wenn es zwischen NFS und Vercel keinen großen Unterschied gibt, müsste die Nutzung eigentlich halbwegs gleich verteilt sein; ich frage mich, warum sich die meisten trotzdem für Vercel entscheiden.
    • NFS bietet eine vollständige Linux-Umgebung mit installierten Programmiersprachen und unterstützt damit auch dynamische Websites, kostet dann aber mehr.
    • Es gab sogar jemanden, der im kostenlosen Tarif eine Netlify-Rechnung über 100.000 Dollar bekommen hat.

  • Ich brauchte eine Domain für eine Event-Website, und Infomaniak bot zusammen mit der Domain auch 10 MB Speicherplatz an. Für etwa 5 Euro pro Jahr bekommt man damit Domain und Website zusammen, was nicht schlecht ist.

  • Ich habe ein JavaScript-Plugin für Kommentare gebaut, das alle Daten im Git-Repository speichert: https://github.com/est/req4cmt. Wenn der Git-Dienst HTTP unterstützt, kann man es nutzen; es läuft auf einem kostenlosen Cloudflare Worker, und Backup sowie Migration sind mit git clone und push erledigt.
    Es gibt auch ein Git-basiertes Twitter-Alternativprojekt: https://github.com/est/gitweets
    Die Demo ist unter https://f.est.im/ zu sehen und unterstützt auch Kommentare mit Git notes. Dank Cloudflare Workers und GitHub Pages ist alles komplett kostenlos.

  • sdf.org ist nützlich für Entwickler, die Unix-Systeme direkt lernen wollen. Es bietet kostenlose Shell-Accounts auf NetBSD Unix, und soweit ich mich erinnere, konnte man mit einer kleinen einmaligen Spende Webspace und zusätzliche Funktionen nutzen.
    Da der Login-Name zur Subdomain des Webspaces wird, sollte man ihn sorgfältig wählen.

  • Ich finde es gut, dass eine Website mit solchen Aussagen nicht auf Cloudflare oder GitHub Pages gehostet wird.

    • GitHub Pages ist kostenloses Hosting mit Domain und SSL, ohne nachträgliche Abrechnung, und die langfristige Perspektive ist gut. Wenn man sich um eine statische Website nicht kümmern möchte, scheinen große Anbieter wie GitHub und Cloudflare am besten geeignet.
    • Ich empfehle oft GitHub Pages, habe aber auch beschrieben, wie man auf einem Raspberry Pi im Schlafzimmer hostet: https://joeldare.com/private-analytics-and-my-raspberry-pi-4...
    • Dass Cloudflare Piratenseiten weiterhin online hält, weiß ich zu schätzen.
    • Für Vercel oder Netlify gilt dasselbe.

  • Ich bevorzuge es, eher den Prozess zu lernen und zu besitzen als ein bestimmtes Tool. Man kann HTML mit Tools wie Pandoc aus leicht lesbaren und schreibbaren Formaten wie Markdown erzeugen, lernen, HTML, CSS und JavaScript zu einem Hosting-Dienst hochzuladen oder zu synchronisieren, eine Domain zu besitzen und DNS mit GitHub Pages oder Cloudflare Pages zu verbinden.
    So ist man nicht an ein bestimmtes Tool, einen Dienst, eine Plattform oder eine Firma gebunden und kann die Inhaltsdateien jederzeit woandershin umziehen. Der Prozess, ursprüngliches Markdown in HTML umzuwandeln, lässt sich mit einem Static Site Generator automatisieren.
    HTML zu können ist nützlich und macht Spaß, muss aber keine Voraussetzung dafür sein, eine Website „100 % unabhängig“ zu betreiben. Man kann für 0 Dollar im Monat auf GitHub und Cloudflare laufen und bei Einstellung des Dienstes oder einer Umstellung auf Bezahlmodelle einfach umziehen.

    • Der Kern des Artikels ist, dass man jedem Beitrag einen eigenen Stil, ein eigenes Aussehen, Layout und eine eigene Persönlichkeit geben kann, wenn man Posts nicht als Markdown oder Datenbankeinträge, sondern als einzelne HTML-Dateien hält. So kann man aus der uniformen Blog-Schablone moderner Publishing-Tools ausbrechen und jeden Beitrag anders gestalten.
    • HTML ist ein für Menschen gut lesbares und schreibbares Format. Schon bevor geeignete Tools aufkamen, arbeiteten nicht nur Informatikstudierende, sondern auch andere direkt mit HTML, JavaScript und CSS im Texteditor; für einfache Websites ist das nicht schwierig.
      Wer den Prozess besitzen und vollständig unabhängig sein will, muss Websprachen selbst verstehen und handhaben können. Static Site Generatoren wie Nikola sind praktisch, aber wenn man die Ausgabe nicht versteht oder nicht direkt ändern kann, bleibt man letztlich trotzdem von einem Drittanbieter-Tool abhängig.