Worin unterscheiden sich Mastodon, Pleroma und Nostr technisch sowie bei Performance und Ressourcenbedarf?

**Kurzvergleich** ## 1) Grundmodell ### **Mastodon** - Föderiertes soziales Netzwerk auf Basis von **ActivityPub**. - Server („Instanzen“) kommunizieren untereinander. - Stark auf Twitter/X-ähnliche Nutzung ausgelegt. - Monolithischer als Pleroma. ### **Pleroma** - Ebenfalls **föderiert** und meist ebenfalls **ActivityPub**-basiert. - Kompatibel mit Mastodon/Fediverse, aber technisch deutlich schlanker. - Eher modular und ressourcensparend gebaut. ### **Nostr** - **Kein klassisches Föderationsmodell** wie Mastodon/Pleroma. - Statt Server-zu-Server-Föderation: Clients signieren Events kryptografisch und senden sie an **Relays**. - Identität basiert auf **Schlüsselpaaren**, nicht auf klassischen Accounts pro Instanz. --- ## 2) Technische Unterschiede ### **Mastodon** - Typisch: Ruby on Rails, PostgreSQL, Redis, Sidekiq, oft Elasticsearch/OpenSearch für Suche. - Viele Hintergrundjobs. - Stärker datenbank- und joblastig. - Föderation erzeugt bei großen Instanzen viel I/O und Queue-Last. ### **Pleroma** - Typisch: Elixir/Phoenix, PostgreSQL; oft ohne so schweren Zusatzstack. - Nutzt die BEAM-VM, die für viele gleichzeitige Verbindungen effizient ist. - Weniger Overhead, oft einfachere Architektur. - Föderation ähnlich im Prinzip, aber Implementierung meist leichtergewichtig. ### **Nostr** - Relays sind oft sehr einfache Event-Server. - Kommunikation meist über **WebSockets**. - Events sind signierte JSON-Nachrichten. - Keine komplexe Server-zu-Server-Synchronisation wie im Fediverse nötig. - Viele Funktionen, die bei Mastodon/Pleroma serverseitig liegen, wandern zu Client oder Relay-Ökosystem. --- ## 3) Performance ### **Mastodon** - Für kleine bis mittlere Instanzen okay. - Bei wachsender Nutzerzahl steigt Last oft deutlich: - mehr Hintergrundjobs - mehr Datenbanklast - mehr Speicherbedarf - mehr Föderationsverkehr - Große Instanzen brauchen oft Tuning, Caching, getrennte Dienste und mehr Admin-Aufwand. ### **Pleroma** - In der Praxis meist **performanter pro eingesetzter Hardware** als Mastodon. - Kann mit weniger CPU/RAM mehr Nutzer bedienen. - Besonders bei vielen gleichzeitigen Verbindungen oft effizienter. ### **Nostr** - Einfache Relays können **sehr leichtgewichtig** und schnell sein. - Performance hängt stark davon ab, was der Relay speichert und filtert. - Da keine klassische Föderation zwischen Servern nötig ist, fällt ein großer Teil der Komplexität weg. - Dafür können Suche, Persistenz, Spamabwehr und Event-Filterung je nach Relay-Software teuer werden. --- ## 4) Ressourcenbedarf ### **Mastodon** - Höchster Bedarf der drei, wenn man ein vollwertiges soziales Netzwerk betreiben will. - Braucht typischerweise: - mehr RAM - mehr CPU - mehr Storage - mehr operative Pflege - Medien, Caches, Suchindex und Job-Queues treiben den Bedarf hoch. ### **Pleroma** - Deutlich sparsamer als Mastodon. - Läuft oft gut auf kleinerer Hardware oder VPS-Systemen. - Geringerer RAM- und CPU-Bedarf bei vergleichbarer Grundfunktion. ### **Nostr** - **Am geringsten**, wenn nur ein einfacher Relay betrieben wird. - Kann aber steigen, wenn: - viele Events dauerhaft gespeichert werden - Volltextsuche nötig ist - starke Moderation/Spamfilter aktiv sind - viele gleichzeitige Clients verbunden sind --- ## 5) Skalierungsverhalten ### **Mastodon** - Skaliert, aber eher mit mehr Infrastruktur. - Horizontal möglich, aber administrativ aufwendiger. ### **Pleroma** - Skaliert meist effizienter auf kleinerer Hardware. - Für Self-Hosting oft attraktiver. ### **Nostr** - Skaliert konzeptionell anders: - viele Relays statt klassischer Instanz-Föderation - Nutzer können mehrere Relays parallel verwenden - Entkopplung von Identität und Server vereinfacht manches, verlagert aber Komplexität. --- ## 6) Praktisches Fazit - **Mastodon**: funktionsreich, weit verbreitet, aber technisch und betrieblich am schwersten. - **Pleroma**: ähnlich nutz