Fediverse

Wer sich mit sozialen Netzwerken wie Mastodon beschäftigt, wird den Begriff des Fediverse bereits gehört haben. Das Kofferwort, bestehend aus Federation und Universe, bezeichnet ein Netzwerk verschiedener sozialer Plattformen, die nicht von einem einzigen Anbieter betrieben werden, sondern auf vielen unabhängigen Servern laufen und mittels offener Protokolle miteinander verbunden sind.

Anders als in den klassischen Walled Gardens à la X, Facebook oder YouTube, wo jede Plattform ein geschlossenes System darstellt, können im Fediverse Nutzer plattformübergreifend miteinander interagieren. Oft genügt bereits ein einziger Account, um Inhalten über verschiedene Dienste hinweg zu folgen und zu kommentieren, z. B. um über Mastodon einem Pixelfed-Account zu folgen.

Ein Ausschnitt des Fediverse

Ein großer Vorteil der Föderation ist die Robustheit. Es gibt keinen Single Point of Failure. Fällt eine Instanz aus oder wird abgeschaltet, betrifft das nur dessen Nutzer, nicht aber das gesamte Netzwerk.

Spezial-Communitys können eigene Instanzen mit spezifischen Moderationsregeln oder Features betreiben, die auf ihre Bedürfnisse zugeschnitten sind. Nutzer haben die Wahl, sich einer Instanz anzuschließen, deren Ausrichtung und Richtlinien ihnen zusagen, oder selbst einen Server aufzusetzen.

Andererseits bedeutet die dezentrale Föderation auch, dass kein einzelner Akteur vollständige Kontrolle über Inhalte und Abläufe hat. Zentralisierte Netzwerke können schneller agieren, einheitliche Richtlinien durchsetzen und technisch einfacher skalieren, da alle Daten an einem Ort liegen.

Im Fediverse müssen sich die Betreiber der einzelnen Instanzen abstimmen, um z. B. Spam oder Missbrauch einzudämmen. Jede Instanz moderiert primär für sich. Auch sind föderierte Systeme komplexer. Der ständige Austausch zwischen Instanzen erfordert robuste Protokolle und kann die Infrastruktur bei hohen Aktivitätspeaks erheblich beanspruchen.

Im Rahmen des Artikels soll vorrangig auf den Teil des Fediverse eingegangen werden, der die ActivityPub-Spezifikation nutzt. Andere Mitglieder des Fediverse im weiteren Sinne, wie Bluesky als Nutzer des AT-Protokolls oder Diaspora mit dem gleichnamigen Protokoll, werden nur angerissen.

Geschichte

Der Grundgedanke von Dezentralität war schon früh im Internet verankert; das E-Mail-System ist bis heute ein anschauliches Beispiel für ein föderiertes Netzwerk. Jeder kann E-Mail-Server aufsetzen und in der Theorie ohne Probleme mit anderen E-Mail-Servern kommunizieren. Auch wenn es im E-Mail-System in den vergangenen Jahrzehnten zu enormen Zentralisierungen gekommen ist, ist es im Kern immer noch ein dezentrales System.

Mit dem Web der späten 90er und beginnenden 2000er Jahre entstanden persönliche Websites, Webringe, RSS/Atom-Feeds und frühe Blogging-Ökosysteme. Technisch dominierten zwar zentralisierte Plattformen wie Blogger.com, aber gleichzeitig gab es einen starken Drang zur Selbsthostbarkeit.

Besonders RSS und Atom können als gedankliche Vorläufer des Fediverse gelten, da sie schon früh das automatische Abonnieren von Inhalten über verschiedene Server hinweg ermöglichten.

OStatus

Sozial wurde Föderation im Web Ende 2008. Das damals von Evan Prodromou entwickelte Protokoll OpenMicroBlogging, ab 2010 OStatus genannt, kombinierte mehrere offene Standards, namentlich Atom, PubSubHubbub, Salmon und WebFinger, um Follower-Beziehungen, Status-Updates und Interaktionen serverübergreifend möglich zu machen.

Allerdings war OStatus technisch fragmentiert, schwer erweiterbar und bot keine echte Möglichkeit, komplexere Interaktionen standardisiert abzubilden.

Mit Identi.ca, welches 2008 gestartet wurde, und dem zugrunde liegenden Software-Stack StatusNet entstand das erste große föderierte Microblogging-Netzwerk. Später nutzten auch GNU social und Friendica Varianten des OStatus-Stacks.

Zeitgleich entwickelte sich mit Diaspora ab 2010 eine weitere föderierte Plattform, die auf einem eigenen Protokoll basierte, aber das Prinzip dezentraler, selbstverwalteter Instanzen ebenfalls konsequent umsetzte.

2013 wurde die Plattform Identi.ca auf pump.io migriert, woraufhin StatusNet faktisch eingestellt wurde. Auch wenn die pump.io-Plattform mittlerweile Geschichte ist, legte sie einige technische Grundlagen für das spätere ActivityPub.

Die im Juli 2014 gegründete W3C Federated Social Web Working Group entwickelte einen neuen Standard, welcher besagte Vorarbeit nutzte, um ActivityPub zu spezifizieren und zu standardisieren. Evan Prodromou fungierte hierbei als Mitautor. 2018 wurde ActivityPub schlussendlich als Webstandard verabschiedet.

ActivityPub erleichterte die Entwicklung dezentraler Plattformen erheblich. Mastodon, das anfangs noch OStatus unterstützte, setzte früh auf ActivityPub und wurde dadurch zum wichtigsten Motor des modernen Fediverse.

Wachstumsschmerzen

Neben der Vergrößerung des Fediverse durch neue Instanzen und Plattformen haben auch kommerzielle Anbieter das Fediverse für sich entdeckt.

