Vergleich sozialer Netzwerke


Zweck

Projektstatus

Jahr des Erscheinens

Kompatibel zu "Fediverse"

Vorteile

Nachteile

Wikipedia

Projektseiten


Diaspora*

Freie Facebook-Alternative

aktiv

2010


▪Übersichtliche Oberfläche

▪Recht hoher Bekanntheitsgrad


▪Langsame Entwicklung

▪Keine Unterstützung für Activitypub, dennoch kompatibel

Friendica

Freie Facebook-Alternative

aktiv

2010


▪Viele Funktionen und Addons

▪Einfache Installation

▪Aktive Entwicklung

▪Kompatibel zu "Fediverse", größte Kompatibilität

▪-


GnuSocial

Freie Facebook-Alternative

de facto inaktiv

2014


▪Recht viele aktive Nutzer*innen

▪Derzeit keine Perspektiven für die Zukunft

▪Keine Unterstützung für Activitypub, dennoch kompatibel

Mastodon

Freie Twitter-Alternative

aktiv

2016


▪Viele Nutzer*innen


▪-

Human Connection

Freies Facebook, Vernetzung für Veränderung

aktiv

2019


▪Engagierte Community


▪Noch inkompatibel zu "Fediverse"

-

Wechange.de

Polit-Vernetzung

aktiv

2016


▪Engagierte Community

▪Aktive Vernetzung

▪Unübersichtliche Kartendarstellung

▪Inkompatibel zu "Fediverse"

-

Nicht gelistet: Plemora und Hubzilla

Erläuterungen und Hintergründe

Zu Diaspora:
Die Entwickler von diaspora* arbeiten an einem abgeschlossenen Netzwerk. Dass Kommunikation auch an andere alternative soziale Netzwerke gehen kann (oder sollte), ist für sie nebensächlich – sie sprechen aber immerhin mit anderen alternativen sozialen Netzwerken über entsprechende Ideen und Möglichkeiten. Der Defacto-Standard ActivityPub ist aus Sicht der diaspora*-Entwickler das falsche Protokoll, da dessen Spezifikationen ihnen zu ungenau definiert sind.

Zu Mastadon und Activitypub:
Mastodon nutzt, wie Friendica auch, ActivityPub, hat den Standard aber nicht ganz exakt implementiert (obwohl sie selber maßgeblich an der Spezifikation beteiligt waren).
ActivityPub ist der sog. w3c-Standard. Das SPAM Problem wurde bei diesem Protokoll, wie beim alten OStatus-Protokoll bereits, ausgeklammert. D.h. man kann Beiträge, die auf andere Server gelangt sind, per Protokoll nicht wieder ohne weiteres “zurückholen” oder löschen.

Bei ActivityPub ist man mit einem Account stets an einen Server gebunden; obwohl mit Zot (Hubzilla, Osada, Zap) es bereits vor dem Beginn der Planungen zu ActivityPub ein Protokoll gegeben hat, das diese Bindung aufhob um zu ermöglichen, dass ein Account einen (oder mehrere) Klone besitzt. Und wenn der Hauptserver mal down sein sollte, der Nutzer ohne Probleme von dem Account-Klon aus weiterkommunizieren kann – bis der Admin den Server gefixt hat.

Zur Performance und Skalierbarkeit von Friendica
Friendica und Mistpark hatten früher das Problem, dass die Datenbank so konzipiert war, dass jeder Nutzer bei dem Beiträgen quasi einen abgeschlossenen Bereich in der Datenbank hatte. Das Skaliert nicht, wenn mehrere Leute auf einem Server die gleichen Kontakte haben, weil dann jeder Beitrag nicht einmal, sondern mehrmals in der Datenbank liegt und verarbeitet werden muss.
Seitdem Mika Macgirvon 2012 mit Hubzilla einen Friendica-Fork erstellt hatte, wurde bei Friendica massiv an der Performance gearbeitet. Friendica läuft heute problemlos für eine Familien-Instanz auf dem Raspberry 2b; das Problem ist der geringe Arbeitsspeicher von 1GB. Mit den neuen Raspbis mit 2GB oder 4GB sollte das noch weniger problematisch sein (eigentlich rechnet man so, dass die komplette Datenbank im Arbeitsspeicher liegen können sollte, mit 1GB RAM ist das schwerlich möglich).
Die großen Friendica-Server haben derzeit ein- bis zweitausend Nutzer. Natürlich dann auch eine bessere Hardware im Server als ein Raspberry Pi.
Nebenbei bemerkt soll die Performance von Pleroma noch besser sein. Aber es ist grundsätzlich die Frage, ob Plattformen darauf optimiert sein sollten, Millionen Accounts beheimaten zu können. Das widerspricht ggf. dem Dezentralisierungsverständnis der Entwickler.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.