Open Social

• So wie Open Source zum Standard der Software-Infrastruktur geworden ist, entsteht nun auch bei Social Apps ein Paradigma von „Open Social“
• Das AT Protocol ermöglicht es Nutzern, ihre Social-Daten direkt zu besitzen und zu kontrollieren, und stellt damit ein Konzept vor, das sich klar von bestehenden Social-Plattformen unterscheidet
• Social-Daten werden nicht länger in einem bestimmten Dienst eingeschlossen, sondern in einem persönlich verwalteten Speicher des Nutzers abgelegt
• Dadurch werden datenübergreifende Wiederverwendung und Remixing zwischen Apps möglich, und selbst bei einer Einstellung des Dienstes bleiben die Daten erhalten
• Mit der Verbreitung von Open Social dürften nutzergetriebenes Dateneigentum und flexible Erweiterbarkeit zu zentralen Werten werden

---

Einleitung: Der Erfolg von Open Source und ein neuer Wandel

• Open Source hat sich trotz vieler Widerstände in der Vergangenheit heute als Grundlage gemeinsamer Infrastruktur etabliert
• Anders als früher ist die Wahl von Open Source heute kein Problem mehr; in wichtigen Software-Bereichen ist Open Source zum Standard geworden
• Nun stehen wir im Bereich der Social Apps an einem ähnlichen Wendepunkt wie Open Source vor 35 Jahren
• Mit „Open Social“ ist eine neue Strömung entstanden, und das AT Protocol von Bluesky gilt als ihre überzeugendste Umsetzung

Die Grundstruktur des Webs und persönliches Dateneigentum

• Im früheren Web gab es persönliche Adressen wie alice.com oder bob.com, und jeder Nutzer besaß seinen eigenen Raum und konnte dort frei Inhalte veröffentlichen
• Wenn einem das Hosting nicht gefiel, konnte man zu einem anderen Anbieter wechseln, während die Adresse unverändert blieb und bestehende Links nicht abrissen
• Deshalb waren Nutzer nicht an einen bestimmten Hosting-Anbieter gebunden, und die Anbieter mussten konkurrieren
• Dank der dezentralen Architektur des Webs behielten Nutzer die Kontrolle über ihre Daten, während Anbieter nur Dienstleister waren

Moderne soziale Netzwerke: Der Verlust des Dateneigentums

• Heute betreiben die meisten Menschen keine eigene Website mehr, sondern posten in Social-Media-Apps mit von Unternehmen vergebenen IDs wie @alice oder @bob
• Daten wie Beiträge, Kommentare und Likes werden in den Datenbanken bestimmter Social-Unternehmen gespeichert
• Diese Struktur hat soziale Aggregationsfunktionen wie Suche, Feeds, Empfehlungen und Benachrichtigungen hervorgebracht
• Gleichzeitig entsteht aber der Nebeneffekt, dass die Kerndaten nicht mehr uns gehören
• Nutzer befinden sich in einer Situation, in der sie ihre selbst geschaffenen Daten und Beziehungen nicht frei mitnehmen können

Das Problem: Nutzer in Plattformen eingeschlossen

• Wer eine Plattform verlässt, muss sein gesamtes selbst aufgebautes Beziehungsnetz zurücklassen
• Der Hosting-Anbieter lässt sich nicht einfach wechseln, und beim Verlassen der Plattform gehen auch Verbindungen und Daten verloren
• Weil Plattformen das wissen, müssen Nutzer oft nachteilige Änderungen (Werbeflut, verzerrte Algorithmen, entfernte Funktionen usw.) hinnehmen
• Selbst wenn Daten gesichert oder exportiert werden, sind sie nur „tote Daten“ ohne sozialen Kontext und lassen sich anderswo nur schwer wiederbeleben

Open Social: Wiederherstellung von Dateneigentum und Netzwerk

• In Open Social geben domänenbasierte Handles wie @alice.com dem Nutzer das tatsächliche Eigentum an seinen Social-Daten zurück
  • Der Name ist mit einer Domain verbunden, die mir gehört, etwa @alice.com
