1 Punkte von GN⁺ 2025-08-08 | 1 Kommentare | Auf WhatsApp teilen
  • Ich nutze keine klassischen Kommentarsysteme wie Disqus, Self-Hosting oder GitHub Issues, da sie Probleme wie Geschwindigkeit, Tracking, Wartungsaufwand und Nutzerbeschränkungen mit sich bringen.
  • Bluesky eignet sich für Blog-Kommentare, weil es keine Infrastrukturwartung erfordert, Rich Content unterstützt, konto-basierte Identitäten mit Echtnamensprüfung bereitstellt und plattfomnübergreifende Gespräche ermöglicht.
  • Die Implementierung folgt einem Ablauf: Blogartikel veröffentlichen → in Bluesky teilen → AT-URI zu den Metadaten des Beitrags hinzufügen → den Kommentar-Thread dieses Beitrags abrufen und anzeigen.
  • Die Komponenten sind in drei Teile aufgeteilt: Anzeige aller Kommentare, Anzeige einzelner Kommentare inklusive Antworten und Behandlung von Einbettungen wie Bildern oder Links.
  • Rekursiv werden bis zu 5 Ebenen von Antworten dargestellt; außerdem Bildraster und Modal, Link-Karten und Platzhaltertexte für nicht unterstützte Embeds.
  • Astro + React-Integration, Laden im Client mit client:load, Aktivierung durch Hinzufügen von DID und postCid im Frontmatter.
  • Für Typensicherheit werden die TypeScript-Typen von @atcute/client genutzt; bei deaktiviertem JavaScript bleibt der Inhalt dank Progressive Enhancement korrekt lesbar.
  • Mit Bluesky API und CDN wird ohne eigenen Server oder Datenbank eine gute Performance erreicht.
  • Dieser Ansatz sichert Skalierbarkeit und Unabhängigkeit, indem soziale Funktionen nicht site-spezifisch neu implementiert, sondern mit Plattformen verbunden werden, die die Nutzer bereits nutzen.

Warum ich Bluesky als Kommentarsystem gewählt habe

  • Keine Notwendigkeit für Infrastrukturwartung
  • Unterstützung für reichhaltige Inhalte wie Bilder, Links und zitierte Posts
  • Vertrauenswürdigkeit und Verantwortlichkeit durch Bluesky-Konten
  • Möglicher Traffic-Austausch zwischen Blog und Social-Media
  • Trennung der Inhaltsverantwortung (Blog-Inhalt gehört dir, Kommentare gehören den Autoren)

AT-Protokoll verstehen

  • DID: dezentraler Benutzerbezeichner
  • CID: Inhaltsbezeichner
  • AT URI: Adresse im Format at://did:.../app.bsky.feed.post/...
  • Mit dem API-Aufruf von getPostThread kann der Kommentar-Thread geladen werden, Authentifizierung ist nicht nötig

Komponentenstruktur

  • Hauptkomponente für Kommentare
  • Komponente für die Darstellung einzelner Kommentare und Antworten
  • Komponente für die Verarbeitung von Bild- und Link-Einbettungen

Verarbeitung verschachtelter Antworten

  • Rekursives Rendering mit einer maximalen Tiefe von 5 Ebenen
  • Visuelle Einrückung zur Darstellung der Hierarchie

Verarbeitung von Rich Content

  • Bilder: Bereitstellung über CDN, Bildrasteransicht und Modal
  • Externe Links: Kartenansicht mit Thumbnail und Beschreibung
  • Weitere Einbettungen: Anzeige von Alternativtexten

Astro-Integration

  • Verwendung von React-Komponenten + client:load
  • Aktivierung der Kommentare durch Hinzufügen von Bluesky-DID und postCid zum Frontmatter

Entwicklungserfahrung

  • Mehr Stabilität durch TypeScript-Typunterstützung
  • Bei Ausfall der API bleibt der Inhalt durch Progressive Enhancement unverändert sichtbar
  • Nutzung der Bluesky-Infrastruktur ohne Server- oder Datenbanklast

Fazit

  • Um Probleme klassischer Kommentarsysteme zu vermeiden, wird an die Plattformen angebunden, die Nutzer bereits verwenden
  • Mit dem Wachstum von Bluesky steigt die potenzielle Teilnahme
  • Da die Lösung auf ATProto basiert, ist ein Wechsel zu einer anderen AppView oder eigener Implementierung einfach möglich

