Fediverse- und Einzelbenutzerinstanzen.
Ich bin mir nicht sicher, ob ich sagen kann, dass eine Instanz mit 7 Benutzern wie meiner (einschließlich meiner Cousine: Sag mir nicht, dass ich Frauen hasse) keine persönliche Instanz ist. Das fedeverse hat jedoch einige Instanzen mit weniger als zehn Benutzern und viele mit „nur“ einem Benutzer. Diese Situation ist definitiv die Killer-App des Fedevers, aber sie stößt (meiner Meinung nach) auf einen Fehler im Softwaredesign.
Das Problem ist hier nicht das Protokoll, sondern das Design der Software, die die Instanz ausführt. Stellen Sie sich vor, Sie sind eine Instanz mit einem einzelnen Benutzer und Sie haben gerade mit der Fedever begonnen. Bevor Sie mit anderen interagieren können, müssen Sie sich verbünden.
Föderieren bedeutet in aktuellen Implementierungen Folgendes: Sobald der Benutzer meiner persönlichen Instanz einem Benutzer einer anderen Instanz folgt, sagen wir einer großen mit einer Million Benutzern, beginnt die Instanz mit einer Million Benutzern, alles an die persönliche Instanz zu senden Nachrichtenverkehr, der als „öffentlich“ gekennzeichnet ist. Diese Botschaften werden sich häufen, um in der persönlichen Instanz die „verbundene Zeitachse“ aufzubauen.
Dies ist eindeutig ein absurdes Design: Viele Instanzen, die für wenige Benutzer entwickelt wurden, verwenden ein einfaches sqlite3 als Datenbank. Was so gut wie möglich skaliert, aber verstehen Sie gut, dass wir, wenn wir mit Instanzen von einer Million Benutzern oder sogar hunderttausend Benutzern föderieren, am Ende eine Datenbank haben werden, die, wie großartig sqlite3 auch sein mag, an Leistung verliert. Und wir werden wahrscheinlich nie eine der Nachrichten lesen.
Warum ist dieses Design so wichtig?
In der Pionierzeit des Fediverse, und wenn wir zurück zu den Tagen von pump.io oder Ostatus, Diaspora oder anderen gehen, bestand das Problem darin, „einen Stream zu erstellen“. Die Benutzer erwarteten, dass sie Zeit damit verbringen würden, einen „Strom“ von Informationen zu lesen, was in den Anfangsjahren von fedeverse nur auf Kosten des Duplizierens von allem und des Sendens einer Kopie an so viele Server wie möglich geschehen konnte.
Andererseits war es sehr schwierig, auf einem wenig genutzten Ding wie pump.io echte Freunde zu finden: Dadurch wollte jeder neue Freunde finden, sonst würde das soziale Netzwerk seine soziale Komponente verlieren. Die föderierte Zeitleiste diente daher hauptsächlich dazu, neue Leute zu finden, denen sie folgen konnten.
Ich erinnere mich, dass es einige Gemeinschaften gab: Sie waren im Allgemeinen Hausbesetzer und Vereinigungen vom Typ „Volksfront von Judäa“, mit denen nur wenige etwas zu tun haben wollten. Infolgedessen war es vollkommen in Ordnung, eine kontinuierliche Stromlinie von Beiträgen zu haben, über Leute zu lesen, die interessant schienen, und sie als „gefolgt“ auszuwählen.
Dieser katastrophale Designfehler, der zunächst eine Notwendigkeit verdeckte, ist in den heutigen Fällen erhalten geblieben, wobei der anfängliche Fehler fast vergessen wurde: Es war nicht beabsichtigt, Nachrichten zu verteilen. Das Bedürfnis, das erfüllt werden musste, war , Konten zu verteilen, um Leute zu treffen.
Wenn es einen Strom aus neuen Konten gegeben hätte, die jede Instanz zusammen mit dem "Bios" neuer Benutzer verbreitet hätte, hätte dies wahrscheinlich das Benutzerproblem (das Problem, neue Leute kennenzulernen) mit viel weniger Ressourceneinsatz gelöst.
Heutzutage wäre es viel besser, wenn die „verbundene Zeitachse“ ein Strom von neuen Benutzern, gelöschten Benutzern oder verschobenen Benutzern wäre, die Instanzen teilen. Die Idee wäre, ihre „Biografie“ zu lesen und zu entscheiden, damit eine neue Instanz „verbunden“ wird, ohne DDOS-Ed mit nutzlosen Nachrichten von zufälligen Menschen auf der ganzen Welt zu erhalten.
Diese Art der Zielanalyse ist jedoch nicht sehr verbreitet. Das Motto der modernen Programmierer lautet „cool vor wichtig“, und daher fragen sie nicht, was für die Implementierung wichtig ist: Sie fragen, was für die Implementierung „cool“ ist.
Sicherlich war eine föderierte Zeitleiste, in der Diskussionen zufälliger Personen flossen, cool: In sozialen Netzwerken wurde es vor einigen Jahren als „Livestream“ bezeichnet. Es war cool. Es ist ein nutzloser (und oft langweiliger) Strom von Unsinn, der von dummen Leuten geschrieben wurde, aber vor Jahren war es cool . Und weil „cool vor wichtig“ ist, sprangen Programmierer darauf an.
Tatsächlich könnte ein guter Programmierer die Anforderung sogar verfeinern: Die Person, die eine Instanz startet, muss keinen Livestream oder gar die vollständige Liste der Benutzer anderer Instanzen haben. Es braucht eine Möglichkeit, andere Instanzen über seine Existenz zu informieren und über die aktiven Benutzer anderer Instanzen Bescheid zu wissen. Auf diese Weise wäre die zu verschiebende Datenmenge von Zeit zu Zeit mit einer kleinen Delta-Di-Ausrichtung sogar noch geringer.
Aber warum ist das wichtig?
Wie gesagt, Einzelbenutzerinstanzen oder solche für wenige Benutzer sind so konzipiert, dass sie eine geringe Auswirkung haben, dh wenig Ressourcen verbrauchen. Einige, wie Pleroma oder Akkoma oder Misskey, verwenden eine Postgres-Datenbank (wiederum, weil „cool before of important“) und können (durch sorgfältiges Einstellen eines automatischen Vakuums und einer automatischen Analyse) mithalten, aber Software, die beispielsweise auf sqlite3 ausgeführt wird , wird nach ein paar GB Unsinn, der von großen Instanzen empfangen wird, abgebaut.
Im Design moderner Instanzen, insbesondere Mastodon, gibt es immer noch viele dieser „Skelette“, dh unsinnige Gewohnheiten und Erfindungen aus alten Zeiten, die ein Benutzererlebnis ruinieren, das noch besser sein könnte, wenn wir nur nicht darauf bestehen würden diese prähistorischen Merkmale am Leben zu erhalten.
Das Activity-Pub-Protokoll ermöglicht schließlich den Austausch von Benutzern und deren Bios. Es gibt also keinen Grund, nicht nur aktive Benutzer (die gesehen werden wollen) an die föderierten Server zu senden. Und andererseits gibt es keinen Grund, kleinere Instanzen mit der Arbeitslast der großen Server zu töten.
In einigen Software gibt es eine Lösung. Auf Akkoma und Pleroma gibt es die Option, eine riesige Instanz in „Nur Follower“ zu platzieren, was bedeutet, dass Sie den Austausch auf Benutzer beschränken können, die sich gegenseitig abonniert haben. Bei Mastodon entspricht dies der Option „Silence“. , wodurch der gleiche Effekt wie bei der Begrenzung des Datenverkehrs erreicht wird, wobei weiterhin die "Benutzerverfolgung" zwischen den Instanzen zulässig ist. Misskey kann diesen Effekt auch erzielen, wenn auch nicht im Detail dokumentiert, indem die Föderationsseite in der Systemsteuerung verwendet wird.
Einfachere Software wie Honk oder gotosocial oder Ktistek, die für kleine Instanzen entwickelt wurden, haben keine derartigen Verteidigungswerkzeuge, mit dem Ergebnis, dass sie, wenn sie sich mit einem Benutzer einer großen Instanz zusammenschließen, eine Flut von Mist erhalten, die der Benutzer, oft ein einzelner, interessiert sich nicht dafür.
Eine andere Frage, die Ihnen in den Sinn kommen könnte, lautet: „Aber warum sind kleine Instanzen gut?“
Die Vorteile sind vielfältig. Erstens die Möglichkeit einer viel granulareren Moderation und ein besseres Vertrauensverhältnis zum Moderator. (Wenn es sich bei der Instanz um eine Einzelbenutzerinstanz handelt, ist der Benutzer natürlich auch Moderator.)
Der zweite Punkt ist, dass das Sammeln von Daten aus Tausenden von Instanzen selbst durch Scraping nicht so einfach ist wie das Scraping von riesigen Instanzen. Und in dieser Hinsicht scheint die „föderierte Zeitleiste“ speziell dafür ausgelegt zu sein, der NSA zu ermöglichen, Daten zu sammeln. Sollte es meiner Meinung nach gar nicht geben.
Der dritte Punkt ist die Datensicherheit. Wenn wir uns vorstellen, dass die fünf Millionen Benutzer des Fediverse in Instanzen von durchschnittlich 10 Benutzern aufgeteilt wurden, müsste der Hacker fünfhunderttausend verschiedene Server angreifen, um die Daten von fünf Millionen Benutzern zu erhalten (eine allzu mikroskopische Datenpanne). mit unterschiedlichen Abwehrmaßnahmen, unterschiedlichen Architekturen, unterschiedlicher Software und unterschiedlichen Schwachstellen. Es wäre eine riesige Aufgabe, eine allzu kleine Menge an Daten zu erhalten.
In diesem Sinne müsste das „ideale Fediverse“ aus kleinen Instanzen bestehen, die vom Geek betrieben werden, der dann Freunde beherbergt, oder aus der kleinen Firma, die lokale BBS betreibt. Früher kam es immer wieder vor.
Kleine Instanzen würden dann „in gewisser Weise“ eine bessere globale Situation schaffen: Der Grund, warum mehrere Instanzen „maßstäblich konzipiert“ sind, ist wiederum das gleiche „cool before of important“, das das heutige Softwaredesign antreibt (und plagt).
In den etablierten sozialen Netzwerken wird alles an der Anzahl der Benutzer gemessen. Die Anzahl der Benutzer, Follower und Likes ist der neue SUV: Größe spielt keine Rolle, sicher, aber wenn IHRE Größe keine Rolle spielt, können Sie entweder einen großen SUV kaufen oder viele Follower haben.
Diesem Gedanken folgend sind alle Instanzen so konzipiert, dass sie Programmierzeit mit Blick auf die Skalierbarkeit aufwenden, anstatt Zeit darauf zu verwenden, einigen Benutzern ein besseres Erlebnis und insbesondere eine viel einfachere Einrichtung des Ganzen zu bieten.
Wenn es eine einfache Möglichkeit gäbe, einen Knoten zu hosten, beispielsweise eine kleine Box, die an den eigenen Heimrouter angeschlossen und mit wenigen Klicks eingerichtet werden kann, würde sich das Fediverse meiner Meinung nach leichter erweitern als die aktuelle Situation. Da die kleine Box natürlich klein wäre, müsste sie für wenige Benutzer und eine geringe Datenspeicherung ausgelegt sein. Was aus Mainstream-Sicht nicht cool genug ist.
Also noch einmal: Selbsthosten von kleinen/persönlichen Instanzen ist der beste Weg, um das Fed-Diversum aufzubauen: Das Problem ist schlechte Entwicklung, wegen schlechter Entwickler, Codierung unter dem Motto „cool vor wichtig!“
Wird sich dies in Zukunft ändern? Nun, um ehrlich zu sein, MUSS ES sich ändern.
Wir können es jedes Mal sehen, wenn es eine Welle von Migranten von Twitter gibt: Die großen Instanzen können die neue Last nicht halten und fangen an, die Benutzer zu bitten, woanders hinzugehen. Der Kampf ist bereits da: Die Systemarchitektur ist eine harte Geliebte, und es gibt keine Möglichkeit zu schummeln.
Bisher sehen wir einen kleinen Prozentsatz von Twitter-Nutzern, die zum Fediverse wechseln, und dennoch leuchtet das Thema vergangener Architekturfehler auf. Stellen Sie sich nun vor, dass 50 % der Facebook-Nutzer migrieren.
Was würde passieren?
Nun, es würde mit jedem Architekturfehler passieren, den ich in den letzten 28 Jahren der IT gesehen habe: Menschen, die rund um die Uhr arbeiten, um vergangene Architekturschulden zu beheben.