So sorgte Meta für Schlagzeilen, als es mit Threads einen eigenen Microblogging-Dienst à la Twitter bzw. X startete und ankündigte, diesen mit ActivityPub kompatibel zu machen.

Die Reaktionen darauf waren im Fediverse gemischt. Einerseits sehen viele darin eine Stärkung der offenen Standards. Dennoch gibt es Bedenken, ob ein großer Player die Kultur des Fediverse verändert oder gar dominiert. Einige Mastodon-Instanzen kündigten prophylaktisch an, Threads gegebenenfalls zu blockieren, falls Meta versucht, zu viele Daten abzugreifen oder eigene Regeln zu diktieren.

Matt Mullenweg zeigte sich begeistert über das Fediverse und sieht darin eine Renaissance des offenen Webs. WordPress selbst kann nun per Plugin zu einem Fediverse-Teilnehmer gemacht werden, wenn auch mit Einschränkungen.

FediDB zeigt das Fediverse in Zahlen

Mittlerweile verfügt das Fediverse (laut FediDB, Stand Dezember 2025) über 12 Millionen registrierte Nutzer, davon sind etwa 890.000 Accounts aktiv, bei insgesamt 1,4 Milliarden Statusmeldungen und über 35.000 Instanzen bzw. Servern.

ActivityPub im Detail

Technisch betrachtet besteht die heutige Föderation aus zwei eng verzahnten Bausteinen. ActivityPub definiert die Mechanik der Kommunikation, also wie Clients Inhalte an einen Server senden und wie Server Aktivitäten an andere Instanzen verteilen.

Was dabei übertragen wird, legt ein zweiter Standard mit dem Namen ActivityStreams 2.0 fest. Dieses JSON-basierte Vokabular beschreibt die semantische Ebene, also welche Objekt- und Aktivitätstypen es gibt; von Note über Image bis zu Create, Like oder Follow.

Erst im Zusammenspiel beider Standards entsteht ein interoperables soziales Netzwerk. ActivityStreams liefert die Bedeutung, während ActivityPub den Transport, Zustellung und die Föderation übernimmt.

ActivityPub definiert zwei APIs. Zum einen eine Client-zu-Server-API (C2S), über die Nutzerinhalte auf dem eigenen Server erstellt, abgerufen oder gelöscht werden können. Zum anderen wird eine Server-zu-Server-API (S2S) definiert, über die föderierte Kommunikation zwischen verschiedenen Servern bzw. Instanzen erfolgt.

Während die C2S-API in der Theorie von den Clients, wie einer App oder einem Webinterface genutzt wird, wird die S2S-API für die Kommunikation zwischen den Servern genutzt.

Interessanterweise müssen nicht beide APIs implementiert werden. So implementiert z. B. Mastodon nur die S2S-API und nutzt stattdessen eine eigene Client-API.

Dies hängt damit zusammen, dass die Implementierung beider APIs optional ist und Mastodons eigene Client-API deutlich älter als ActivityPub ist. Dazu heißt es in der Spezifikation:

ActivityPub implementations can implement just one of these things or both of them.

Die Client-zu-Server-Seite von ActivityPub ist zwar spezifiziert, wird in der Praxis jedoch nur sehr begrenzt genutzt.

Die Energie floss bei den meisten Plattformen in das föderierte Server-zu-Server-Protokoll, dass die Dienste des Fediverse tatsächlich miteinander verbindet.

Actors

Nutzer in ActivityPub werden von einem sogenannten Actor repräsentiert und besitzen jeweils eine eindeutige Adresse, bestehend aus einem Nutzernamen und der Domain der Heim-Instanz.

Wichtig ist hierbei, dass zwischen dem Fediverse-Handle z. B. @alice@fedi.example und der eigentlichen Adresse (https://fedi.example/users/alice) unterschieden wird. Das Handle wird hierbei mehrheitlich mittels Webfinger zur URL aufgelöst. Technisch betrachtet werden Handles nicht in der ActivityPub-Spezifikation behandelt, da dort nur Actor-URLs erwähnt werden.

Ein Nutzer kann im Kontext von ActivityPub z. B. eine Person, eine Applikation, eine Gruppe, ein Service oder eine Organisation sein. Dazu heißt es in der Spezifikation:

ActivityPub does not dictate a specific relationship between „users“ and Actors; many configurations are possible. There may be multiple human users or organizations controlling an Actor, or likewise one human or organization may control multiple Actors. Similarly, an Actor may represent a piece of software, like a bot, or an automated process. More detailed „user“ modelling, for example linking together of Actors which are controlled by the same entity, or allowing one Actor to be presented through multiple alternate profiles or aspects, are at the discretion of the implementation.

In- und Outboxen

Jeder Actor verfügt über eine In- und eine Outbox. Die Inbox enthält die Nachrichten, die von außerhalb empfangen wurden, während die Outbox die zu sendenden Nachrichten enthält.

Wenn ein Nutzer einen neuen Beitrag absendet, landet dieser zunächst in der Outbox. Der Server sendet diese zu den Inboxen der Follower-Server.

Umgekehrt kommen eingehende Nachrichten anderer Instanzen in der Inbox des Nutzers an.

Follow und Accept

Damit ein Actor allerdings überhaupt entsprechende Nachrichten erhält, muss er mindestens einem anderen Actor folgen. Dies geschieht, indem er eine Follow-Activity an einen anderen Actor sendet. Der Remote-Server antwortet mit einer Accept-Activity, wenn er den Follow erlaubt.

Erst wenn der Ablauf erfolgreich abgeschlossen ist, gilt auf Protokollebene eine lokale Follow-Beziehung als etabliert. Nur dann beginnt der Server des Actors, neue Aktivitäten aus seiner Outbox an die Inbox des Followers zu pushen.

ActivityPub im Beispiel

Doch wie sehen die Operationen auf Protokollebene aus? Für den Fall, dass ein Nutzer einem anderen Nutzer folgen möchte, sendet seine Instanz eine Follow-Activity an die Inbox des Remote-Actors. In diesem Fall möchte Bob dem Nutzer Alice folgen:

POST https://fedi.example/users/alice/inbox
Content-Type: application/activity+json

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://social.example/users/bob/activities/follow-123",
  "type": "Follow",
  "actor": "https://social.example/users/bob",
  "object": "https://fedi.example/users/alice"
}