1 Kommentare

 
GN⁺ 2025-08-08
Hacker News Kommentar
  • Ich würde mir wünschen, dass offen gelegt wird, wie Bluesky in Zukunft monetarisiert werden könnte. Obwohl alles in eine komplexe technische Architektur gekleidet ist, bin ich neugierig, welches Bezahlmodell am Ende herauskommt.

  • Ich finde den Beitrag spannend; ich lese gerne, wie andere unabhängig eine eigene Website aufbauen und betreiben. Im Artikel werden Probleme mit Kommentarsystemen und vier Alternativen genannt, aber ich möchte sagen, dass auch ein fünfter Weg bei mir funktioniert hat.
    Ich habe mehrere Drittanbieter-Kommentarsysteme ausprobiert und nutze inzwischen ein einfaches eigenes (form.lisp), das ich selbst gebaut habe. Jeder Kommentar wird als Textdatei gespeichert, sodass ich mir weder um Spam, XSS noch um sinnlose Kommentare kümmern muss. Ich prüfe sie jedes Wochenende manuell und ergänze sie dann im Blog.
    Die Kommentare werden als normale HTML-Dateien gespeichert, und ein statischer Site-Generator (site.lisp) erstellt zusammen mit dem Beitrag auch eine Kommentarseite (Kommentarbeispiel); im Grunde agiert er als statischer Kommentargenerator.
    Die fünf im Beitrag genannten Eigenschaften (keine separate Infrastruktur, Rich Content, echter Name usw.) treffen hier zwar nicht zu, aber für mich passt es gut, und ich betreibe es schon seit mindestens vier Jahren mit Zufriedenheit.

    • Auch ein Ansatz, bei dem man Kommentare über ein E-Mail-Formular o. Ä. annimmt und sie anschließend vom Admin manuell am Ende des Beitrags ergänzt, ist ziemlich brauchbar.

    • Für meinen Low-Traffic-Blog finde ich diesen Ansatz auch sehr geeignet. Mir persönlich ist es jedoch unangenehm, fremde Stimmen auf meine eigene Website hereinzulassen, daher habe ich Kommentare komplett entfernt und nutze das Blog nur noch als Raum für meine persönliche Ausdrucksform. Stattdessen hinterlasse ich lieber per E-Mail Feedback bei anderen Bloggern, die mich inspirieren.

    • Es fühlt sich ein bisschen wie „Leserbriefe“ in einer Zeitung an.

  • Meine Empfehlung ist cactus.chat. Es basiert auf Matrix und unterstützt Gäste, sodass man kommentieren kann, ohne ein Matrix-Konto zu benötigen. Wenn man sein eigenes Konto nutzt, ist es so, als würde man je Beitrag an einem Matrix-Raum teilnehmen.

  • Bluesky ist bei der auf Nutzerkonten basierenden Datenspeicherung sehr nützlich; ich entwickle gerade ein Bluesky-basiertes Review-System auf der Open-Source-Webkarte cartes.app. Es ist nicht einfach, man muss ein Lexicon erstellen und die Datenbank entlang des Bluesky-Streams ständig pflegen.

    • Im Grunde kann man auch weitgehend ohne DB auskommen. Bei scrapboard.org, das ich aufgebaut habe, ließ sich schon mit der getRecord-API (Dokumentation) einiges an Client-Daten abrufen.

    • Es wird vorgeschlagen, stattdessen mangrove.reviews zu nutzen. Der Dienst hat eine klare CC-BY-SA-Lizenz und wird auch auf MapComplete.org genutzt; auch Bluesky kann irgendwann Probleme bekommen.

  • Ich bin skeptisch hinsichtlich der Nachhaltigkeit des Bluesky-Monetarisierungsmodells, denn selbst das, was jetzt kostenlos nutzbar ist, basiert de facto auf VC-Finanzierung. Deshalb gehe ich mit der Einführung vorsichtig um, und ich habe die Befürchtung, dass die API bald geschlossen oder das Kommentarsystem ausfallen könnte.

    • Bluesky läuft architektonisch unter dem Personal Data Server (PDS) eines Nutzers. Jeder kann das PDS wechseln, der offizielle Bluesky-App-Server ist dabei nur für Aggregation zuständig.
      Auch über App-Server und App Views, die von Dritten gebaut wurden, kann auf dieselben Daten zugegriffen werden; man muss sich also nicht auf die offizielle API verlassen. In vielen Bereichen ist die Offenheit hier hoch.

    • Ich glaube stark an das Konzept von POSSE. Der positive Aspekt des „Enshitification-Zyklus“ ist, dass man zunächst eine gute Online-Community-Erfahrung haben und später wieder gehen kann. So wie frühere gute Clubs irgendwann verschwunden sind, muss man sich nicht unnötig daran klammern. Eine Zusammenfassung meiner Gedanken findet sich auch in diesem Mastodon-Post: Theorieerklärung

    • Bluesky wird mit Sicherheit zu einem bezahlten Modell wechseln, aber KI- und andere Dienste laufen letztlich ebenfalls in einem VC-getriebenen Modell wie bei Twitter, Uber oder DoorDash. Genau wie dort wird die Atmosphäre langfristig schlechter werden, doch solange VCs Geld in neue Reichtumsphantasien investieren, ist es auch auf einer gewissen Ebene „lustig“, diese Phase der Prosperität auszukosten.

  • Ich finde das Bluesky-Ökosystem wirklich stark; ich habe bereits einmal ein Beispiel für dieses Bluesky-basierte Kommentarsystem gesehen.
    Kleinere Einschränkung: Für jede einzelne Seite muss ein separater Beitrag bei Bluesky gepostet werden, damit das Kommentarsystem funktioniert. Ein Webcomponent wäre hier noch besser.

    • Der Beitrag sagt, man könne „seit Jahren kein ordentliches Kommentarsystem ans Blog hängen“, aber im gesamten Blog sehe ich nur zwei Beiträge aus dem Jahr 2025 (davon ist einer mein aktueller Beitrag).

    • Zur Vorgeschichte habe ich früher auf archive.org gesehen, dass es wohl ein anderes Blog gegeben hat.

  • Der Ansatz ist spannend, weil man mit sozialen Medien interagieren kann, ohne den Social-Media-Feed direkt vor sich zu haben.
    Würde ich diese Funktion auf meinem Blog einbauen, könnten Leute direkt Kommentare hinterlassen, und ich könnte über genau diese Oberfläche mit Bluesky oder anderen sozialen Diensten interagieren.
    Wenn man den Feed öffnet, landet man oft in Doomscrolling und Verschwendung von Zeit; mit diesem Weg habe ich das Gefühl, dass man trotz neuer Möglichkeiten mit sozialen Medien verbunden bleiben kann, ohne diesen Teufelskreis.

    • Ich stimme zu mit der Aussage, dass man im Feed oft nur noch endlos nutzlose Infos sieht; manchmal frage ich mich, ob das nicht genau der ursprüngliche Zweck war.
  • Ich habe das Gefühl, dass Bluesky wieder einmal eine frische Idee in den sozialen Netzdiensten geschaffen hat, in der wieder Neues entstehen kann.

    • Tatsächlich ist es eher eine Integrationsoption, die Threads noch offener macht; vielleicht passt dafür ATProto viel besser als der Begriff „offene Innovation“.

    • Ich will keinem Unternehmen oder einzelnen Kollektiv einen übergroßen Platz einräumen, aber aktuell ist die Bluesky-Community spannend. Ich war früher Fan von Twitter, und viele der Hauptnutzer in Bluesky wirken wie aus derselben Gruppe; was daraus wird, bleibt abzuwarten.

    • Ich glaube fest am Slogan „Protokoll statt Plattform“. Es gibt zwar den Begriff „Build Mode“, aber es geht im Kern darum, etwas zu bauen, das nicht so leicht vereinnahmt oder missbraucht werden kann.

    • Sollten Bluesky-Mitarbeitende oder eine Nutzergruppe provoziert werden oder eine bestimmte Gruppe eine Meldung gegen jemanden erstattet, kann das Konto sofort gebannt werden; oder man landet bereits auf einer vorab geteilten Blacklist und ist damit unsichtbar, noch bevor man etwas sagen kann.
      Grundsätzlich fühlt es sich an wie der Versuch, eine härtere Umgebung als früheres Twitter zu schaffen, inklusive kindischer Machtspielchen wie in einer High-School-Mensa.

  • Wenn ich mein Blog nicht selbst hoste und auf Bluesky aufsetze, liegt es letztlich doch bei Bluesky. Obwohl oft von keinem Plattform-Lock-in gesprochen wird, frage ich mich, was passiert, wenn mein Konto bei Bluesky morgen blockiert wird oder die Firma zusammenbricht. Ein Umstieg auf AT-kompatible Produkte wäre möglich, aber ich mache mir Sorgen, dass viele Daten verloren gehen könnten.

    • Wer sich für das Thema interessiert, findet auf whtwnd.com/bnewbold.net praktische Informationen zu Relais-Netzwerken, Datenmigration und ähnlichem auf Basis von Bluesky und AT Proto, sowie Tools und Fortschritte zu Datenmigration, Portabilität und alternativen Relay-Netzwerken; auch der zugehörige Link lohnt sich.
      (Übrigens: Der Blogger dort ist ein Bluesky-Mitarbeiter; ich bin nicht mit ihm verbunden.)

    • Eigene Personaldaten lassen sich als CAR-Dateien im IPFS-Format (eine Art Tarball) sichern. Danach kann das Konto über das did:plc-Dokument oder DNS-Einträge auf jedem PDS wiederhergestellt werden. Falls der aktuelle PDS ausfällt oder blockiert wird, kann man sofort auf einen anderen Server wechseln. Relays (Gossip Nodes), PDS, Clients, App Views (Backend der Bluesky-Web-App) sowie zahlreiche Open-Source-Implementierungen und Hosting-Anbieter gibt es bereits.
      Sollte Bluesky morgen ausfallen, kann man einfach self-hosting nutzen oder die bestehende App über einen anderen Provider (z. B. zeppelin.social) weiterbetreiben. Das PLC Directory wird zwar noch von Bluesky verwaltet, befindet sich aber im Übergang zu einer unabhängigen Stiftung; bei Bedarf lässt es sich leicht replizieren. Mit did:web verlässt man sich nur auf DNS und gewinnt damit deutlich an Unabhängigkeit.

    • Darüber hinaus vertreibt Bluesky deutlich libertäre (freiheitliche) oder rechte Nutzer aktiv, während linke oder politisch unbeteiligte Nutzer eine gute Stimmung haben.