• Nutzer verwalten über ein persönliches Repository alle Social-Daten, die sie selbst erzeugen
  • Aktivitäten wie Beiträge, Kommentare oder Follows werden im persönlichen Repository (Repo) aufgezeichnet
  • Das Repository ist einfach ein Webserver, der Datensätze im JSON-Format speichert
  • Die Adresse hat die Form at://alice.com/... und kann mit anderen verknüpft werden
• Ein auf dem AT Protocol basierendes Repository arbeitet auf DNS, HTTP und JSON und speichert jede Information als verlinktes JSON
• Auch für Menschen ohne technisches Wissen wird beim Registrieren in einer App automatisch ein Repository angelegt, sodass die Daten unabhängig von der App im Besitz des Nutzers bleiben
• Die Daten gehören dem Speicher des Nutzers, und selbst wenn sich der Dienstanbieter ändert, bleiben Dateneigentum und Verknüpfbarkeit erhalten

Struktur und Anwendungen von Open-Social-Apps

• Jede Open-Social-App verwaltet ähnlich wie ein CMS einen Teil des Social-Speichers des Nutzers; die App ist nun nur noch ein Werkzeug zum Lesen und Schreiben im Speicher des Nutzers
• Beispielsweise können Daten aus verschiedenen Apps wie Bluesky, Tangled oder Leaflet im Speicher eines einzelnen Nutzers nebeneinander existieren
  • Wenn ich in Bluesky einen Beitrag schreibe, bleibt ein Eintrag in meinem Speicher zurück; wenn ich in Tangled ein Projekt mit einem Stern markiere, landet auch das in meinem Speicher
  • Die Datenformate werden zur Vermeidung von Kollisionen durch Namespaces getrennt, etwa app.bsky.post oder sh.tangled.star
  • Mit der Zeit wird mein Speicher zu einer Sammlung von Daten aus vielen verschiedenen Apps

Wie ein offenes Datenmodell das Ökosystem verändert

• Weil die Daten offen gespeichert werden, werden App-übergreifende Integration, neue Services sowie freies Referenzieren, Wiederverwenden und Remixen fremder Daten einfacher
• Selbst wenn eine App eingestellt wird, bleiben die Daten im Speicher des Nutzers erhalten und können in anderen Diensten weiterverwendet werden
• Neue Apps können bestehende Beziehungen und Daten des Netzwerks nutzen, um das „Cold-Start“-Problem zu überwinden
• Da diese Daten für jeden lesbar sind, kann eine andere App sie übernehmen, Profilbilder laden oder bestehende Follow-Beziehungen unverändert weiterverwenden
• Auch wenn eine App schließt, bleiben die Daten im Nutzerspeicher und können von einer anderen App wieder hervorgeholt werden

Aggregation und technische Herausforderungen

• Die Daten der Nutzer sind auf einzelne Speicher verteilt, aber über WebSocket-Abonnements werden Event-Streams von Datenänderungen empfangen und in eine lokale Datenbank übernommen
• Über große Relays werden Ereignisse des gesamten Netzwerks empfangen und nur die benötigten gefiltert
• Daten-Records sind kryptografisch signiert und gewährleisten Vertrauenswürdigkeit und Konsistenz
• Infrastrukturen wie Graze und Slices unterstützen die Aggregation im Open-Social-Modell

Wie funktionieren Aggregationsfunktionen?

• Obwohl die Speicher der einzelnen Nutzer getrennt existieren, empfangen Apps Echtzeit-Event-Streams aus diesen Speichern und schreiben sie in ihre eigene Datenbank
• Relay-Server wie bei Bluesky sammeln den gesamten Stream und liefern ihn aus; Apps speichern nur die Ereignisse, die sie interessieren
• Die so aufgebaute Datenbank kann Funktionen wie Suche, Feeds und Empfehlungen schnell bereitstellen
• Daten-Records sind kryptografisch signiert und gewährleisten Vertrauenswürdigkeit und Konsistenz: Selbst ohne dem Relay zu vertrauen, lässt sich die Echtheit der Daten prüfen
• Infrastrukturen wie Graze und Slices unterstützen die Aggregation im Open-Social-Modell

Das große Bild