Was im Request nicht aufgeführt ist, aber faktisch zum Fediverse dazugehört, ist eine Signatur im Header:

Signature: keyId="https://social.example/users/bob#main-key",algorithm="rsa-sha256",headers="(request-target) host date digest",signature="..."

Unsignierte Requests werden von den meisten Plattformen grundsätzlich abgelehnt.

Mit der Follow-Activity ist allerdings noch keine Follow-Beziehung etabliert. Der Remote-Server entscheidet, ob die Anfrage genehmigt wird. Wenn ja, sendet er eine Accept-Activity zurück. Erst mit diesem Accept ist die Follow-Beziehung etabliert. In diesem Fall bestätigt Alice die Anfrage von Bob:

POST https://social.example/users/bob/inbox
Content-Type: application/activity+json

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://fedi.example/activities/accept-follow-123",
  "type": "Accept",
  "actor": "https://fedi.example/users/alice",
  "object": {
    "id": "https://social.example/users/bob/activities/follow-123",
    "type": "Follow",
    "actor": "https://social.example/users/bob",
    "object": "https://fedi.example/users/alice"
  }
}

Wenn der Nutzer nun einen Beitrag schreiben möchte, so erstellt er eine Create-Activity, die in die Outbox seiner Instanz gestellt wird. Von dort wird sie automatisch an die Follower verteilt. Im Beispiel setzt Alice einen Post ab:

POST https://fedi.example/users/alice/outbox
Content-Type: application/activity+json

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Create",
  "actor": "https://fedi.example/users/alice",
  "object": {
    "type": "Note",
    "content": "Hello, world!",
    "to": ["https://www.w3.org/ns/activitystreams#Public"]
  }
}

Der Remote-Follower empfängt die Nachricht in seiner Inbox:

POST https://social.example/users/bob/inbox
Content-Type: application/activity+json

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://fedi.example/users/alice/activities/create-123",
  "type": "Create",
  "actor": "https://fedi.example/users/alice",
  "object": {
    "id": "https://fedi.example/users/alice/posts/123",
    "type": "Note",
    "content": "Hello, world!",
    "to": ["https://www.w3.org/ns/activitystreams#Public"]
  }
}

Daneben sind natürlich auch andere Interaktionen, wie Likes im Rahmen der Kommunikation, möglich.

Protokoll-Fragmentierung

Auf dem Papier wirkt ActivityPub wie der gemeinsame Nenner des Fediverse. Ein Datenmodell, ein Protokoll und damit die Aussicht auf echte Interoperabilität.

In der Praxis zeigt sich jedoch ein paradoxes Bild. Trotz des gleichen Protokolls sprechen viele Plattformen unterschiedliche Dialekte. Es entsteht kein kohärentes Gesamt­netzwerk, sondern mehrere nur locker miteinander gekoppelte Subsysteme.

Ein Kernproblem liegt in der Architektur des Standards selbst. ActivityPub basiert auf ActivityStreams 2.0, und dieses Format ist absichtlich sehr flexibel und erweiterbar gestaltet. Viele Felder sind optional, Semantiken bleiben offen und unbekannte Eigenschaften müssen laut Spezifikation ignoriert werden. Required-Attribute werden stattdessen nur sehr sparsam eingesetzt.

So können zwei Plattformen vollkommen korrekt behaupten, ActivityPub zu unterstützen, und dennoch kaum sinnvoll miteinander kommunizieren. Eine Plattform sendet Objekte mit Mastodon-Erweiterungen, eine andere erwartet strikteres JSON-LD, eine dritte ignoriert Felder, die für eine andere Plattform essenziell sind.

Besonders sichtbar wird das am Beispiel Mastodon. Die Plattform ist mit Abstand die größte ActivityPub-Implementierung und gleichzeitig eine, die den Standard nur teilweise umsetzt.

Die Client-to-Server-API fehlt weitgehend, mehrere Activity-Typen werden nicht unterstützt und bei der Account-Migration setzt Mastodon auf ein eigenes Verfahren. Umgekehrt verlangt Mastodon Dinge, die ActivityPub selbst nicht vorschreibt. Dazu gehören HTTP Signatures für alle Server-zu-Server-Anfragen, bestimmte JSON-LD-Kontexte und diverse Mastodon-spezifische Felder.

Mitglieder des Fediverse

Im Fediverse existieren zahlreiche Dienste mit unterschiedlichen Schwerpunkten. Viele davon sind bewusst als Alternative zu bekannten zentralen Plattformen konzipiert. Einige dieser Plattformen werden im Folgenden vorgestellt.

Mastodon

Mastodon ist die bekannteste und mit Abstand größte Plattform im Fediverse. Es handelt sich um einen freien Microblogging-Dienst, der Twitter bzw. X ähnelt. Nutzer können kurze Texte mit Bildern, Umfragen usw. veröffentlichen und anderen Nutzern folgen.

Mastodon wurde 2016 vom deutschen Entwickler Eugen Rochko gestartet und hat insbesondere nach der Übernahme von Twitter durch Elon Musk massiven Zulauf erhalten. So stieg die registrierte Nutzerzahl innerhalb weniger Wochen sprunghaft an.

Mastodon im Browser

