Mastodon Maschinenraum
chaos.social-Admin Leah Oswald berichtet über ihre Erfahrungen
Leah Oswald hat die Mastodon-Instanz chaos.social mit aufgebaut, die mit über 10.700 Usern zu den Schwergewichten im dezentralen sozialen Netzwerk gehört. Im Gespräch mit c’t erklärt sie, wie chaos.social funktioniert und warum beim Wachstum Kontrolle wichtig ist.
Das dezentrale soziale Netzwerk Mastodon ist seit der Übernahme von Twitter durch Elon Musk schnell gewachsen. Anders als andere soziale Netzwerke wird Mastodon nicht von einem Unternehmen kontrolliert, sondern setzt sich aus vielen großen und kleinen Instanzen zusammen, die miteinander kommunizieren können. Grundsätzlich kann jeder eine eigene Mastodon-Instanz aufsetzen und damit einer Community ein Zuhause geben. Leah Oswald administriert chaos.social und erklärt im c’t-Interview, worauf man beim Aufsetzen einer eigenen Instanz achten sollte.
c’t: Du hast 2017 die Mastodon-Instanz chaos.social mit aufgebaut und bist dort Administratorin. Was ist das für eine Gemeinschaft?
Leah Oswald: Die Community hat sich in den letzten Monaten sehr dynamisch entwickelt. Ursprünglich haben wir die Instanz aufgesetzt, um den Menschen rund um den Chaos Computer Club im Fediverse ein Zuhause zu geben, weil es das noch nicht gab. Mein Admin-Kollege rixx hat damals gesagt: „Es gibt da diese coole neue Software Mastodon, hast du nicht Lust, dass wir das für die Chaos-Community aufsetzen?“ Wir haben das zur GPN 2017 (Gulaschprogrammiernacht, ein CCC-Event, Anm. d. Red.) fertigbekommen und vorgestellt. Seitdem sind immer mehr Leute dazu gekommen. Irgendwann wurden es aber zu viele Menschen und wir haben auf ein Einladungssystem umgestellt, also konnten nur bestehende Mitglieder neue Mitglieder hinzufügen. Das hat bis vor Kurzem noch gut funktioniert.
Seit der Übernahme von Twitter durch Elon Musk hat sich die Entwicklung der Mitgliederzahlen sehr beschleunigt. Das waren teilweise bis zu 200 neue Accounts am Tag und sicher nicht mehr nur Freundes-Freunde. An diesem Punkt haben wir vorerst die Registrierung geschlossen, damit sich wieder ein Gemeinsamkeitsgefühl entwickeln kann.
c’t: Wie viele User sind aktuell auf eurer Instanz registriert?
Oswald: Wir haben circa 10.700 registrierte Mitglieder. Das hatte sich bis zur Ankündigung von Musks Twitter-Plänen sehr linear entwickelt. Plötzlich haben sich in ein paar Tagen 1500 Menschen registriert. Ende Oktober gab es den nächsten großen Schwung mit 2500 neuen Usern. Außerdem sind viele inaktive User wieder aktiv geworden. Die tatsächliche Zahl aktiver Accounts ist von 2000 auf 7000 angestiegen.
c’t: Ihr administriert die Instanz zu zweit. Wie sieht eure Arbeitsteilung aus?
Oswald: Ich kümmere mich vorrangig um die Technik und rixx übernimmt die Moderation und Kommunikation nach außen, beispielsweise in unserem Admin-Blog, und er macht die Dokumentation.
c’t: Wie seid ihr vorgegangen, als ihr eure Instanz aufgesetzt habt?
Oswald: Ich arbeite im Bereich IT-Infrastruktur als Leiterin eines Operation-Teams, deswegen konnte ich eine Menge Vorerfahrung einbringen. Mastodon haben wir mit einem Ansible-Playbook (ein Open-Source-Werkzeug zur Automatisierung und Konfiguration, Anm. d. Red.) installiert, das rixx gefunden hatte. Das Playbook haben wir über die Jahre weiterentwickelt. Anfänglich lief Mastodon noch in einer kleinen virtuellen Maschine mit vier Kernen und 8 GByte RAM. Die VM ist jedoch über die Jahre größer geworden. Bis Anfang 2022 war der Server schon auf 20 GByte-RAM, zehn CPU-Kerne und eine Reihe NVMe-SSDs angewachsen. Die flotten SSDs sind wichtig, weil sonst alles sehr langsam wird. Bis auf wenige Probleme mit Updates lief unsere Instanz ziemlich wartungsarm vor sich hin.
Nach dem großen Ansturm waren wir gezwungen, unsere Architektur zu überdenken und haben die Datenbank auf einen separaten Server ausgelagert. Jetzt haben wir eine VM mit dem Webinterface, dem Streaming-API und Redis als Cache sowie eine weitere VM, wo die Sidekiq-Worker laufen, die alle Jobs verarbeiten, die von intern oder extern kommen. Dazu gibt es einen externen Speicher, auf dem wir die Mediendateien ablegen. Das war eine Bedingung, um die Sidekiq-Worker auslagern zu können. Sonst hätte man ein geteiltes Dateisystem nutzen und Performanceabstriche machen müssen. Die Mediendateien liegen jetzt in einem S3-kompatiblen Object-Storage (ein skalierbarer Cloud-Speicher, Anm. d. Red.). Da setzen wir auf Minio.
c’t: Mastodon ist also keine Anwendung aus einem Guss. Welche Aufgaben erfüllen die einzelnen Komponenten?
Oswald: Der sichtbare Teil ist die Webkomponente, ein Webserver namens Puma, der in Ruby geschrieben ist. Dann gibt es das Streaming-API. Das kümmert sich darum, dass ich nicht immer die ganze Seite neu laden muss, wenn ich als Nutzer neue Toots sehen will, sondern das automatisch via WebSocket gestreamt wird. Die Redis-Datenbank dient als Cache für die Timeline und Benachrichtigungen, speichert und verwaltet aber auch Jobs für Sidekiq. Die Sidekiq-Worker verarbeiten Aktionen wie Likes und Toots, komprimieren Media-Uploads, holen Toots fremder Instanzen und generieren Link-Previews. All diese Aktionen werden in Warteschlangen einsortiert, die dann von Workern abgearbeitet werden. Dazu kommt unser S3-kompatibler Storage, also ein Webserver mit definiertem API, auf den ich Dateien hochladen und runterladen kann.
c’t: Ist ein externer Object-Storage Pflicht oder kann man auch das lokale Dateisystem nutzen?
Oswald: Ja, das geht, aber man sollte vorher nachdenken, wohin man mit der Instanz möchte. Bei einer Instanz bis 1000 Leuten sollte das lokale Dateisystem ausreichen. Wenn ich aber eine Community habe, von der ich glaube, dass sie schnell wächst, dann sollte man das von Beginn an mitdenken. Die Architektur später umzubauen, ist schwierig. Bis Oktober letzten Jahres haben wir Dateien noch lokal gespeichert. Dann mussten wir im laufenden Betrieb umbauen und 2,4 Millionen Dateien synchronisieren. Das hat zwei Tage gedauert und währenddessen war die Instanz sehr langsam.
c’t: Hast du noch mehr Tipps, die man beachten sollte, wenn man eine große Instanz aufziehen will?
Oswald: Wie bei jeder Software, die viele Menschen benutzen, sollte man auch bei Mastodon wissen, was man tut und sich der großen Verantwortung bewusst sein. Als Admin hat man Zugriff auf sensible Daten, und die Nutzer vertrauen einem. Deswegen sollte man unbedingt darauf achten, die Instanz sicher zu betreiben und regelmäßig Backups anlegen. Dazu sollten Security-Basics erfüllt werden, beispielsweise Zwei-Faktor-Authentifizierung für Admin-Accounts, SSH-Zugang nur mit passendem Schlüssel und man sollte darauf achten, Mastodon und die restliche Software auf dem Server aktuell zu halten.
Abgesehen vom technischen Aspekt ist die Moderation sehr wichtig. Ich würde niemandem empfehlen, eine Instanz mit mehr als hundert Leuten allein zu betreiben. Das kann dazu führen, dass die Moderation nicht hinterherkommt und die Instanz beispielsweise eine Anlaufstelle rechter Trolle wird. Wenn daraufhin andere Instanzen deinen Server blocken, war all die Arbeit umsonst. Ab 1000 aktiven Nutzerinnen und Nutzern sollte man sich Hilfe holen, beispielsweise um sich bei Moderationsentscheidungen eine zweite Meinung einzuholen. Grundsätzlich würde ich von Instanzen mit mehr als 20.000 Accounts abraten, auch weil dann der dezentrale Ansatz an seine Grenzen stößt.
c’t: Wie kann man für ein gutes Wohlfühlklima auf seiner Instanz sorgen?
Oswald: Wo viele Menschen zusammenkommen müssen unterschiedliche Wünsche und Ansprüche vermittelt werden. Das zu moderieren ist schwierig und man kann sich als Admin sicher sein, dass irgendwer immer mit einer Entscheidung unzufrieden ist. Als Nutzer kann man den Admins das Leben leichter machen, indem man die Instanzregeln liest und sich daran hält. Wenn ein Post klar gegen die Instanzregeln verstößt, dann sollte man ihn melden und eine Beschreibung des Problems mitliefern. Wenn es kein gravierendes Problem ist, dann reicht es meistens auch, den betreffenden Account einfach selbst zu blocken oder stumm zu schalten.
c’t: Ihr mietet für eure Instanz eine Menge Rechenleistung und steckt viel Zeit in Administration und Moderation. Wie finanziert ihr den Betrieb von chaos.social?
Oswald: Wir finanzieren uns hauptsächlich über Spenden. Dafür haben wir den Verein chaos-social e.V. gegründet. Ab einem gewissen Punkt des Wachstums mussten wir den Betrieb formalisieren, auch damit wir nicht mehr als Privatpersonen haften. Der Verein ist nicht als gemeinnützig eingetragen, dafür sind die Hürden sehr hoch und es bedeutet mehr Aufwand. An den Verein können User spenden, beispielsweise per Banküberweisung, PayPal und Liberapay. Andere Instanzen haben ähnliche Modelle und es ist durchaus gängig, dass sich User freiwillig an den Kosten beteiligen.
c’t: Du hast ja von dem großen Ansturm nach der Übernahme von Twitter durch Elon Musk gesprochen. Welche Stellschrauben hat Mastodon, damit eine Instanz kontrolliert wachsen kann?
Oswald: Eine Option ist, Registrierungen nur mit einer Einladung zuzulassen. Die Einladungslinks können bei uns von der Administration oder von Usern generiert werden. Das sorgt auch dafür, dass sich ein gewisses Vertrauensverhältnis entwickelt. Man kann potenzielle User auch einen Grund angeben lassen, warum sie Mitglied werden wollen, so wie eine „Mini-Bewerbung“. Registrierungen generell zu öffnen ist risikoreich. Ich kenne Instanzen, die innerhalb weniger Tage 30.000 neue Accounts hatten. Das ist ein Rezept für ein Desaster. Wir haben unsere Instanz außerdem so modifiziert, dass generierte Einladungslinks nur einmal benutzt werden können.
c’t: Viele Mastodon-Instanzen werden von Ehrenamtlichen gehostet. Was kann ich denn als Nutzer tun, wenn die keine Zeit mehr für ihre Instanz habe oder ich die Instanz aus anderen Gründen wechseln möchte? Kann ich als User meine Daten retten und umziehen?
Oswald: Ja, im Mastodon-Webinterface gibt es die Option, die eigenen Daten zu exportieren, beispielsweise als CSV-Tabellen, die Follows, geblockte Accounts und gefolgte Accounts enthalten. Diese Dateien braucht man, um auf eine andere Instanz umzuziehen. Sie lassen sich über das Mastodon-Webinterface importieren. Man kann aber nicht alle Daten mitnehmen. Alte Posts und angelegte Listen ziehen beispielsweise nicht mit um. (ndi@ct.de)