• Früheres Web: Nutzer hatten ihre eigenen Inhalte und Adressen in der Hand
• Heutige Social Apps: Es gibt Aggregationsfunktionen, aber die Daten bleiben in firmeneigenen Datenbanken eingeschlossen
• Open Social: Die Aggregationsfunktionen bleiben erhalten, während die Daten in den Händen der Nutzer bleiben
• Apps werden nur noch zu einem Fenster, das die Daten der Nutzer sammelt und anzeigt
• Selbst wenn ein Dienst verschwindet, bleiben die Daten bestehen und können von anderen Apps in neuen Kontexten wieder angezeigt werden

Fazit

• Der Kern von Open Social ist die Verbindung der Vorteile des persönlichen Webs (Dateneigentum, freie Wahl des Hostings, stabile Links) mit den Stärken geschlossener sozialer Netzwerke (Aggregation, Skalierbarkeit)
• Open Social garantiert nutzergetriebenes Dateneigentum, freie Datenmobilität zwischen Apps und Dienstkontinuität
  • So wie Open Source sagte: „Der Code sollte den Nutzern gehören“, gilt nun: „Die Daten sollten den Nutzern gehören“
  • Damit wird das Problem gelöst, dass Nutzer auf geschlossenen Plattformen ihre Daten und ihre Konnektivität verlieren
• Wenn mehr Open-Social-Produkte entstehen, werden die Grenzen zwischen Apps verschwimmen und ein Ökosystem entstehen, in dem Daten ganz natürlich fließen
  • Am Ende könnte eine Zukunft entstehen, in der Nutzer ihre Daten und Netzwerke tatsächlich kontrollieren
• In der Anfangsphase wird die Bewegung wohl von einer kleinen Zahl engagierter Entwickler und Nutzer getragen, doch sobald eine gemeinsame Grundlage wächst, hat der offene Ansatz langfristig gute Chancen
  • Auch ohne technische Konzepte wie Dezentralisierung oder Föderation zu kennen, können Menschen den praktischen Nutzen (Datenverknüpfung, einfacher Wechsel, Beständigkeit) spüren
  • Open Social wird sich durch langfristige, gemeinschaftsgetriebene Anstrengungen und kumulative Effekte schrittweise verbreiten

[shakespeares]

Es stimmt zwar, dass Instagram auch ein Ort ist, an dem Erinnerungen gespeichert werden, aber man scheint dort nicht so leicht nach Belieben herauszukommen.
Ich habe auch das Gefühl, dass man beim Teilen und Nutzen von Daten gewisse Zugeständnisse machen muss.

[kimjoin2]

KakaoTalk ... ss

[GN⁺]

Hacker-News-Meinungen