Für den Nutzer bietet Mastodon drei Feed-Spalten: die Home-Timeline (Beiträge der Accounts, denen man folgt), eine lokale Timeline (alles, was auf der eigenen Instanz gepostet wird) und die föderierte Timeline, die öffentliche Posts aus allen verbundenen Instanzen zeigt.

Mastodon selbst ist quelloffene Software unter der AGPLv3 und wird mittlerweile von der Mastodon gGmbH weiterentwickelt, finanziert u. a. durch Spenden. Technisch basiert die Plattform auf Ruby on Rails und React.

Lemmy

Für textbasierte Diskussionen, Linksharing und Community-Foren gibt es im Fediverse Lemmy. Dieses Projekt startete 2019 und ist ein freies, selbsthostbares Foren- und Link-Aggregator-System, das bewusst als Alternative zu Reddit entworfen wurde.

Eine Lemmy-Instanz

Inhalte werden in thematischen Unterforen, sogenannten Communitys, eingestellt. Andere Nutzer können Beiträge und Kommentare hoch- oder runterstimmen, und es gibt Diskussionsthreads.

Lemmy hat durch die Reddit-Turbulenzen einen Schub an Nutzern erfahren. Während es Anfang 2023 noch unter hundert Lemmy-Instanzen gab, wuchs die Zahl bis Juli 2023 auf über 1.500 an, mit rund 66.000 aktiven Nutzern pro Monat.

Manche großen Reddit-Communities haben Lemmy-Ableger gegründet, um eine zensurresistente, gemeinschaftskontrollierte Alternative in der Hinterhand zu haben. Trotz dieses Wachstums steht Lemmy noch am Anfang. Die in Rust geschriebene Software wird aktiv weiterentwickelt und ist unter der AGPL lizenziert.

Pixelfed

Pixelfed ist konzeptionell eine dezentrale Alternative zu Instagram. Die Plattform ging Ende 2018 an den Start und ermöglicht das Teilen von Fotos, Alben und Storys.

Pixelfed erinnert in seiner Oberfläche stark an Instagram. Es gibt einen Feed mit den Beiträgen der verfolgten Accounts, Bilder können gelikt, Hashtags genutzt, Fotos mit Ortsangaben versehen und Storys gepostet werden.

Pixelfed ist ebenfalls quelloffen und unter der AGPL lizenziert und wird vom Entwickler Daniel Supernault verantwortet. Technisch basiert es auf PHP und Laravel.

PeerTube

PeerTube ist das Fediverse-Pendant zu YouTube. Es wurde ab 2017 vom französischen Non-Profit-Verein Framasoft entwickelt, um eine Alternative zu zentralisierten Videoportalen wie YouTube, Vimeo oder Dailymotion zu bieten.

Die PeerTube-Instanz der Blender Foundation

Technisch setzt PeerTube auf ActivityPub und ergänzt es um Peer-to-Peer-Technologie, um die Belastung einzelner Server bei populären Videos zu reduzieren.

Es erfreut sich insbesondere in Europa zunehmender Beliebtheit bei öffentlichen Einrichtungen und der Open-Source-Community. Daneben nutzen einige Content Creator PeerTube als werbefreie, datenschutzfreundliche Ergänzung zu YouTube.

PeerTube hat auch institutionelle Adoption erreicht. Der Europäische Datenschutzbeauftragte betrieb das Portal EU Video auf PeerTube-Basis im Rahmen einer Pilotphase, nach deren Ende der Betrieb erst einmal nicht fortgesetzt wurde.

PeerTube ist freie Software und unter der AGPL lizenziert. Technisch setzt PeerTube auf TypeScript, mit einem Node.js-Backend und einem Angular-Frontend.

Mobilizon

Bei Mobilizon handelt es sich um eine Plattform für die Organisation von Veranstaltungen und Gruppen und stellt damit das Fediverse-Pendant zu Facebook Events oder Meetup.com dar.

Mobilizon wurde ebenfalls von Framasoft initiiert und im Oktober 2020 in Version 1.0 veröffentlicht. Die Idee dahinter war, zivilgesellschaftlichen Gruppen, Vereinen oder einfach Freundeskreisen ein Werkzeug zu geben, um Veranstaltungen zu erstellen, Teilnehmer einzuladen und sich zu koordinieren.

Die Software ist in der Programmiersprache Elixir geschrieben und nutzt als Frontend das JavaScript-Framework Vue.js. Es ist unter der AGPL lizenziert und damit freie Software.

Friendica

Friendica gehört zu den ältesten Föderations-Plattformen und besticht durch eine breite Protokollunterstützung im Fediverse. Gestartet bereits 2010 unter dem Namen Mistpark, war Friendica lange vor ActivityPub verfügbar und unterstützt bis heute mehrere Protokolle parallel.

Friendica kann als eine Art föderiertes soziales Netzwerk à la Facebook betrachtet werden. Es bietet klassische Social-Media-Funktionen, einen Nachrichtenstream, Freunde/Follow-System, Kommentare, Gruppen, Direktnachrichten und Fotoalben.

Friendica-Server können sich einerseits untereinander verbinden, andererseits aber auch Inhalte und Kontakte von externen Netzwerken einbinden. So lassen sich in einem Friendica-Account Kontakte von Diaspora, GNU social und seit einiger Zeit auch ActivityPub-Diensten wie Mastodon oder Pixelfed integrieren.

Friendica ist ebenfalls freie Software unter der AGPL und wird von einer Community entwickelt. Als selbst gehostete Lösung ist es relativ anspruchslos und kann auch auf kleinen Webservern betrieben werden.

Sonstige Dienste

Neben den bekannten Schwergewichten existiert im Fediverse eine ganze Reihe weiterer Dienste, die jeweils eigene Nischen adressieren.

