- IndieWeb ist eine Community und eine menschenzentrierte Alternative zum unternehmenszentrierten Web: Inhalte, Identität und Gespräche bleiben auf der eigenen Domain erhalten und können bei Bedarf mit sozialen Netzwerken verbunden werden
- Auf Basis der eigenen Domain kombiniert es kleine Standards wie microformats2,
rel="me", Webmention, IndieAuth und Micropub, damit HTML maschinenlesbar wird und Authentifizierung, Veröffentlichung und Gespräche zwischen Websites unterstützt werden - 23 Millionen Seiten von GeoCities und mehr als 50 Millionen Songs von MySpace sind verschwunden; auch eine Pew-Research-Studie von 2024 zeigte, dass 38 % der 2013 existierenden Webseiten 10 Jahre später nicht mehr erreichbar waren
- POSSE veröffentlicht das Original zuerst auf der eigenen Website und verteilt es dann auf externe Plattformen; Backfeed bringt externe Likes, Antworten und Reposts per Webmention zum Original zurück, sodass das gesamte Gespräch auf der persönlichen Domain erhalten bleibt
- Auf der tatsächlichen Website wurden Webmention, h-entry, h-card und
rel="me"eingesetzt, Micropub, IndieAuth und WebSub jedoch weggelassen, weil sie nicht zum bestehenden Git-/Markdown-Workflow oder zur 24-stündigen Veröffentlichungsverzögerung passen; sinnvoller ist es, zuerst die wirklich benötigte Technik schrittweise einzuführen statt alle Spezifikationen auf einmal
Das Web, auf das IndieWeb abzielt
- IndieWeb bezeichnet sich selbst als „menschenzentrierte Alternative zum Unternehmens-Web“ und ist eher ein ideelles Fundament, das verschiedene Ansätze und Projekte aufnimmt, als eine bestimmte Software oder ein bestimmtes Framework
- 2010 nahmen Aaron Parecki und Tantek Çelik am Federated Social Web Summit in Portland teil und kamen zu dem Schluss, dass es statt Protokollen einen stärker schöpferzentrierten Ansatz braucht
- 2011 fand in Portland das erste IndieWebCamp statt; seitdem wird es jedes Jahr an verschiedenen Orten weltweit veranstaltet
- Beim Homebrew Website Club treffen sich Teilnehmer, um ihre persönlichen Websites zu verbessern
- Die drei Säulen des IndieWeb sind:
- Eigentum an Inhalten: Ins Web gestellte Inhalte sollten dem Veröffentlichenden gehören, nicht einem Unternehmen
- Bessere Vernetzung: Beiträge sollten auf mehrere Plattformen verteilt werden können, und externe Antworten und Likes sollten sich zurück auf die eigene Website holen lassen
- Kontrolle: Man sollte im gewünschten Format veröffentlichen und lesen können und dauerhafte URLs behalten
- Die Nutzung sozialer Netzwerke wird nicht grundsätzlich abgelehnt, wohl aber geschlossene Ökosysteme, die Inhalte und Interaktionen einsperren
Silos und das Verschwinden von Webinhalten
- Ein Silo ist im Allgemeinen eine zentralisierte Website, die meist von einem gewinnorientierten Unternehmen betrieben wird und Rechte an nutzergenerierten Inhalten beansprucht oder den Zugang einschränkt
- Für die Teilnahme ist ein dienstspezifisches Konto nötig
- Interaktionen sind oft nur zwischen Konten desselben Dienstes möglich
- Hinzu kommen teils restriktive Nutzungsbedingungen, Anforderungen an Inhaltslizenzen, blockierte Suchindexierung und Hürden beim Import/Export
- Wenn ein Silo eingestellt wird, können auch die Inhalte seiner Nutzer verschwinden
- GeoCities verschwand am 26. Oktober 2009 mit der Abschaltung durch Yahoo; dabei gingen 23 Millionen Seiten verloren
- MySpace verlor 2019 während einer Servermigration mehr als 50 Millionen Songs, die 14 Millionen Künstler in den ersten 12 Jahren hochgeladen hatten
- Google+ wurde im April 2019 eingestellt
- Auch Posterous, FriendFeed, Vine, Yahoo Groups, TinyLetter und Cohost stehen auf der Liste eingestellter Dienste
- Selbst wenn Silos nicht schließen, können Webinhalte verschwinden
- Laut einer Pew-Research-Studie von 2024 waren 38 % der 2013 vorhandenen Webseiten 10 Jahre später nicht mehr erreichbar
- Das Gegenprinzip besteht nicht darin, soziale Netzwerke gar nicht zu nutzen, sondern die kanonische Version der Inhalte auf einer selbst kontrollierten Domain zu halten
Die 11 Prinzipien der Community
- Die 11 Prinzipien sind keine Prioritätenliste und auch keine Pflicht, die vollständig erfüllt werden muss
- Eigentum an Daten: Inhalte, Metadaten und Identität liegen auf der eigenen Domain, und der langfristige Zugriff bleibt erhalten
- Sichtbare Daten verwenden und veröffentlichen: Erst an Menschen denken, dann an Maschinen; wenn sich Daten in HTML unterbringen lassen, braucht es keine separate API
- Baue, was du selbst brauchst: Werkzeuge für reale eigene Bedürfnisse bauen, nicht für hypothetische Nutzer, deren Existenz unklar ist
- Selbst benutzen: Das Gebaute täglich verwenden und prüfen, ob es verlässlich genug ist
- Dokumentation: Prozesse, Ideen und Code auf der eigenen Website festhalten, um anderen und dem zukünftigen Ich zu helfen
- Open Source: Keine Pflicht, aber hilfreich, damit andere schneller am unabhängigen Web teilnehmen können
- UX vor Protokoll: Erst die Nutzererfahrung festlegen und dann nur die einfachsten und kleinsten Protokolle verwenden, die sie unterstützen
- Modularität: Kleine, lose gekoppelte Komponenten bauen, damit nichts an ein bestimmtes Gerät, eine Sprache oder Plattform gebunden ist
- Langfristige Beständigkeit: Webtechnik schaffen, bei der bisherige Arbeit nicht alle paar Jahre wegen „Fortschritt“ verworfen werden muss
- Pluralismus: Bewusst verschiedene Ansätze fördern, um eine widerstandsfähigere Community statt einer einheitlichen Technikkultur zu schaffen
- Freude: Persönlichen Ausdruck bewahren, der wie das Web der 1990er seltsam und interessant sein darf
Die technische Struktur, die bei der eigenen Domain beginnt
- Die eigene Domain als primäre Online-Identität zu verwenden, ist die Grundvoraussetzung für alles Weitere
- Selbst wenn Hosting oder CMS wechseln, bleiben mit der Domain Links, Leser und Suchranking erhalten
- Sie ist auch die Mindestbedingung, die die Community als Teilnahme am IndieWeb anerkennt
- Statt einer einzelnen Plattform setzt IndieWeb auf kleine, kombinierbare Spezifikationen; das offizielle Spezifikationsverzeichnis ordnet sie nach Implementierungsgeschichte und Verbreitung
microformats2: HTML als API verwenden
- microformats2 macht Inhalte maschinenlesbar, indem vorhandenes HTML mit CSS-Klassen ergänzt wird, ganz ohne separate Dateien oder APIs
h-*: Wurzelobjektp-*: Klartextu-*: URLdt-*: Datume-*: eingebettetes HTML
- h-card repräsentiert persönliche Identität wie Name, URL und Foto und ermöglicht Anwendungen, Profile neben Beiträgen anzuzeigen und Nutzer zu erkennen
- Anders als das E-Mail-basierte Gravatar funktioniert es auf Domain-Basis
- h-entry markiert Titel, Autor, Veröffentlichungsdatum und Inhalt eines Beitrags und ist der zentrale Baustein von IndieWeb-Inhalten
- h-feed bündelt mehrere h-entrys und macht eine HTML-Listenseite selbst zu einem abonnierbaren Feed
- Zum Lesen werden microformats verwendet, zum Schreiben Micropub; so entsteht eine Struktur, in der „die Website selbst die API ist“
rel="me" und verteilte Identitätsbestätigung
rel="me"erklärt, dass das Linkziel dieselbe Person repräsentiert wie die aktuelle Seite- Wenn Website und externes Profil sich gegenseitig per
rel="me"verlinken, wird gegenseitige Identitätsbestätigung ohne zentrale Instanz möglich- Mastodon nutzt diese Struktur für den grünen Verifizierungsindikator auf Domains
- Auch Threads, PixelFed, GitHub, Keybase und Wikipedia unterstützen sie
- RelMeAuth delegiert den Identitätsnachweis an einen OAuth-Anbieter wie GitHub, der auf der Startseite verlinkt ist, und ermöglicht die Anmeldung bei Diensten mit einer persönlichen URL
- Es ist die Grundlage für Dienste wie IndieLogin
Webmention: Gespräche zwischen Websites
- Webmention ist seit dem 12. Januar 2017 eine W3C Recommendation und ermöglicht als Nachfolger von Pingback das Übermitteln von Kommentaren, Likes, Antworten und Reposts zwischen Websites ohne Plattform dazwischen
- Der Ablauf sieht so aus:
- Der sendende Beitrag enthält einen Link zum Zielbeitrag
- Der sendende Server findet den Empfangs-Endpunkt im HTTP-
Link-Header des Zielbeitrags oder im HTML-Element<link rel="webmention"> - Er sendet einen POST-Request, der nur den sendenden Beitrag
sourceund den Zielbeitragtargetenthält - Der empfangende Server lädt
sourceherunter und prüft, ob der Link zutargettatsächlich vorhanden ist - Er analysiert das h-entry von
source, um Antwort, Like oder Repost zu unterscheiden, und zeigt mit h-card den Namen und das Foto des Autors an
- Jede Website wird zu einem Knoten, und die Links zwischen Websites bilden einen Social Graph; Probleme mit Spam und Moderation bleiben jedoch bestehen
- Vouch übergibt als dritten Parameter eine Bürgschafts-Website, die der Empfänger bereits kennt und die auf die sendende Domain verlinkt hat, wodurch die Filterkosten zum Sender verlagert werden
- Salmention sorgt dafür, dass der ursprüngliche Beitrag bei Antworten auf Kommentare aktualisierte Webmentions erneut an Teilnehmer sendet und so Gesprächs-Threads weiterverbreitet
- Für statische Websites ohne Backend kann webmention.io Webmentions stellvertretend empfangen und eine Abfrage-API bereitstellen
- Es lässt sich mit statischen Site-Generatoren wie Hugo, Jekyll und Eleventy nutzen
Domainbasierter Login und Publizieren
- IndieAuth verwendet statt Google- oder Facebook-Konten eine persönliche URL als Login-Identität
- Es basiert auf OAuth 2.0 und identifiziert Nutzer und Anwendungen per URL
- DNS ersetzt die vorherige Client-Registrierung, und PKCE zum Schutz vor Token-Diebstahl ist verpflichtend
- Dienste finden den Authentifizierungsserver über
rel="indieauth-metadata"auf der Benutzerseite und prüfen nach Abschluss der Authentifizierung die Kontrolle über diese URL - Als Authentifizierungsmethoden sind Passwort, E-Mail, RelMeAuth usw. möglich
- Micropub ist seit Mai 2017 eine W3C Recommendation und trennt Website-Software von der Veröffentlichungsoberfläche
- Web-, iOS- und Android-Clients können Beiträge auf der persönlichen Domain erstellen, bearbeiten und löschen
- Statt MetaWeblog und AtomPub, bei denen Passwörter geteilt wurden, nutzt es per IndieAuth erhaltene OAuth-Tokens
- Es definiert kein eigenes Vokabular, sondern serialisiert h-entry-Eigenschaften wie
h=entryundcontentzur Übertragung
Echtzeit-Feeds und entkoppelte Reader
- WebSub hieß früher PubSubHubbub und ist seit Januar 2018 eine W3C Recommendation
- Statt dass Abonnenten den Server regelmäßig abfragen, meldet der Publisher neue Beiträge an einen Hub, der sie per Webhook sofort an Abonnenten ausliefert
- Das reduziert Serverlast und beseitigt Aktualisierungsverzögerungen; unterstützt wird es unter anderem von Feedly und NewsBlur
- Microsub ist die jüngste Spezifikation, befindet sich noch im Entwurfsstadium und trennt Social-Reading-Anwendungen in zwei Schichten
- Der Server übernimmt Abonnementverwaltung, Feed-Sammlung/-Analyse und Datennormalisierung
- Der Client zeigt nur die Leseoberfläche an, kann also über UX konkurrieren, und Abonnementdaten lassen sich zwischen Clients mitnehmen
- Kombiniert man Antwortveröffentlichung per Micropub mit Benachrichtigungen über Webmention, ergibt sich die Struktur eines IndieWeb-Social Readers
POSSE, PESOS und Backfeed
- POSSE ist die empfohlene Strategie, zuerst auf der eigenen Website zu veröffentlichen und dann extern zu verteilen
- Externe Kopien enthalten einen Link zum Original, sodass Leser auf ihren gewohnten Plattformen weiterlesen können, während der Verfasser die kanonische Version behält
- Selbst wenn eine Plattform eingestellt wird oder ein Konto gesperrt wird, bleibt das Original erhalten
- Tantek Çelik prägte den Begriff 2012; verwendet wird er unter anderem von Cory Doctorow und Molly White
- Den Effekt, dass Spam-Seiten beim Kopieren eines Beitrags auch gleich den Link zum Original mitkopieren, nennt man „Internet-Aikido“
- PESOS ist der umgekehrte Ansatz: zuerst im Silo veröffentlichen und dann zur Archivierung auf die eigene Website kopieren
- So lassen sich ausgereifte Silo-Apps nutzen, und man kann auch weiter veröffentlichen, wenn die eigene Website ausfällt
- Allerdings gelten von Anfang an die Bedingungen des Silos; die Kopie auf der eigenen Website ist nicht die kanonische Version und übernimmt Einschränkungen wie Zeichenlimits oder
t.co-Links
- Backfeed bringt Likes, Antworten und Reposts auf externen Kopien per Webmention zurück zum Original
- Bridgy beobachtet Kopien auf Mastodon, GitHub, Flickr, Reddit und Bluesky und sendet bei jeder Interaktion eine Webmention
- So lässt sich letztlich das gesamte Gespräch, das auf externen Plattformen stattfindet, auf der persönlichen Domain archivieren
Verhältnis zum Fediverse und zu RSS
- Webmention, Micropub, WebSub und ActivityPub stammen alle aus der W3C Social Web Working Group, folgen aber unterschiedlichen Philosophien
- Das Fediverse föderiert Server und stellt Identitäten als
@user@instancedar; wer keine eigene Instanz betreibt, ist somit von einem anderen Betreiber abhängig- Der Betrieb einer Instanz bringt hohe Moderations- und Wartungskosten mit sich, die als admintax bezeichnet werden
- IndieWeb föderiert Websites und verwendet die persönliche Domain als Identität; Föderation ist dabei nur einer von mehreren Verbreitungskanälen
- Bridgy Fed wandelt h-card, h-entry und Webmention in ActivityPub und das AT Protocol von Bluesky um und zurück
- Eine persönliche Domain wird so zu einem Fediverse-Konto in der Form
@example.com@example.com - Dieses Konto kann in Mastodon gesucht und abonniert werden; Antworten kehren per Backfeed zum ursprünglichen Beitrag zurück
- Eine persönliche Domain wird so zu einem Fediverse-Konto in der Form
- IndieWeb sieht bei RSS und Atom den Nachteil, dass neben HTML eine separate XML-Kopie gepflegt werden muss, was Wartungskosten und Inkonsistenzen verursachen kann
- Manche Atom-Dateien sind bis zu 4,5-mal größer als die HTML-Seite mit demselben Inhalt
- Auch die Erfahrung ist schlecht, wenn Menschen Feed-Links direkt öffnen
- Die Alternative h-feed verwendet das HTML selbst als Feed, wird aber von sehr wenigen Readern unterstützt
- Daher wird für die IndieWeb-Umgebung h-feed empfohlen, für normale Leser jedoch zusätzlich RSS/Atom
Reihenfolge für den Einstieg
- Getting Started empfiehlt folgende Reihenfolge
- Domain sichern: als primäre Online-Identität verwenden; WHOIS-Datenschutz nur wählen, wenn man dem Anbieter vollständig vertraut
- Hosting einrichten: Einsteiger nutzen verwaltete Dienste wie GitHub Pages, Netlify oder Neocities, Erfahrene hosten selbst
- Seite erstellen: Ob statischer Site-Generator, handgeschriebenes HTML oder CMS, alles ist möglich; es gibt keine offizielle Technik
- POSSE anwenden: auf andere Plattformen mit Link zum Original verteilen
- microformats hinzufügen:
rel="me"auf der Startseite und h-entry in Beiträgen ergänzen - Validieren: mit IndieWebify.me schrittweise rel-me, h-card und h-entry prüfen
- An der Community teilnehmen: Auch mit nur einer Seite das Gebaute teilen und es für den nächsten Nutzer im Wiki dokumentieren
- IndieMark ist ein stufenweiser Leitfaden für Entwickler, die das Thema nach und nach einführen wollen
Praktische Umsetzung und bewusst weggelassene Funktionen
- Auf der tatsächlichen Website wurden folgende Elemente umgesetzt
- Webmention senden und empfangen: Das tägliche Benachrichtigen externer Links in neuen Beiträgen wurde automatisiert, mit 24 Stunden Puffer, damit Tippfehler noch korrigiert werden können
- Empfangene Webmentions werden als Referenzliste am Ende jedes Beitrags genutzt und von per E-Mail verwalteten Kommentaren getrennt
- Für alle Beiträge wurde h-entry, für die Startseite h-card eingesetzt und mit mf2py validiert
- Im Footer wurden Mastodon, GitHub und Org Social per
rel="me"verknüpft, um Verifizierungsindikatoren zu erhalten
- Elemente, die nicht zu den Anforderungen und dem bestehenden Workflow passten, wurden weggelassen
- Micropub·IndieAuth: Da Editor und Git die Veröffentlichungsoberfläche bilden und Beiträge als versioniertes Markdown geschrieben werden, ist kein separater Publishing-Endpunkt nötig
- WebSub: Da Veröffentlichungen absichtlich um 24 Stunden verzögert werden, rechtfertigt Echtzeitübertragung die zusätzliche Komplexität nicht
- h-feed: Das Karten-Template für Beiträge wird auch in Bereichen wie Empfehlungen innerhalb des Inhalts wiederverwendet, sodass Parser dies mehrdeutig als h-entry erkennen könnten; RSS erfüllt diese Rolle ausreichend
Praxisprinzipien, die länger bleiben als Technik
- Normales HTML ist das langlebigste Format, in dem sich der vollständige Inhalt auch ohne JavaScript lesen lässt
- Nach dem Prinzip „Cool URIs don't change“ sollten URLs so entworfen werden, dass sie dauerhaft bestehen können
- Auf der tatsächlichen Website funktionieren bestehende URLs weiter, selbst wenn sich der Slug eines Beitrags ändert
- Man muss Silos nicht auf einmal verlassen; ein schrittweiser Übergang ist möglich, bei dem je nach Inhaltstyp zuerst auf der eigenen Website veröffentlicht wird
- Es lohnt sich, auch an extreme Langfristigkeit zu denken
- Man kann einen „dead man's switch“ erwägen, um die Schlüssel zur Website nach dem Tod einer vertrauenswürdigen Person zu übergeben
- Geklärt werden muss auch, wer die Domainkosten bezahlt, wenn der Betreiber nicht mehr da ist
- Mehr im Sinne des IndieWeb ist es, eine unvollkommene und unverwechselbare persönliche Website mit Freude zu betreiben als ein perfektes, aber im Unterhalt langweiliges Template
1 Kommentare
Hacker-News-Kommentare
Wenn das IndieWeb Inhalte will, ist es genau der falsche Weg, sie unter einem komplexen Technologie-Stack zu vergraben
Dieses Protokollbündel ist für 90 % der Nutzer praktisch unbenutzbar, und wenn man die Content-User-Experience priorisieren will, braucht man eine One-Click-Lösung, mit der man sofort loslegen kann
In dem Moment, in dem man Kommandozeile, Docker oder das direkte Bearbeiten von HTML/CSS verlangt, schafft man eine Hürde, die die meisten nicht überwinden können, und so wie es jetzt aussieht, wirkt es eher wie ein NerdNet als wie ein IndieWeb
Der bekannteste One-Click-Einstiegspunkt, micro.blog, bietet für 5 Dollar im Monat eine persönliche Website mit aktuellen IndieWeb-Funktionen
Derzeit besteht das Interesse größtenteils aus Entwicklern, die selbst etwas aufbauen wollen, deshalb sehen die entsprechenden Beiträge technisch überladen aus, aber die Community wünscht sich auch mehr Zulauf von Nicht-Entwicklern. David Shanske entwickelt seit zehn Jahren WordPress-Plugins, die IndieWeb-Tools standardmäßig bereitstellen: https://profiles.wordpress.org/dshanske/#content-plugins
Man muss auch nicht alle Technologien nutzen, um zum IndieWeb zu gehören. Man kann mit einer eigenen Domain anfangen, Seiten mit HTML, Markdown oder Django erstellen und dann nach und nach Microformats und Webmention hinzufügen; in jedem dieser Schritte kann es bereits als IndieWeb-Site gelten
Das Internet war besser, als es noch ein Ort war, an dem sich interessante Menschen von selbst versammelten, bevor es zu einem globalen Walmart wurde
Auch das Internet hat sich immer aus schrägen, schwierigen, aber spannenden Dingen von Nerds entwickelt und wurde dann nach und nach für normale Menschen einfacher. Das IndieWeb ist ebenfalls noch in einer frühen Phase, und wenn es überlebt, wird die Verbreitung in den Mainstream von selbst folgen, also sollte man die Leute jetzt einfach weiter bauen lassen
Das Problem ist die Wirtschaftlichkeit. Eine One-Click-Lösung ist gut, aber das IndieWeb löst eher ein ideologisches Problem als ein dringendes Problem der Nutzer, daher ist es schwer, Kunden zu finden, die Investitionen oder Betriebskosten eines Dienstes tragen
micro.blog kommt dem am nächsten, ist aber ein zentralisierter Dienst, der nicht auf eigener Infrastruktur betrieben werden kann; trotz Protokollkompatibilität ist es daher kein vollständiges IndieWeb-Tool
Es gibt Möglichkeiten wie Aktivitätsprotokolle für Agenten oder Publishing-Tools für Sensoren und Server, aber ohne konkrete Nutzernachfrage scheint es schwer, daraus einen fertigen Dienst zu machen
Man sollte Menschen eher dazu ermutigen, das zu bauen, was sie wollen, statt sich dem Populären zu unterwerfen. Marketing-Berufe, die sich mehr mit Rent-Seeking-Strategien und Lobbyarbeit beschäftigen als mit echtem Wert, machen die Gesellschaft schlechter und sollten weniger werden
Die Denkweise von Nostr scheint mir näher an POSSE zu sein als Mastodon oder das AT Protocol, deshalb mag ich es lieber
Ich betreibe regelmäßig einen Blog und besitze auch Domain und Beiträge, aber wenn das wegen WordPress nicht als IndieWeb gilt, ist man am Ende trotzdem auf Unternehmen angewiesen. Blogs, die ich früher mit Blogger gemacht habe, stehen seit fast zehn Jahren noch immer unverändert online
Den Server selbst zu besitzen ist nicht realistisch. Bei virtuellen Servern landet man bei Amazon- oder Microsoft-Clouds, und selbst physische Server muss man in Rechenzentren von Unternehmen unterbringen; auch eine USV und eine dauerhafte Internetverbindung selbst zu verwalten, ist schwierig
Frühere Alternativen verfolgten meist nur Nostalgie für die 1990er und boten abgesehen von einem kurzen Nostalgiekick wenig Nutzen, aber dieser Ansatz wirkt anders
Er akzeptiert das moderne Web und gibt Schaffenden trotzdem vollständige Kontrolle über ihren eigenen Raum. Wenn ich Zeit habe, würde ich gern meinen Blog myzopotamia.dev ins IndieWeb bringen
indiekit bringt faktisch das komplette IndieWeb-Feature-Set standardmäßig mit. Ich nutze es auf https://rmendes.net und arbeite daran, es auch bei https://textcaster.app einzubauen
Das DRY-Problem bei RSS-Feeds scheint übertrieben. Ich kann mich nicht erinnern, wann es zuletzt ein Problem war, mit irgendeinem Open-Source-Framework automatisch einen RSS-Feed zu erzeugen
h-entrygibt, musste ich oft frustriert zwei Versionen desselben Inhalts plus XML pflegenRSS wurde direkt vor der semantischen Markup-Revolution erfunden, als tabellenbasierte Layouts gerade zu Ende gingen, also zu einem ungünstigen Zeitpunkt
Wenn ich auf Sites, die sich aufs IndieWeb berufen, Autorenbiografien, professionell gemachte Porträtfotos, Hinweise auf prestigeträchtige Institutionen und polierte Blogs sehe, fühlt sich das unangenehm an
Es ist ein bisschen so, als würde man in einem hell ausgeleuchteten Kleidungsgeschäft in einem gehobenen Einkaufszentrum an jedem Produkt ein Anarchie-Symbol sehen, nur um aus der Nähe festzustellen, dass die Preisschilder fast vierstellig sind
Eine persönliche Website kann alles sein, was man möchte. Auch meine Seite wird, seit ich sie nicht mehr zur Jobsuche brauche, jedes Jahr persönlicher und hobbyorientierter, aber eine Website ist letztlich ein Produkt der Gesellschaft, in der diese Person lebt, und man muss auch seinen Lebensunterhalt verdienen
Mein Berufsleben ist ebenfalls ein Teil von mir, und im Sinne von Selbstständigkeit könnte man mich auch einen unabhängigen Arbeiter nennen; ich sehe nicht, warum das schlecht sein soll
Das IndieWeb lehnt Professionalität nicht ab; es geht davon aus, dass Inhalte einem selbst gehören und Plattformen überdauern sollten. Ein Porträtfoto, ein Lebenslauf und ein polierter Blog sind völlig in Ordnung; kritisiert wird, sie in Plattformen einzusperren, die schließen, Daten verkaufen oder verschwinden können
Inhalte ohne parallele Dateien oder API maschinenlesbar zu machen, war von Anfang an kaum ein Problem, das gelöst werden musste
Wie bei früheren Ontologien nützt das menschlichen Besuchern nichts und füttert nur Akteure, die ihnen gegenüber feindlich eingestellt sind, mit Daten
Es ist gut, regelmäßig andere Blogs zu teilen, die man mag. Das IndieWeb hängt von Mundpropaganda und menschlicher Kuratierung ab, daher sind Beiträge wie „Was ich diesen Monat gern gelesen habe“ nützlich
Man sollte großzügig loben, per E-Mail danken und auch Gespräche anstoßen. Statische Websites ohne Nutzer-Tracking können sich wie ein Monolog anfühlen, deshalb sind Mails von Lesern eine große Motivation
Wie es sich für eine persönliche Website gehört, darf sie unvollkommen und schräg sein, und nicht jeder Inhalt muss ein chronologischer Feed sein. Man kann den Raum wie einen digitalen Garten so gestalten, wie man möchte
Ich frage mich, ob bekannt ist, dass die
.dev-Domain Google gehört