• Ich dachte zuerst, das AT Protocol sei einfach die Bluesky-Version von ActivityPub für Unternehmen, aber nach diesem Artikel gefällt mir die Art, wie Daten in einem von mir gewählten „Repository“ gespeichert werden, ziemlich gut. Das passt auch zu meinem allgemeinen Grundsatz: Ich glaube, dass Filtern und Ähnliches auf der Leseseite besser aufgehoben ist als beim Schreiben. So kann ich alles, was ich will, in mein Repository stellen, und andere können es lesen und verwenden. Die Pfeile lassen zwar so aussehen, als würden Kommentare in mein Repository gelangen, aber das wirkt eher wie eine kleine Ungenauigkeit bei der Darstellung der Idee. Insgesamt wirkt die Struktur sehr cool und stark dezentralisiert. Als ich allerdings versucht habe, in AT selbst ein separates PDS zu betreiben, habe ich gemerkt, dass es zwar ziemlich glatt und gut verpackt ist, aber doch ein paar Voraussetzungen mitbringt:

  1. SSL und Ähnliches werden automatisch erledigt
  2. Es wird ein HTTPS/WSS-Server gestartet, der verschiedene RPCs unterstützt Deshalb brauche ich, selbst wenn ich eigentlich sowohl https://roshangeorge.dev als auch at://roshangeorge.dev nutzen will, für Letzteres trotzdem https://roshangeorge.dev/xrpc und wss://roshangeorge.dev. Am Ende betreibe ich also faktisch https://roshangeorge.dev und at://at.roshangeorge.dev sowie https://at.roshangeorge.dev und wss://at.roshangeorge.dev. Natürlich ist das nur ein Detail und kein grundsätzliches Problem der Ausrichtung. Trotzdem wollte ich es anmerken.

  • Ich habe wohl Verwirrung gestiftet, weil ich zwei Arten von Pfeilen verwendet habe. Die durchgezogenen Pfeile (die von @alice.com nach unten) zeigen Eigentum an. Das entspricht auch der farblichen Gruppierung. Alles Blaue gehört Alice. Die gestrichelten Pfeile sind Links zwischen Records. Genau wie bei `` kann jeder Record frei auf jeden anderen verweisen, egal in welchem Repository er liegt. Wenn jemand meinen Beitrag kommentiert, landet dieser Kommentar im Repository der kommentierenden Person und wird mit dem Originalbeitrag verlinkt. Das Datenmodell ist absichtlich so aufgebaut, damit jemand, der indexiert, die Beziehung leicht wiederherstellen kann, wenn beide Records vorliegen. Wenn Bob also auf Alices Beitrag antwortet, liegt Bobs Kommentar in Bobs Repository und Alices Beitrag in Alices Repository. Wenn jemand meinen Beitrag kommentiert, bleibt dieser Kommentar immer im Repository dieser Person. Die zentrale Annahme ist, dass man keine Records im Repository anderer anlegen kann.

  • Das Standard-Packaging für PDS unterstützt die SSL-Behandlung automatisch, aber es ist nicht zwingend vorgeschrieben, sondern nur so umgesetzt, dass Entwickler es leicht nutzen können. at://-URIs haben die Form at://DID/..., und menschenlesbare Handles werden über einen DNS-TXT-Record (_atproto.roshangeorge.dev) auf eine DID gemappt. Die DID verweist wiederum auf ein Dokument, das den Serverstandort festlegt, daher können HTTPS/WSS-Routen beliebig platziert werden. Außerdem landen Likes, Antworten usw. auf meine Beiträge im Repository der Person, die diese Aktion ausgeführt hat, nicht in meinem. Dieses Bauchgefühl war also richtig.

• Ich dachte, ActivityPub sei das bessere Protokoll und AT nur ein billiger Abklatsch, aber nach diesem Artikel wurde mir klar, dass AT viel besser ist. Der entscheidende Punkt ist, dass mehrere Programme dieselbe Identität teilen können. Das ist wirklich eine großartige Eigenschaft und hat meinen Horizont enorm erweitert.

  • Die meisten Erklärungen zu ATProto konzentrieren sich auf Dateneigentum, aber tatsächlich ist ActivityPub bei der Datenverarbeitung stärker. ATProto ist so aufgebaut, dass es die ganze Welt öffentlich betrachtet, daher sind alle Ereignisse auf einem vertrauenswürdigen globalen AppServer sichtbar und müssen dort direkt beurteilt werden; Feed-Erzeugung, Zugriffsrechte usw. hängen deshalb alle von vertrauenswürdigen Vermittlern ab. ActivityPub ähnelt eher RSS oder E-Mail: Mein Server verwaltet nur die Feeds, die ich abonniert habe, und mein Posteingang besteht direkt aus Beiträgen, auf die ich zugreifen darf. Deshalb gibt es bei Bluesky auch keine „privaten Likes“ wie bei Twitter. Jede AppView müsste die Like-Zahlen sämtlicher Beiträge im Netzwerk selbst verfolgen, was extrem umständlich ist. Langfristig halte ich die Struktur von ActivityPub für vorteilhafter. Und was den Punkt „mehrere Programme teilen dieselbe Identität“ angeht: Das gab es tatsächlich schon in den frühen ActivityPub-Entwürfen. Die populärsten frühen Implementierungen haben diese Funktion nur weggelassen, um besser in bestehende Strukturen zu passen.

  • Die Debatte AT vs. AP ist so komplex. Auch in unserer Community wurde das mehrfach diskutiert, daher hier ein Thread als Referenz: https://github.com/bevyengine/bevy/discussions/18302

  • Freut mich, dass dich gerade dieser Aspekt anspricht. Mich nervt es immer, wenn es ständig mit AP verglichen wird, weil der Umfang einfach völlig anders ist.

  • Ein Artikel, der eine ähnliche Sicht aus Perspektive eines Engineers für verteilte Systeme behandelt, wäre vielleicht auch interessant: https://atproto.com/articles/atproto-for-distsys-engineers

  • Heißt das dann, dass es einen zentralisierten Identitätsdienst gibt?