So sieht sich Funkwhale etwa als föderiertes Pendant zu SoundCloud, Castopod als moderne Podcast-Hosting-Plattform, WriteFreely als Blogging-Plattform oder BookWyrm als soziale Heimat für Leser, vergleichbar mit Goodreads.

Fediverse in der Praxis

In der praktischen Nutzung des Fediverse stößt der Nutzer auf eine Reihe von Eigenheiten und Mechanismen, die sich von klassischen, zentralisierten Plattformen unterscheiden und daher besondere Aufmerksamkeit verdienen.

Instanzauswahl

Die Wahl einer Instanz wirkt auf den ersten Blick wie die Entscheidung für einen E-Mail-Provider. So sorgt die Föderation schließlich dafür, dass Dienste miteinander sprechen können. Doch in der Praxis hängt die Nutzung stark davon ab, wo man sich niederlässt.

Jede Instanz bringt ihre eigene Kultur, Moderationsregeln und technischen Rahmenbedingungen mit. Diese Unterschiede prägen den Alltag deutlicher als neue Nutzer es oft erwarten.

Besonders relevant ist der Fokus auf die Community. Ob Microblogging, Fotoplattform, Wissenschaft, Gaming oder Bücher. Praktisch für jeden sozialen Mikrokosmos existiert eine passende Instanz im Fediverse.

Die Instanzgröße verändert das Nutzungserlebnis spürbar. Kleine Knoten liefern Nähe und kurze Wege zur Moderation, mittlere Instanzen eine gute Balance, große Instanzen hohe Aktivität, aber auch mehr Rauschen.

Auch die technischen Parameter bestimmen die Alltagstauglichkeit. Von Uptime, Serverlast über Softwarestand und der Frage, welche externen Instanzen blockiert oder eingeschränkt werden. All das bestimmt, welche Inhalte sichtbar werden und welche außen vor bleiben.

Ein oft unterschätzter Punkt ist die finanzielle und organisatorische Nachhaltigkeit. Viele Instanzen werden ehrenamtlich betrieben; wenn Administratoren aussteigen oder Kosten steigen, kann ein Server verschwinden. Verschwindet die Instanz, auf der der eigene Account liegt, gehen sämtliche Daten verloren und sind nicht mehr abrufbar.

Hier sind in der Theorie Protokolle wie Zot bzw. Nomad im Vorteil, die nomadische Identitäten ermöglichen und nicht an eine einzelne Instanz gebunden sind.

Praktische Helfer, wie Fedi.Garden, Instances.social oder die Join-Fediverse-Guides z. B. joinfediverse.wiki erleichtern die Orientierung, ersetzen aber nicht den Blick auf Community, Governance und technische Basis einer Instanz.

Account-Migration

Je nach Plattform gestaltet sich die Account-Migration auf den Fediverse-Plattformen schwierig. So sind bestimmte Dinge semi-automatisiert, wie die Followerübertragung bei Mastodon, während Inhalte wie Posts nicht automatisch übertragen werden.

Die zentrale Limitierung bleibt die providergebundene Identität. ActivityPub verankert Identitäten in URIs, die den jeweiligen Server-Hostnamen enthalten. Damit sind Identitäten praktisch nicht portabel.

Bei einem Serverwechsel bleiben die historischen Post-URLs an die alte Instanz gebunden. Externe Links und Einbettungen verweisen weiterhin auf den alten Host und werden unbrauchbar, sobald dieser verschwindet. Modelle wie Bring-Your-Own-Domain oder W3C-DIDs könnten dieses Problem theoretisch lösen, existieren aber praktisch in keiner größeren Implementierung.

Fazit

Das Fediverse ist längst kein experimentelles Nischenprojekt mehr, sondern die bislang reifste Alternative zu zentralisierten Social-Media-Plattformen.

Die Stärken sind funktionierende Dezentralisierung, Community-Governance, Open-Source-Innovation und ein Rückzugsort jenseits kommerzieller Plattformlogiken.

Gleichzeitig bleiben die offenen Fragen erheblich. Finanzielle Nachhaltigkeit, Skalierbarkeit, moderationsfähige Strukturen bei Wachstum und echte Widerstandsfähigkeit gegenüber kommerzieller Vereinnahmung.

Aktuelle Forschung zeigt zudem nüchtern, dass die Idealvorstellung radikaler Dezentralität in der Praxis stark relativiert wird. Die Mehrheit der aktiven Nutzer konzentriert sich auf wenige große Instanzen, und mit Threads drängt erneut ein Player mit deutlicher Dominanz ins offene Ökosystem.

Auch klassische Lock-ins bestehen fort, etwa die fehlende Post-Migration oder eingeschränkte Interoperabilität zwischen Implementierungen.

Ob das Fediverse sich langfristig etabliert, hängt von einigen Faktoren ab: belastbare öffentliche Förderung, institutionelle Adoption durch Verwaltungen, Medien und Wissenschaft, Skalierung und Verschlüsselung sowie Governance-Modelle, die Koordination ermöglichen, ohne zentrale Kontrolle.

Ebenso zentral ist eine gesunde, einladende Community-Kultur, die bei weiterem Wachstum nicht verloren gehen darf.

Letztlich bleibt das Fediverse eine der spannendsten Entwicklungen des modernen Webs. Es erinnert an die frühen Ideale des Internets; offen, föderiert, interoperabel und zeigt, dass Alternativen zu den klassischen Monopolplattformen tatsächlich funktionieren können.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Teilzeit diffamieren heißt Verantwortung verweigern

Lifestyle-Teilzeit. Dieser Begriff transportiert ein Weltbild. Ein solches, in dem bestimmte Arten der Teilzeit kein legitimes Arbeits- und Lebensmodell sind, sondern eine bequeme und egoistische Freizeitentscheidung.

