atproto hat keine Instanzen
(overreacted.io)- Die Frage nach „Bluesky-Instanzen“ überträgt das Instanzmodell von Mastodon direkt auf atproto, obwohl atproto bewusst so entworfen wurde, dass Hosting und App-Aggregation getrennt sind
- Wie bei RSS und Google Reader sind Daten nicht in einer App eingeschlossen, sondern liegen in gehosteten Repositories, aus denen verschiedene Apps die Daten abrufen und anzeigen
- Mastodon-Instanzen bündeln Hosting, App, Identität und Föderationsbeziehungen in einer einzigen Box, sodass Entscheidungen von Administratoren oder Ausfälle einer Instanz die Nutzererfahrung direkt beeinflussen
- Bei atproto können Nutzer ihr Hosting wechseln oder neue Apps erstellen und ausprobieren; Apps wie Tangled, Semble und Sidetrail funktionieren unabhängig von Bluesky
- Wer die Dezentralität von atproto beurteilen will, sollte nicht auf die Anzahl der Bluesky-Instanzen schauen, sondern darauf, ob alternative Hostings und ein neues App-Ökosystem tatsächlich funktionieren
Ein Modell näher an RSS und Google Reader
- Im RSS-Zeitalter veröffentlichten Nutzer ihre Beiträge im eigenen Blog, und Apps wie Google Reader oder Feedly aggregierten Beiträge aus vielen Blogs
- Die Beiträge „lebten“ nicht in Google Reader, sondern blieben in den jeweiligen Blogs oder an ihrem Hosting-Ort erhalten
- Der Kern ist die Trennung von Hosting und Aggregation
- Hosting ist der Ort, an dem die eigentlichen Inhalte existieren
- Aggregations-Apps sind eher eine Projektion verschiedener Inhaltsquellen
Zentralisierte soziale Medien und Mastodons Antwort darauf
- Traditionelle soziale Medien funktionieren so, dass alle Nutzer in einer einzigen App und einem einzigen Raum zusammengeführt werden
- In dieser Struktur entstehen Zentralisierung und starke Netzwerkeffekte; die Diskussion über dezentrale soziale Netzwerke beginnt damit, wie man dieses Problem aufteilen kann
- Der Mastodon-Ansatz besteht darin, dass jede Community ihr eigenes „kleines Facebook“ oder „kleines Twitter“ betreibt; diese Box ist die Instanz
Was Mastodon-Instanzen bündeln
- Nutzer gehören zu einer bestimmten Instanz „darin“
- Dass das Mastodon-Login-Format
[email protected]ist, liegt ebenfalls daran, dass die Instanz Teil der Identität ist - Der Nutzer ist nicht eine abstrakte „Alice“, sondern „Alice von Instanz Nr. 1“
- Dass das Mastodon-Login-Format
- Damit Nutzer verschiedener Instanzen kommunizieren können, müssen die Instanzen Nachrichten austauschen
- Wenn Alice auf Instanz Nr. 1 ist und Bree auf Instanz Nr. 2, dann wird beim Folgen von Bree durch Alice Brees Beitrag an Instanz Nr. 1 übertragen
- Diese Übertragungsbeziehung ist die Föderation
- Hosting und App sind gemeinsam gebündelt, wodurch Nutzer stark von ihrer Instanz abhängig werden
Einschränkungen durch die Instanz-Kopplung
- Kommt es zu Konflikten zwischen Instanz-Administratoren, können sie die Föderation beenden
- In diesem Fall können Nutzer die Beiträge ihrer Freunde möglicherweise nicht mehr sehen
- Fällt die Instanz eines Nutzers aus, verschwindet auch die an diese Instanz gebundene Identität
- Denn Follower folgen einem „Nutzer dieser Instanz“
- Die Verbindungspfeile zwischen Instanzen wachsen mit O(n²)
- Derzeit ist das vielleicht kein großes Problem, aber wenn diese Art sozialer Netzwerke populär wird, könnte es wichtig werden
Der zentrale Unterschied von atproto
- atproto setzt kein Mastodon-artiges Instanzkonzept voraus, sondern kehrt zum Modell von RSS und Google Reader zurück
- Auf Netzwerkebene trennt es Hosting und Aggregation
- Die Daten liegen im Hosting
- Apps aggregieren Daten aus dem Hosting vieler Personen
- Deshalb gibt es in atproto keine Instanzen
- Hosting kann gewechselt werden
- Apps aggregieren Daten aus vielen Hostings
- Diese Struktur wirkt wie eine reichhaltigere Form der Dezentralisierung als „eine App in vielen Kopien zu betreiben“
Dezentralisierung, die Nutzer selbst umsetzen können
- Nutzer können ihr Hosting austauschen
- Der Autor hat seine atproto-Daten zu Eurosky verschoben und erklärt, dass dies bis auf einige UX-Probleme automatisch ablief
- Wer aktiver sein möchte, kann auch kostenlos selbst bei Cloudflare hosten
- Man kann neue Apps ausprobieren oder selbst bauen
- Tangled und Semble sind Beispiele für atproto-Apps unabhängig von Bluesky
- Der Autor hat eine App namens Sidetrail gebaut; diese App ist Open Source
- Für atproto gibt es auch ein Statusphere-Tutorial zum Bau von Apps
Warum die „Anzahl der Bluesky-Instanzen“ am Thema vorbeigeht
- Bei Mastodon ist es naheliegend, Dezentralität über die Anzahl der Instanzen zu messen
- Denn die wichtigste Form der Dezentralisierung bei Mastodon besteht darin, mehr Boxen zu betreiben, in denen Hosting und App gekoppelt sind und die miteinander sprechen
- Bei atproto sind alle Apps eher eine Projektion der gesamten Atmosphere
- Die Struktur ähnelt Feedly und Google Reader, die die gesamte Blogosphere zeigen
- Es ist zwar möglich, mehrere vollständige Kopien des Bluesky-Datenbankservers zu betreiben, aber das ist im Allgemeinen kaum nützlicher, als viele Kopien von Google Reader zu betreiben
- Einige Kopien existieren für spezielle Anforderungen
- Blacksky ist ein Beispiel für einen speziellen Bedarf wie eine andere Moderationsphilosophie
- Der Client reddwarf.app verwendet ohne eigene Datenbank den kostenlosen, von der Community betriebenen Cache constellation
- Geteilte Netzwerkinfrastruktur wie Relay soll seit einem Jahr günstig betrieben werden können
Woran man atproto messen sollte
- Wer die Dezentralität von atproto beurteilen will, sollte nicht auf die „Anzahl der Bluesky-Instanzen“ schauen, sondern auf Folgendes
- Wechseln Menschen zu alternativen Hostings
- Erstellen und nutzen Menschen neue Apps
- Die Trennung von Hosting und App kann kaputte Anreize sowohl in geschlossenen als auch in föderierten sozialen Netzwerken korrigieren
- Dass Nutzerdaten außerhalb von Apps liegen und Apps darüber aggregieren, ist der Kern von atproto
1 Kommentare
Hacker-News-Kommentare
Die Frage „Wo ist die Bluesky-Instanz?“ wirkt wie eine absichtliche Fehlinterpretation, um ATProto aufzuwerten und ActivityPub abzuwerten
Dadurch werden interessante technische Fakten wie die Relays von ATProto samt Vor- und Nachteilen oder der Konto-Umzug bei ActivityPub samt Vor- und Nachteilen ausgelassen oder verzerrt, und zwischen zwei Plattformen, die ähnliche Probleme lösen, entsteht unnötiger Konflikt
Es gibt sicher auch Leute, die „Instanz“ im allgemeinen Sinn von Server, laufender Software, virtueller Maschine oder Container verwenden; ich verstehe nicht, warum das unbedingt nur im Mastodon-Sinn gelesen wird
Das Diagramm und die Erklärung waren gut, aber die unterschwelligen Seitenhiebe gegen ActivityPub wirkten eher von Feindseligkeit als vom Wunsch nach Informationsvermittlung getrieben
Der Vergleich mit „Wo ist die Google-Reader-Instanz?“ zeigt meiner Meinung nach gut, wie seltsam diese Frage ist, und ich finde, die beiden Grafiken am Ende des Beitrags erklären ziemlich gut Punkte, die in frühen Diskussionen über atproto/ActivityPub oft übersehen wurden
Warum ich Relays nicht aufgenommen habe, steht hier: https://news.ycombinator.com/item?id=48600963
Relays sind eher eine Performance-Optimierung als der Kern des Modells, deshalb wollte ich mich im Beitrag auf das Modell selbst konzentrieren
Sobald ein Wort mit einem bestimmten Konzept und einer bestimmten Struktur verknüpft wird, denken viele bei „dezentralen sozialen Medien“ an eine ActivityPub-artige Föderationsstruktur und fragen sich bei ATProto: „Warum gibt es nur eine Bluesky-Instanz, bei der sich Leute anmelden?“
Auch wenn es keine völlig neue Perspektive ist, wirkt es wie ein nützlicher Beitrag, auf den man später noch einmal verlinken kann, wenn jemand diese bestehenden Assoziationen fest im Kopf hat
Statt eines „filioque“-Edikts wechseln dann Blogposts hin und her, in denen beide Seiten aneinander vorbeireden, weil sie „Föderation“ unterschiedlich definieren
Das Fediverse-Modell lässt sich aus Sicht bestehender sozialer Netzwerke leicht verstehen, aber ATProto ist ein neues Konzept, das Nutzern Datensouveränität geben und zugleich die Skalierbarkeit zentralisierter sozialer Netzwerke erreichen will
Meiner Meinung nach ist die Analogie hier brüchig
RSS war überhaupt nicht von Google Reader abhängig und war selbst in seiner Blütezeit weniger davon abhängig als E-Mail heute von Gmail
Bei ATProto ist AppView stark auf Relays angewiesen, wenn es nützlich werden soll, und der Betrieb von Relays kostet auch einiges
Außerdem ist der gelbe Kreis im RSS-Diagramm, der für Blogs steht, etwas anderes als ein Kreis, der für Facebook-Posts steht. Blogs sind an sich eigenständig
Das heißt nicht, dass ATProto schlecht ist, aber dieser Beitrag wirkt eher verwirrend als klärend
Früher war es etwas teurer, weil der gesamte Traffic gespeichert wurde, aber mit sync 1.1 ist dieser Teil weggefallen, und heute lässt sich das selbst auf einer virtuellen Maschine für 20 Dollar im Monat recht problemlos betreiben
Wirklich teuer und schwierig ist, egal ob zentralisiert oder dezentralisiert, weiterhin die Moderation
Der Autor dieses Beitrags ist schon vor 9 Monaten auf ein verbreitetes Missverständnis über Relays eingegangen: https://news.ycombinator.com/item?id=45077291#45078223
Für mich sind Relays der Klebstoff, der ATProto performant funktionieren lässt
Sie transportieren Daten unabhängig vom Inhalt und reduzieren offenbar die Zahl der Dienste, die jede AppView kennen muss
Wie auch im Beitrag gesagt wird, ist die große Verbesserung gegenüber Mastodon, dass Relay, AppView und PDS getrennte Dienste mit unterschiedlichen Skalierungsanforderungen sind, und das ist eine ziemlich elegante Lösung für ein Systemdesign-Problem
[1] https://atproto.com/guides/glossary
Es ist allerdings eine unsichtbare Optimierung, und es gibt auch andere Strategien, deshalb habe ich es im Beitrag weitgehend weggelassen
Viele kleine Apps bauen heute zum Beispiel keinen eigenen Datenbankindex auf, sondern verlassen sich auf Constellation(https://constellation.microcosm.blue/) und verwenden daher überhaupt keine Relays
Es wird behauptet, nur Inhalte zu entfernen, deren Hosting illegal wäre, aber wie sehr das tatsächlich stimmt, weiß ich nicht, und es besteht immer das Risiko, dass sich das künftig ändert
https://docs.bsky.app/blog/blueskys-moderation-architecture#...
Dass die Unterschiede zwischen den beiden Ansätzen erklärt wurden, war gut.
Allerdings war es frustrierend, dass die Frage „Wie löst ATProto die Probleme, die Instanzen lösen?“ unbeantwortet blieb.
Wenn man Föderation zum Beispiel als irgendeinen unbekannten Grund abtut, warum man die Beiträge von Freunden nicht sehen kann, kann man die Frage „Wie löst atproto dann die Probleme, die Föderation löst?“ nicht beantworten.
Die naheliegende Grundantwort in diesem Framing ist: „Gar nicht.“
Auf Hosting-Ebene kann ein Hoster Accounts sperren, weil etwas eindeutig illegal ist, so wie blogspot.com oder Cloudflare in bestimmten Fällen blockieren.
Auf Anwendungsebene steuern App-Admins und Moderatoren nutzergenerierte Inhalte wie bei anderen Webdiensten, die mit User-Generated Content umgehen.
Es ist eine Entscheidung des App-Entwicklers; man kann wie bei Reddit grundlegende Bausteine für Moderation in Nutzerbereichen bereitstellen oder wie bei Bluesky einen separaten Moderationsdienst einstecken.
Da es nichts gibt, was einer „Community-Instanz“ entspräche, die sich mit anderen streiten könnte, gibt es auch keine Föderation. Es gibt nur Hosting, Apps und Moderation auf App-Ebene entsprechend den Entscheidungen der App-Entwickler.
Das ist im Kern sehr ähnlich zu dem, was Microsoft bei E-Mail macht. Außer den größten Anbietern werden Nachrichten verworfen, und de facto wird so föderiert, dass Nutzer Microsoft oder andere große etablierte Anbieter verwenden müssen, wenn sie Nachrichten zustellen wollen.
Neue Instanzen können dann keine Nachrichten zustellen und keine Nutzer gewinnen. Für große etablierte Anbieter entsteht ein pervertierter Anreiz, sich nicht mit neuen Instanzen zu föderieren.
Eine solche Architekturentscheidung verfestigt langfristig ein Oligopol.
Es heißt zwar, das sei zur Spam-Abwehr nötig, aber es gibt auch Anbieter, die das nicht tun, und wenn DKIM, Reverse DNS usw. korrekt eingerichtet sind, kommt man bei Gmail normalerweise trotzdem durch; sie haben auch nicht mehr Spam-Probleme.
Die naheliegende Alternative ist clientseitiges Filtern. Wenn Filter von Anbietern von Filterlisten mit einem Charakter wie uBlock bereitgestellt würden statt von Betreibern wie Microsoft, hätten diese keinen Anreiz, alle auf ihre eigene Instanz zu drängen, weil sie gar keine bestimmte Instanz betreiben.
Es sei denn, es gäbe sehr viele AppViews, die den gesamten Firehose konsumieren können, zwischen denen man frei wählen kann und die man selbst günstig betreiben kann.
ATProto ist eher das RSS einer Welt, in der man RSS nur über Google Reader oder einen Klondienst in derselben Größenordnung lesen kann, aber nicht über Desktop- oder mobile RSS-Reader.
Wenn es quakt wie eine Ente, ist es eine Ente.
Ein Account hat ein einzelnes PDS, und die DID zeigt auf das PDS als offiziellen Daten-Feed des Nutzers und als Schreibziel.
Die Daten können repliziert werden, aber das PDS gilt als maßgebliche Quelle.
Das ist einer Client/Server-Architektur sehr viel näher als einer verteilten Architektur.
Es gibt keine P2P-Datenbank, nichts wird in eine DHT oder an Peers geschrieben. Man schreibt in das PDS, und dieser Schreibvorgang wird optional gespiegelt.
Auch die Discovery läuft über DNS, also fragt man keine Peers nach Daten.
Mit Relays verbindet man sich nicht mit Peers, sondern als Client, der eine Kopie von Daten anfordert, die maßgeblich auf dem PDS gehostet werden.
Ich halte es nicht für abwegig, das PDS eine Instanz und Relays Spiegel zu nennen.
Es ist nur nicht dasselbe, was Leute, die über Mastodon sprechen, normalerweise mit „Instanz“ meinen.
Bei Mastodon ist eine Instanz ein untrennbares Bündel aus Datenhosting, App, Community und Moderation.
Ich verstehe es so, dass ATproto echte Dezentralisierung zugunsten von Konsistenz opfert, während Mastodon und ActivityPub echte Konsistenz zugunsten einer zugänglicheren Dezentralisierung opfern.
Der Betrieb eines ActivityPub-Knotens ist für normale Self-Hosting-Nutzer viel zugänglicher als der Betrieb eines Content-Relays für AT.
Was sich bei AT letztlich „dezentralisieren“ lässt, sind nur die eigenen Daten, und das kommt eher Dateneigentum gleich, als einen Teil des Netzwerks gemeinsam zu besitzen.
Das ist auch etwas, das auf HN schon mehrfach durchgekaut wurde.
Bei ActivityPub bedeutet das Betreiben einer Instanz, dass man für Daten, Anwendung und spätere Skalierungsprobleme insgesamt verantwortlich ist; man muss also entweder die Betriebsverantwortung selbst tragen oder an die Instanz anderer gebunden sein.
Selbst wenn einem die gewählte Instanz nicht gefällt und man wechseln will, muss man, falls sich daran noch nichts geändert hat, praktisch fast bei null anfangen.
Bei AtProto ist es leicht, mit derselben Identität zu einer anderen Application-Plattform zu wechseln, und die Daten von einer Plattform zu exportieren und selbst zu hosten ist zwar aus UX-Sicht schwierig, aber zumindest möglich.
Ich habe zum Beispiel kürzlich zum ersten Mal Tangled ausprobiert und konnte mich mit meiner bestehenden bsky-basierten Domain (
h14h.com) anmelden. Ich musste weder ein neues Konto noch einen neuen Benutzernamen anlegen; es war, als wäre ich dort bereits vorhanden gewesen.Die Konfiguration zum Self-Hosting eines git-Repositorys auf einem VPS war höchstens ein halber Nachmittag Arbeit und läuft als Backend-Service, um den man sich fast gar nicht kümmern muss.
Im schlimmsten Fall erscheint auf tangled.org ein Banner wie „Repository ist veraltet und möglicherweise nicht mit dem aktuellen Tangled kompatibel“, und das lässt sich beheben, indem man das Docker-Image mit der neuesten Version neu baut und ausrollt.
Architektonisch ist AtProto zwar definitiv schwerer zu durchdringen, aber ich denke, es tatsächlich mit Nutzern in Berührung zu bringen, ist viel einfacher.
In meinem Kopf ist das weniger ein einzelner Schieberegler als vielmehr ein Buffet aus Trade-offs.
Der Vollständigkeit halber: Auch in der AP-Welt betreiben Einzelpersonen und kleine Teams Relays, Mirrors, Caches und AppViews. Es stimmt nur, dass das mit wachsender Größe teurer werden kann.
AT bietet nicht nur Konsistenz, sondern auch ein gemeinsames Datenmodell über Apps hinweg.
Dadurch können Apps Inhalte anderer Apps referenzieren und rendern. Es ist eine Art Web aus typisiertem JSON, und unterschiedliche Apps sind Linsen auf dasselbe Netzwerk.
Jeder kann auf bestehenden Daten neue Erlebnisse aufbauen, und in AP gibt es kaum etwas Entsprechendes.
AP koppelt Daten an die App, während AT eher einem einzigen globalen Datenbankbestand nahekommt, den alle Apps abfragen und der die Daten der ganzen Welt enthält.
Ich verstehe nicht, warum Diskussionen immer bei den Relays hängenbleiben. Inzwischen kann man ein Relay, wenn man will, für grob 30 Dollar im Monat betreiben, oder man nutzt kostenlos Bluesky oder Community-Relays.
Viele Apps verwenden überhaupt keine Relays und verlassen sich stattdessen auf Community-Indizes wie Constellation(https://constellation.microcosm.blue/). Es gibt sogar Apps, die nicht einmal einen eigenen Server oder eine eigene Datenbank betreiben.
Ich würde aber eher umgekehrt argumentieren: dass ATproto dezentraler ist oder es zumindest werden will.
In der ActivityPub-Welt sind Identität, Anwendung und Hosting im Wesentlichen miteinander verknüpft.
Wenn ich Lemmy nutzen will, muss ich entweder auf dieser Lemmy-Instanz ein zweites dauerhaft getrenntes ActivityPub-Konto anlegen, oder ich kann Lemmy nur in dem Maße nutzen, wie meine Mastodon-Instanz Nachrichten senden kann, die Lemmy versteht.
Jede neue ActivityPub-App schafft neue Interoperabilitätsprobleme, weil jede App ihre eigene Identität und ihr eigenes Hosting besitzt.
Es gibt keine Möglichkeit, dass meine selbstgehostete Mastodon-Instanz einem Lemmy-Server meine Identität bereitstellt und dieser Lemmy-Server dann meiner Instanz sagt, sie solle Inhalte in meinem Namen hosten.
Um das Niveau zu erreichen, von dem ATProto spricht, wäre mindestens das nötig. Ich weiß nur nicht, wie sehr das auf das tatsächlich existierende ATProto zutrifft, und auch das tatsächlich existierende ActivityPub ist nicht so interoperabel, wie seine Befürworter behaupten.
Dieser Blog erklärt die Architektur gut.
Aber in der Praxis dachte ich immer, das „Problem“ sei, dass das Unternehmen Bluesky die Haupt-App betreibt und den Großteil der Nutzerdaten hostet.
Auf Protokollebene ist es dezentralisiert, aber als reales System ist es aus Sicht der Kontrollinstanz immer noch stark zentralisiert.
Das soll nicht heißen, dass es unbedingt Blueskys Schuld ist, aber bisher scheint es sich doch so entwickelt zu haben.
Dieses Problem ist weder Bluesky noch ATProto eigen; ob gewinnorientierte Organisation, Non-Profit oder Freiwilligengruppe, irgendwer findet immer etwas, woran man Anstoß nehmen kann.
Ich habe auch keinen Interessenkonflikt mit Bluesky, außer dass ich früher Nutzer war und kein Investor. Im Rahmen meiner Möglichkeiten verstehe ich das Protokoll, das Unternehmen und auch die Website.
Die Seite und die App funktionieren gut. Die Leute sind viel zu sehr darauf fixiert, Probleme zu suchen, statt größere und bessere Lösungen zu bauen.
Die meisten wollen keine provisorischen P2P-Lösungen wie Lemmy oder Mastodon. Sie wollen, dass die Inhalte an einem Ort sind und dass man eine verantwortliche Stelle dafür benennen kann.
Deshalb glaube ich, dass sich P2P-soziale Netzwerke niemals durchsetzen werden. Rund um Lemmy und Mastodon gab es mehr Drama als bei Twitter, Reddit und Facebook zusammen.
Das sind meine 2 Cent, und meine Partnerin bzw. mein Partner und meine Freunde scheinen das genauso zu sehen.
Sowohl in der Theorie als auch in der Praxis ist es dezentralisiert.
Da Bluesky aber den größten Teil betreibt, kann man sagen, dass es auf Community- oder Mindshare-Ebene nicht dezentralisiert ist, auch wenn sich das ebenfalls verändert.
Es wird nur gesagt, dass es „keine Instanzen“ gebe, aber nicht erklärt, wie diese Architektur Probleme wie Authentifizierung, Synchronisierung und Discovery umgeht.
Die Wahl von Google Reader als Vergleich fühlt sich unheilvoll an
RSS hat das Ende von Google Reader zwar überlebt, aber nicht alle Communities, die RSS nutzten, haben überlebt, und viele von ihnen wissen bis heute nicht, was RSS ist
Einerseits zu behaupten, es sei dezentralisiert, und dann immer wieder auf die massive soziale Zentralisierung des dezentralen Ökosystems als positives Beispiel zu verweisen, wirkt fast schon freudianisch
Vor allem kennen wir das Ende bereits
Google Reader bündelte viele RSS-Heime zu einem, fügte Mehrwert wie Social Graph und Kommentare hinzu, brach dann aber durch die Launen von Google-Führungskräften zusammen, tötete RSS beinahe und zerstörte einen beeindruckenden Social Graph
Mit so einer Analogie entsteht kein großes Vertrauen in ATProto
Apps indexieren ihn nur
Deshalb könnte in dieser Analogie jeder denselben Graphen nutzen, um Google Reader wiederzubeleben oder damit zu konkurrieren
Falls es interessiert: http://leaflet.pub funktioniert derzeit tatsächlich so
Man muss sich nur vorstellen, dass man keine Desktop- oder mobilen RSS-Reader nutzen kann und RSS nur über Google Reader oder ähnlich große Klondienste lesen kann
Erst kürzlich hat noch jemand NetNewsWire erwähnt
Der wichtige Unterschied ist, dass Blogs ihre eigene Website haben und im RSS-Feed nicht zwingend der vollständige Beitrag stehen muss
Bei Bluesky funktioniert das normalerweise nicht so. Alles auf dem PDS wird repliziert
Außerdem wird dazu ermutigt, komplette Blogbeiträge in den PDS zu stellen, damit sie sich leicht replizieren lassen
Dann kann jeder, der indexieren will, eine Kopie mitnehmen, und man hat keine Kontrolle darüber, was sie damit tun
Zwingend ist das nicht. Man kann den Blog auf der eigenen Website hosten und bei Bluesky nur den Link posten
Einen HTTP-Frontend auf ein atproto-Konto zu setzen, ist die empfohlene Vorgehensweise, und tatsächlich machen das viele
Ich mache das auf pfrazee.com ebenfalls so, und meine leaflet-Blogposts, deren maßgebliche Version in atproto liegt, werden auch in meinem Blog gerendert
Der RSS-Vergleich ist irreführend
Atproto-Apps sind nicht wie RSS-Reader, die auf dem Computer des Nutzers laufen und sich direkt mit der Quelle der Inhalte verbinden
Atproto-Apps sind Server, die die Inhalte kontrollieren, filtern und formen, die dem Leser angeboten werden
Atproto-Apps können nach Belieben zensieren, shadowbannen, Werbung ausspielen und Feeds algorithmisieren
Nutzer sind machtlos, und Kreative bleiben als Opfer zurück, denen nichts bleibt als zu klagen
Dass jeder die Daten irgendwo hosten kann, ist völlig bedeutungslos, wenn es keinen Weg gibt, diese Daten zu verteilen
Erstens kann man andere AppViews nutzen, die so etwas nicht tun
Feeds können so algorithmisiert werden, wie Nutzer es möchten, und wenn es mehrere Apps gibt, ist man nicht an den Algorithmus eines einzigen zentralen Anbieters gebunden