• Mir ist egal, welches verteilte Protokoll am Ende gewinnt, aber obwohl ATProtocol theoretisch gut aussieht, wirkt ActivityPub in der Praxis auf mich zunehmend attraktiver. Ich bin auf Lemmy ziemlich aktiv, und dort ist es recht lebendig und unterhaltsam.

  1. 99,99 % der AT-Nutzer sind bei Bluesky konzentriert. Das ist ein von einem Unternehmen geführter Dienst. Auch wenn sie behaupten, das Protokoll nicht zu kontrollieren, bleibt es faktisch die dominante Instanz des Protokolls, sodass die Gefahr besteht, dass Änderungen nach ihrem Geschmack durchgesetzt werden. Ich habe sogar die Sorge, dass sie in fünf Jahren entscheiden könnten, dass Migration nicht mehr möglich sein soll. Genau so etwas ist in anderen sozialen Netzwerken schon oft passiert.
  2. Nutzer interessieren sich nicht für Protokolle; Trägheit und bestehende Nutzerbasis sind viel wichtiger. Schon bei den verschiedenen Reddit-Alternativen auf AP ist es extrem schwer, Nutzer dazuzuholen, und noch schwerer, sie zu einem Wechsel zu bewegen. Ich fürchte, solche Versuche zersplittern nur die ohnehin kleinen Communities noch weiter, bis am Ende alle entnervt wieder zu den großen Plattformen zurückkehren. Dass Kontowechsel einfach sein sollen, ist zwar ein nettes Feature, aber Backup/Restore von Einstellungen und das Anlegen eines Kontos auf einer neuen Instanz sind ohnehin schon einfach genug. Das ist für mich kein großer Umbruch. Referenzseite: https://arewedecentralizedyet.online/ Lemmy, programming.dev, Piefed usw. halte ich derzeit ebenfalls für ziemlich gut.

  • Anders als bei Mastodon ist das Instanzkonzept bei AT grundsätzlich anders. Selbst innerhalb der Bluesky-Infrastruktur gibt es mehrere PDS, und strukturell funktioniert es hierarchisch anders (siehe den verlinkten Artikel). Von einer einzelnen dominanten Instanz zu sprechen, ist daher nicht ganz treffend. Natürlich ist die Sorge realistisch, dass ein Unternehmen das Protokoll nach eigenem Geschmack steuern könnte. Bisher hat es aber eher die Rolle eines guten Verwalters gespielt. Ich denke, das wird sich mit wachsendem Ökosystem nach und nach lösen. Und auch die Sorge, Bluesky könnte schließen und man könne dann nicht wegmigrieren, ist durch das Protokoll selbst adressiert: Backup und Migration sind eingebaut. Solange man eine CAR-Datei hat, kann man jederzeit zu einem anderen Host umziehen. Bei Mastodon geht bei einer Kontomigration vieles verloren, bei atproto kann man dagegen zu 100 % transparent migrieren.

  • Letztlich geht es bei Bluesky wie bei Mastodon fast nur um US-Politik. Ich mag wöchentliche Politdramen nicht besonders, daher passen Plattformen wie Tumblr, Pinterest oder TikTok mit mehr thematischer Vielfalt wahrscheinlich besser zu mir.

  • Mastodon ist zwar nicht völlig identisch mit ActivityPub, aber ich vertraue ihm wegen der plötzlich verschwindenden Antworten nicht. Manche Beiträge bleiben, andere verschwinden wieder, und das war einer der zwei Gründe, warum ich Mastodon verlassen habe.