Die Debatte darüber entspann sich an einem geplanten Antrag der CDU-Mittelstands- und Wirtschaftsunion (MIT). Dieser Antrag, mit dem Titel Kein Rechtsanspruch auf Lifestyle-Teilzeit soll nach Wunsch der MIT auf dem Bundesparteitag der Union im Februar dieses Jahres beschlossen werden.

Definitionsfrage

Die Definition von Teilzeitarbeit ergibt sich im deutschen Recht aus dem Teilzeit- und Befristungsgesetz. Dort heißt es in Paragraf 2:

Teilzeitbeschäftigt ist ein Arbeitnehmer, dessen regelmäßige Wochenarbeitszeit kürzer ist als die eines vergleichbaren vollzeitbeschäftigten Arbeitnehmers.

Überspitzt könnte dies bedeuten, dass bereits eine 39-Stunden-Woche definitionsgemäß Teilzeit ist. Andere Definitionen, etwa in OECD-Statistiken, setzen die Grenze für Teilzeit häufig bei einer Wochenarbeitszeit von maximal 30 Stunden an.

Was sich zeigt, ist, dass Teilzeit kein Lifestyle oder Ausdruck von Arbeitsunlust ist. Stattdessen ist es ein geregelter Rechtsbegriff: regelmäßige Arbeitszeit unterhalb der betrieblichen Vollzeit.

Der Gesetzgeber verfolgt damit eine einfache, aber zentrale Idee. Arbeitszeit ist verhandelbar, weil Leben nicht normiert ist. Wer dieses Recht infrage stellt, greift nicht einen modischen Lebensentwurf an. Er greift ein zentrales Arbeitnehmerrecht an und verkauft das als Kulturkampf.

Der Nische entwachsen

Teilzeitbeschäftigung ist in Deutschland längst kein Nischenthema mehr, sondern ein Massenphänomen. Laut Destatis arbeiteten im Jahr 2024 erstmals 29 % aller Erwerbstätigen in Teilzeit.

Der Frauenanteil unter den Teilzeitbeschäftigten ist dabei hoch. 49 % der erwerbstätigen Frauen waren 2024 in Teilzeit, aber nur 12 % der Männer. In absoluten Zahlen bedeutet das, dass fast jede zweite Frau, aber nur knapp jeder achte Mann in Teilzeit arbeitet.

Die Teilzeitquote steigt dabei seit Jahren. Während 2005 erst 43 % der Frauen und 7 % der Männer in Teilzeit arbeiteten, sind es 2024 jeweils 49 % und 12 %.

Diese Zunahme ging Hand in Hand mit einem starken Anstieg der Erwerbstätigenquote, besonders bei Frauen, von gut 59 % im Jahr 2005 auf 74 % im Jahr 2024. Hier wird also nicht weniger gearbeitet, sondern mehr.

Teilzeit in der IT

Die Debatte um Teilzeit findet in der IT-Branche eine besondere Relevanz.

Aktuelle Bitkom-Zahlen zeigen, dass in der deutschen Wirtschaft auch 2025 weiterhin ein großer Fachkräftemangel in der IT-Branche besteht. Rund 109.000 IT-Stellen sind aktuell unbesetzt, und Unternehmen berichten, dass vakante Positionen im Schnitt etwa 7,7 Monate unbesetzt bleiben.

Trotz teils zurückhaltender Einstellungspläne durch Unternehmen bleibt die Nachfrage nach IT-Fachkräften hoch, was den Druck auf den Arbeitsmarkt und die Suche nach flexiblen Beschäftigungsformen wie Teilzeit verstärkt.

Unternehmen haben erkannt, dass Flexibilität Mitarbeiter:innen bindet und neue Bewerberkreise erschließt. So lautet die zentrale Erkenntnis einer aktuellen Studie des Institutes der deutschen Wirtschaft, dass Teilzeitstellen den Kandidatenpool erweitern und damit eine Chance zur Fachkräftesicherung sind.

Eine branchenübergreifende Befragung zeigt, dass rund drei Viertel der Unternehmen Teilzeitstellen als förderlich für ihr Geschäft einschätzen. Von diesen erwarten 56 % eine höhere Mitarbeiterzufriedenheit, 51 % eine bessere Deckung des Personalbedarfs und 18 % eine Produktivitätssteigerung.

In der IT ist Teilzeit längst gelebte Praxis moderner Arbeitsmodelle. Flexible Formen wie Teilzeit-Führung, Remote Work, Gleitzeit oder Job-Sharing helfen, Talente zu gewinnen und zu halten. Die CDU-Vorschläge würden genau diese Flexibilität zurückdrehen. Ausgerechnet in einer Branche, die ohne sie kaum funktionieren würde. Stattdessen plädiert die CDU-Mittelstands- und Wirtschaftsunion faktisch für eine Verknappung des Bewerbermarkts.

Symboldebatte statt Fakten

Gegner von Teilzeit verweisen gern auf die Leistungsgesellschaft. Deutschland müsse härter arbeiten, um international mithalten zu können.

Ein Blick auf die Zahlen relativiert das. Deutschland hat mit rund 29 Prozent eine der höchsten Teilzeitquoten in Europa, und die durchschnittliche Wochenarbeitszeit aller Erwerbstätigen liegt unter dem EU-Durchschnitt (etwa 33,9 Stunden in Deutschland vs. rund 36 Stunden im EU-Schnitt). Während die wöchentliche Arbeitszeit für Vollzeitbeschäftigte in Deutschland nahezu dem EU-Durchschnitt entspricht, zieht der hohe Anteil an Teilzeitstellen den Durchschnitt aller Beschäftigten nach unten. Es wird nicht weniger gearbeitet, sondern anders.