• Es ist ein bisschen schade, dass jede App ihre eigenen Collection-Typen verwendet und trotz möglicher gemeinsamer Nutzung unklar bleibt, ob die Apps am Ende wirklich interoperabel sein werden. Einer der schönen Aspekte von ActivityPub ist, dass ein Mastodon-Nutzer einem Pixelfed-Nutzer folgen kann, ohne sich darum groß kümmern zu müssen. Es fühlt sich an, als wären Twitter, Instagram, Reddit, YouTube und Substack automatisch miteinander verbunden, ganz ohne besondere Einrichtung.

  • Bei AP funktionieren mehrere Dienste grundsätzlich bei den Typen Status und Question gut zusammen. Mastodon, Pixelfed, Misskey, Pleroma usw. bauen alle stark auf diesem Schema auf. Darüber hinaus ist die Unterstützung anderer Typen aber sehr begrenzt, sodass andere Inhaltsarten nicht sauber unterstützt werden. Ein Problem ist der Mangel an Community-Organisation für Erweiterungen außerhalb des Standards. ATproto verlangt dagegen, dass Daten-Collections den definierten Lexicons/Schemas folgen, und Referenz- sowie Drittimplementierungen bieten Schema-Validierung. Dadurch ist grundlegende Kompatibilität klarer strukturiert. Andererseits sollte das System vielleicht flexibler werden, sodass optionale Unterstützung für zusätzliche Felder und Ähnliches leichter möglich ist. Es gibt etwa Beispiele wie Bridgy Fed, das aus APub stammende Daten mit Metadaten wie Original-URL oder Text anreichert. (Siehe https://fed.brid.gy/docs#bluesky-fields)

  • Es gibt laufende Bemühungen, gemeinsame Lexicons zu verbessern: https://github.com/lexicon-community

• Ich habe langsam das Gefühl, dass Projekte, die vom „nächsten Twitter“ sprechen, das Problem jeweils leicht falsch angehen. Selbst wenn sie Twitter funktional perfekt nachbauen, bleiben sie dann am Henne-Ei-Problem aus zu wenigen Nutzern und zu wenig Inhalt hängen. Am Ende gehen Menschen dorthin, wo andere Menschen sind, und das ist immer noch Twitter. Stattdessen wirkt der Ansatz sinnvoller, zunächst im Hintergrund Daten zu sammeln und sie dann den Nutzern auszuliefern, ähnlich wie die kürzlich von OpenAI gestartete Timeline. Die konkrete Umsetzung kann unterschiedlich sein, aber die Richtung erscheint mir richtig. Die meisten Nutzer legen wohl keinen großen Wert darauf, selbst Tweets zu schreiben; der eigentliche Wert liegt im Datenkonsum, also in der Beschaffung von Inhalten. Aus dieser Perspektive scheint mir ein Multi-Social-RSS-Reader mit P2P-Option die bessere Richtung zu sein. Nur meine persönliche Meinung.

  • Wie im Artikel beschrieben, dient Microblogging nur als anfängliches Framing, tatsächlich sind aber weit mehr Formen möglich als nur Twitter-artige Dienste. Beispiele: Tangled ist „Github auf atproto“, Leaflet ist „Medium auf atproto“. Die Grenzen eines clientseitigen P2P-Ansatzes liegen darin, dass großskalige Aggregation und Konsistenz schwer zu gewährleisten sind, und genau das erwarten die meisten normalen Nutzer von einer Social-App als Grundfunktion. Auch das OpenAI-Beispiel ist etwas, worin atproto stark ist. Die Daten existieren bereits im Netzwerk, daher lassen sich Crawler, Indexierung und Automatisierungstools leicht darauf aufsetzen. Ein frühes Beispiel ist https://github.com/graze-social/iftta.

  • Soziale Netzwerke wachsen nicht durch „das Gleiche, aber mit etwas extra!“, sondern dann, wenn sie neue Nutzungsformen ermöglichen, die auf der vorherigen Plattform nicht möglich waren.

  • Deshalb ist Nostr anders! Man kann alles darauf bauen: Blogs, Twitter-artige Dienste, Streaming-Services, Messenger und mehr. Eine Beispielsammlung: https://nostrapps.com

• Ich frage mich, ob kostenlose Top-Level-Domains (TLDs) möglich wären. Was kostet eine Domainregistrierung tatsächlich? Wenn man daran denkt, dass Let's Encrypt Zertifikate kostenlos verfügbar gemacht hat, frage ich mich, warum eine gemeinnützige Organisation nicht auch Domains gratis vergeben könnte. Sie müssten nicht einmal schön aussehen. Mir wäre es egal, wenn es nur eine Reihe von UUID-v7-Werten wäre, solange sie global eindeutig und kostenlos sind. Der Browser merkt sich die Adresse nach dem ersten Zugriff, also wären auch lange Namen kein Problem. Ist diese Idee wirklich so schlecht?

  • Bei atproto übernimmt das did:plc. Unter https://web.plc.directory/ kann man kostenlos eine ID bekommen. Meine ID ist zum Beispiel https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr. Über einen TXT-Record der Domain lässt sie sich dann mit dieser did:plc verknüpfen.

  • Kostenlose TLDs sind praktisch schwer umzusetzen. Für TLDs und die Public Suffix List gelten verschiedene Regeln, Kosten und administrative Besonderheiten, siehe https://github.com/publicsuffix/list. Normale Domains unterhalb einer TLD kann man dagegen grundsätzlich frei nutzen, und auch kostenlose Subdomains kann man verteilen. In der Praxis bereut man den Betrieb eines solchen Dienstes aber schnell, weil dann Spam, Phishing und andere dunkle Seiten des Internets auf einen einprasseln. Genauso wie jeder theoretisch einen URL-Redirector bauen kann, der reale Betrieb aber eine ganz andere Sache ist, stößt man bei ernsthaftem Betrieb sehr schnell auf Probleme. Leider ist das die Realität.

  • Das ist im Grunde ein ähnliches Konzept wie die Vergabe von IPv6-Adressen. Die meisten privaten Internetanschlüsse bekommen heute öffentliche IPv6-Präfixe in /64-Größe, aber die ISPs blockieren meist per Port-Firewall, sodass sie praktisch kaum nutzbar sind. Außerdem verliert man die Adressen leicht, wenn man den ISP wechselt. Wenn man daraus wirklich permanente und portable IPv6-Adressen machen wollte, müsste man kostenlos providerunabhängigen Adressraum an Einzelpersonen vergeben und ihn per BGP global routbar machen. Theoretisch ist das möglich, wurde aber bislang nie umgesetzt – ähnlich wie die Lage vor der Entstehung von Let's Encrypt. Ich weiß nicht, warum man dafür unbedingt DNS-basiertes Naming bräuchte; wenn es nicht kurz und merkbar sein muss, ist DNS dafür gar nicht so passend. Ein Modell wie bei ngrok, das Domains unter einer eigenen gTLD ausstellt, könnte aber interessant sein. Tatsächlich hat die .me-ccTLD früher einmal auf diese Weise kostenlose Domains verteilt und im Gegenzug in den gesamten Traffic auf einem zwischengeschalteten Proxy Werbung eingefügt.

  • .tk war kostenlos und nach Registrierungszahl die größte ccTLD der Welt. Sie wurde allerdings oft missbraucht. Facebook verklagte den Betreiber – das niederländische Unternehmen Freenom – wegen Beteiligung an Phishing, und seitdem ist die kostenlose Vergabe nicht mehr möglich.

  • Es gab einmal die .FREE-TLD-Initiative, aber wegen Umsetzungsproblemen und verpasster Fristen ist sie inzwischen im Sande verlaufen: https://icannwiki.org/.free

• Wenn ich einen Artikel von Dan sehe, klicke ich darauf. Ich mache mir etwas Sorgen, dass das offene Web vor allem wegen des First-Mover-Vorteils erfolgreich war. Andererseits macht mir der Erfolg von Open Source Hoffnung. Ich würde gern eine Welt sehen, in der sich so etwas wie atproto durchsetzt. Es ist wirklich schade, wenn bessere Apps wegen Netzwerkeffekten keinen Erfolg haben können.

  • HTML war erfolgreich, weil es „kostenlos“ war. Damals gab es viele kostenpflichtige Hypermedia-Standards, aber HTML war im Vergleich dazu sehr zugänglich. Jeder konnte relativ leicht einen Browser oder Server bauen.

  • Ein großer Vorteil von ATProto ist auch, dass es so entworfen wurde, die Grenzen von Netzwerkeffekten zu durchbrechen. Wenn alle zu atproto-basierten Diensten migrieren, muss man soziale Netzwerke nicht immer wieder „nur noch ein letztes Mal“ umziehen. Am Ende ermöglicht das eine dezentralisierte Umgebung mit freiem Wettbewerb.

• Realistisch gesehen fällt es mir schwer, mir vorzustellen, dass sich so ein System breit durchsetzt. Die klassische Social-Media-Zielgruppe und Nutzer mit dezentraler Ausrichtung sind völlig unterschiedliche Gruppen. Die meisten interessieren sich nur für die Plattform als Mittel zum Zweck, nicht für das dahinterliegende System. Wenn am Ende alle einfach nur ein Bluesky-Konto anlegen, konzentriert sich wieder alles auf ein paar große Dienste, und dann ist der Sinn dahin.

  • Selbst wenn sich alle bei bsky.social sammeln, wäre das immer noch ein gewaltiger Fortschritt gegenüber heute. So wie man auch nicht sagt, das Web sei zentralisiert, nur weil viele Server auf AWS laufen, kann man jederzeit umziehen, wenn es nötig wird.

  • Tatsächlich ist Federation bei Bluesky noch nicht vollständig umgesetzt. Der gesamte Traffic hängt derzeit von einem einzelnen „BGS“-Router-Server ab.

  • Leider liegt die eigentliche Ursache des Problems am Ende bei den Menschen.

• Ich habe zu dieser Arbeit gemischte Gefühle. Einerseits trifft die Idee genau meinen Geschmack. Dass jeder seine eigenen Inhalte besitzt, passt zur Indie-Web-Bewegung, und die Qualität dieser Seite und der Artikel ist wirklich beeindruckend. Andererseits gibt es kaum Entwickler, die solche Standards tatsächlich in ihren persönlichen Blogs oder Open-Source-Projekten einsetzen, und auch unter normalen Bloggern/Vloggern und Alltagsnutzern ist die Akzeptanz gering. Es beunruhigt mich, dass so viele Menschen gegenüber Dateneigentum, Offenheit und Interoperabilität gleichgültig sind. Die Leute scheinen einfach nur Feeds wie TikTok oder Instagram Reels zu wollen. Ich respektiere die Vision und die Mühe sehr, aber ich frage mich, ob das jemals Mainstream statt nur eines Nischenhobbys werden kann.

  • Es bleibt noch Arbeit, die Developer Experience einfacher zu machen. Aber die Entwicklung in diesem Bereich ist gerade extrem schnell, deshalb freue ich mich sehr auf die nächsten 6 bis 12 Monate. Die meisten Menschen verstehen noch nicht, dass ATProto nicht nur für Bluesky gedacht ist, sondern in viel breiteren Bereichen eingesetzt werden kann. Es braucht einfach Zeit, bis das im Markt konkreter sichtbar wird.

  • Ich frage mich, warum das Konzept von „Dateneigentum“ so wichtig sein soll und warum es wirklich besorgniserregend ist, dass sich die breite Masse nicht dafür interessiert. Menschen haben schon immer Inhalte konsumiert, ohne sie zu besitzen – etwa bei Fernsehen, Büchern oder Radio. Heute können sie immerhin selbst etwas veröffentlichen, das andere sehen. Aber ist es wirklich so wichtig, ob man einen Instagram-Post tatsächlich „besitzt“?

  • Da stimme ich zu. Letztlich kann diese Technologie nur erfolgreich werden, wenn wir sie aktiv verbreiten und zu ihrer Popularisierung beitragen. Vielleicht wird irgendwann ein Gründer oder CTO, der vom offenen sozialen Web begeistert ist, eine massentaugliche Erfolgs-App bauen. Wenn wir gar nichts tun, wird es auf keinen Fall gelingen.