Länder mit ähnlich hohen Teilzeitquoten wie die Niederlande oder Dänemark zählen trotz, oder gerade wegen, dieser Modelle zu den produktivsten Volkswirtschaften. Mehr Arbeitszeit allein schafft keine Wettbewerbsfähigkeit; entscheidend sind Produktivität, Qualifizierung und verlässliche Betreuung.

Ein hoher Teilzeitanteil ist weder ein Allheilmittel gegen den Fachkräftemangel noch der Wettbewerbsnachteil, als der er oft dargestellt wird. Er ermöglicht vielmehr eine bessere Vereinbarkeit von Arbeit und Leben; ein Standortfaktor und immaterieller Nutzen, der in internationalen Vergleichen regelmäßig unterschätzt wird.

Teilzeit und Familie

Deutschland ist nach wie vor eines der Länder mit der größten geschlechtsspezifischen Aufteilung von Beruf und Haushalt. Frauen leisten laut Statistischem Bundesamt knapp 44 % mehr unbezahlte Sorgearbeit als Männer (rund 30 vs. 20 Stunden pro Woche).

Ohne Teilzeitmodelle müssten viele Mütter Vollzeit arbeiten, ohne Rücksicht auf Kinderbetreuung, was oft nicht praktikabel ist.

Die Daten zeigen einen klaren Zusammenhang zwischen der Verfügbarkeit von Kinderbetreuung und dem Umfang von Teilzeitarbeit. Ohne verlässliche Ganztagsbetreuung und familienfreundliche Arbeitsmodelle ist Teilzeit keine Option, sondern die Voraussetzung für Erwerbsarbeit von Eltern. Flexible Arbeitszeitmodelle sind hier oft die einzige Möglichkeit, Beruf und Familie zu vereinbaren.

Wer wirklich mehr Arbeitsvolumen will, hat eine langweilige Pflichtaufgabe: Kitas, Ganztag, Pflege, flexible Arbeitsmodelle. Das ist teuer, mühsam, unsexy.

Die Belastung der Sozialsysteme

Wenn die MIT-Vorsitzende Gitta Connemann erklärt, ergänzende Sozialleistungen seien nur für „echte Ausnahmesituationen“ gedacht, verkennt sie die Realität des Arbeitsmarkts.

Teilzeit ist für Millionen Beschäftigte kein freiwilliger Komfort, sondern die Voraussetzung dafür, überhaupt erwerbstätig zu sein. Ohne flexible Arbeitszeitmodelle würden viele Eltern und Pflegende ganz aus dem Arbeitsmarkt fallen; mit deutlich höheren Sozialausgaben als Folge. Dass Eltern und Pflegende damit angeblich nicht gemeint seien, ändert nichts: Der Begriff Lifestyle-Teilzeit trifft nicht Einzelfälle, sondern diskreditiert Teilzeit insgesamt.

Ergänzende Leistungen sind daher kein Zeichen von Arbeitsunwillen, sondern ein Korrektiv für strukturelle Defizite: fehlende Betreuung, unzureichende Pflegeangebote und Arbeitszeiten, die mit realem Leben kollidieren. Was hier als Normalfall kritisiert wird, ist politisch erzeugt.

Schuld ersetzt Lösungen

Der Vorstoß der CDU-Mittelstands- und Wirtschaftsunion macht aus einer strukturellen Realität ein individuelles Fehlverhalten. Lifestyle-Teilzeit ist kein analytischer Begriff, sondern ein moralischer. Er soll beschämen, wo Politik gestalten müsste, und Misstrauen säen, wo Verantwortung gefragt wäre. So wird Sozialpolitik durch Schuldzuweisung ersetzt.

Teilzeitarbeit ist in Deutschland kein Randphänomen und kein modischer Rückzug aus der Leistungsgesellschaft. Sie ist für Millionen Menschen die Voraussetzung, Erwerbsarbeit überhaupt mit Betreuung, Pflege, Gesundheit oder schlichten Belastungsgrenzen vereinbaren zu können. Wer das diffamiert, bekämpft Symptome und blendet Ursachen aus.

Besonders entlarvend ist der Versuch, den Rechtsanspruch auf Teilzeit an würdige Motive zu knüpfen. Arbeitszeit ist jedoch kein Bekenntnis, sondern eine Vertragsfrage. Gleichzeitig existiert bis heute kein durchsetzbarer Anspruch auf Rückkehr in Vollzeit. Wer reduziert, trägt das Risiko allein. Diese strukturelle Einbahnstraße bleibt im CDU-Vorstoß unerwähnt.

Auch das Argument der Sozialsysteme überzeugt nicht. Geschwächt wird der Sozialstaat nicht durch reduzierte Arbeitszeit, sondern durch schlechte institutionelle Organisation, niedrige Löhne und politische Fehlanreize. Dass ausgerechnet bei der Arbeitszeit moralisch sortiert wird, während andere beitragsmindernde Modelle unangetastet bleiben, ist keine ökonomische Logik, sondern moralische Rosinenpickerei.

Diese Debatte ist daher keine arbeitsmarktpolitische, sondern eine kulturelle. Wer Teilzeit als Lifestyle diffamiert, fordert nicht mehr Produktivität, sondern mehr Anpassung. Deutschland hat kein Teilzeitproblem. Deutschland hat ein Betreuungs-, Pflege- und Politikproblem und versucht, dieses Versagen rhetorisch nach unten weiterzureichen.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Upgrade einer Minecraft-Welt erzwingen

Meine mittlerweile über fünfzehnjährige Minecraft-Welt Akaria, belegt speichertechnisch bereits etliche Gigabyte auf der Festplatte. Allerdings ist dies bei solchen gewachsenen Welten nicht unbedingt das Problem. Bedingt durch viele Upgrades der Minecraft-Server-Versionen und damit einhergehenden Änderungen, wie z.B. am Chunk-Format, befindet sich irgendwann ein buntes Sammelsurium an Daten in den Weltordnern. An sich ist dies kein Problem, da Chunks beim Laden im Spiel automatisch konvertiert werden.

Ein Teil der Minecraft-Welt Akaria

Allerdings kann dies bei vielen Chunks mit Performanceeinbußen verbunden sein und die Chunks könnten teilweise noch Daten enthalten, die nur aufgrund vorheriger Versionen in diesen schlummern, aber in dieser Form nicht mehr benötigt werden. In einem solchen Fall bietet es sich an ein Upgrade aller Chunks und Regionen zu erzwingen:

screen java -Xms16G -Xmx16G -jar server.jar --forceUpgrade --recreateRegionFiles --eraseCache

Durch den Screen-Befehl kann die Session im Hintergrund weiterlaufen, nachdem sie detached wurde (Strg + A, anschließend Strg + D; Wiederaufruf mittels screen -r).

Damit beginnt der Minecraft-Server die Entities, POIs und Chunks zu upgraden. Während dieses Vorgangs, der je nach Welt, etliche Stunden dauern kann, ist der Minecraft-Server nicht erreichbar. In der Log-Datei latest.log kann der Fortschritt verfolgt werden:

[20:21:17] [Server thread/INFO]: 3% completed (10558 / 343881 chunks)...
[20:21:18] [Server thread/INFO]: 3% completed (10613 / 343881 chunks)...
[20:21:19] [Server thread/INFO]: 3% completed (10661 / 343881 chunks)...
[20:21:20] [Server thread/INFO]: 3% completed (10736 / 343881 chunks)...
[20:21:21] [Server thread/INFO]: 3% completed (10818 / 343881 chunks)...
[20:21:22] [Server thread/INFO]: 3% completed (10869 / 343881 chunks)...
[20:21:23] [Server thread/INFO]: 3% completed (10906 / 343881 chunks)...

Während die Option forceUpgrade dafür sorgt, dass der Upgradeprozess überhaupt angestartet wird, sorgt recreateRegionFiles dafür das neue und saubere Region-Dateien erzeugt werden, anstatt die alten Dateien nur zu bearbeiten. Die Option eraseCache löscht cacheähnliche Daten aus den NBT-Daten, darunter unter anderem Heightmaps, BlockLight und SkyLight. Diese Daten werden beim Neuladen der Chunks im Server ebenfalls wieder neu erzeugt.

Ist der Vorgang am Ende abgeschlossen, kann der temporär gestartete Server beendet werden und der Minecraft-Server wieder im Produktivbetrieb gestartet werden. Durch das Upgrade, das Löschen der Caches und der Neuanlage der Regionen, sollten viele Altlasten und potenzielle Probleme aus den Daten entfernt werden. Dies schlägt sich im Endeffekt auch positiv auf die Performance des Spieles im Serverbetrieb nieder.

Größe der Packdateien unter Git beschränken

Im Versionsverwaltungssystem Git existieren im Repository sogenannte Packfiles. Diese werden genutzt um mehrere Objekte, wie z.B. Commits, Trees, Blobs oder Tags, als einzelne Dateien abzulegen. Damit fasst Git viele Objekte zu einer einzelnen komprimierten Datei zusammen. Ergänzt wird das ganze durch einen Index, um einen schnellen Zugriff zu ermöglichen. Dabei nutzt Git Delta-Kompression, indem es ähnliche Objekte, z. B. verschiedene Versionen derselben Datei, nicht vollständig speichert, sondern nur die Unterschiede.

Eine Git-Pack-Datei im Schema

Dies reduziert die Repository-Größe erheblich, kann aber bei ungünstigen Repositorys mit vielen Binärdaten zu Repositorys führen, welche mehrere dutzend Gigabyte große Pack-Dateien besitzen. Eine Steuerung ist über den Konfigurationsparameter pack.packsizelimit möglich:

git config pack.packsizelimit 5g

Damit würde diese Einstellung für das aktuelle Repository gesetzt werden. Wer das Ganze global benötigt, kann dies ebenfalls einstellen:

git config --global pack.packsizelimit 5g

Allerdings gilt diese Einstellung nicht sofort, stattdessen muss für ein Repack gesorgt werden:

git repack -Ad --max-pack-size=5g

Anschließend kann die Größe der Packs kontrolliert werden:

ls -lh .git/objects/pack

Allerdings sollte beachtet werden, das die Option grundsätzlich nur in Ausnahmefällen sinnvoll ist:

Note that this option is rarely useful, and may result in a larger total on-disk size (because Git will not store deltas between packs) and worse runtime performance (object lookup within multiple packs is slower than a single pack, and optimizations like reachability bitmaps cannot cope with multiple packs).

Maus-Probleme in Minecraft unter Ubuntu

In einer Minecraft-Installation unter Ubuntu kann es zu Problemen kommen, das die Mausevents innerhalb des Spieles nicht korrekt verarbeitet werden. Dies kann unter anderem zu dem Effekt führen, dass Mausklicks, wie z.B. der Klick mit der rechten Maustaste nicht richtig erkannt werden und die Maustaste dann als dauerhaft gedrückt angenommen wird. Bei dieser Art von Problemen wird dann oft von Problemen mit Wayland ausgegangen oder mit der Einstellung Raw Input in den Mouse Settings von Minecraft versucht das Problem zu lösen.

Mit fehlerhaften Mausevents vergeht in Minecraft schnell der Spielspaß

Im vorliegenden Fall lag es aber an der Minecraft-Installation selbst, welche als Snap-Paket installiert war. Durch das Sandboxing kam es zu den Problemen bei der Erkennung der Mausklicks. Hier half es am Ende die Snap-Version zu deinstallieren und das Debian-Paket des Minecraft-Launchers zu installieren. Anschließend funktionierten die Mausklicks wie gewohnt.