Das Fediverse steckt fest: auf dem Weg zu einer Lösung.
Bisher habe ich ein paar Beiträge über die Stagnation des Fediverse geschrieben , und ich muss sagen, dass mich die Resonanz überrascht hat. Es ist klar, dass das Fediverse wichtig ist, aber es ist auch klar, dass es die Open-Source-Community abstößt.
Von mir angesprochene Probleme sind:
Der Grund liegt genau darin, dass Activitypub im Gegensatz zu anderen Standards, die für Open Source entwickelt wurden, ausschließlich für Unternehmer und Unternehmen entwickelt wurde, die sich ein beträchtliches Budget oder zumindest eine beträchtliche Menge an Arbeitsstunden leisten können, um eine Instanz des Fediverse zu schreiben.
Der Schöpfer von ActivityPub war immerhin ein Unternehmer, und dieser Standard stammt von ActivityStream ab, einem Standard, dessen minimale Implementierung in Golang mehrere MILLIONEN Codezeilen erfordert. Für eine Person unmöglich zu handhaben, geschweige denn sicher zu machen.
Wenn wir alle Versuche überprüfen, funktionierenden Code mit ActivityPub zu schreiben, sehen wir die Barriere: Jeder steckt fest, wenn er diesen schrecklichen Standard zur Kommunikation verwenden muss. Ein Beispiel ist Lemmy: Der erste Teil bestand darin, Forensoftware zu schreiben, was funktionierte. Der zweite Teil bestand darin, Lemmy dazu zu bringen, mit Lemmy zu sprechen, und der letzte, schwierigste und immer noch unvollständige Teil bestand darin, Lemmy dazu zu bringen, mit ActivityPub mit dem Rest der Welt zu sprechen.
Dies ist eindeutig ein Problem: Es bedeutet, dass ActivityPub für den Open-Source-Programmierer eine Barriere darstellt. Ziel unseres Handelns sollte es daher sein, die Lernkurve zu verkürzen und nur den funktionalen Teil den Programmierern zu überlassen.
Dieses neue Protokoll sollte daher folgende Ziele haben:
- einfach umzusetzen
- vorzugsweise bereits vorhandene, um gut gemachte Bibliotheken zu finden
- geprüft
- eindeutig standardisiert.
optimiert, um:
- seine Akzeptanz erhöhen
- zum Selbsthosten einladen
- Zahl der Programmierer, die sich an die Erstellung von Software machen
Zunächst müssen wir uns also fragen, ob wir die Syntax „user @ FQDN“ beibehalten wollen. Dann müssen wir das Rad sicher nicht neu erfinden, denn wir haben die ersten Kandidaten:
- SMTP
- XMPP
- SCHLUCK
Die Tatsache, dass wir das Rad nicht erneut implementieren müssen, indem wir bereits vorhandene Bibliotheken verwenden, wird unsere Software stabiler und sicherer machen.
Der Fehler, den man jedoch nicht machen sollte, besteht darin, die Komplexität zu erhöhen. Wenn wir zum Beispiel an SIP denken, stellen wir fest, dass SIP äußerst effektiv ist, um die Online-Präsenz zu verwalten und eine Sitzung zu initiieren.
Welche Art von Sitzung wird dann durch Aushandlung einer anderen Schicht, SDP (Sitzungsdefinitionsprotokoll), entschieden. Dies macht es enorm flexibel, da die SDP-Sitzung von einer PDF-Datei über die Beschreibung des Codecs für einen Sprachanruf bis hin zu einem Video-Codec reichen kann.
Das Problem ist, dass die SDP-Schicht an dieser Stelle sagen könnte: "Dies ist eine ActivityPub-Sitzung", alles wäre legal. Nicht einmal ActivityPub gibt an, dass die Nutzdaten über http gesendet werden müssen: Jeder Transport ist in Ordnung .
Aber durch die Verwendung von SIP haben wir uns nicht nur für das am schwierigsten zu implementierende der drei Protokolle entschieden, sondern auch für die Verwendung einer „Obermenge“ von ActivityPub, etwas, das es enthalten kann. Und das ist nicht gut: Wir wollten etwas EINFACHES.
Lassen Sie uns SIP verwerfen und etwas Einfaches versuchen. Versuchen wir es mit SMTP. SMTP ist einfach, ein Programmierer kann es an einem Tag oder weniger implementieren, und es ermöglicht eine ziemlich umfangreiche Grammatik.
Unsere Instanz möchte tatsächlich Threads gruppieren und möchte, dass Antworten auf eine Nachricht gruppiert werden. Und wenn wir ein wenig über die Grammatik von SMTP lesen, stellen wir fest, dass die Header alles enthalten, was wir brauchen, um die Beziehung zwischen der Antwort und der Nachricht zu beschreiben und den Thread zu rekonstruieren.
In-Reply-To: <4BE8776D.4080504@kheb.fr> References: <AANLkTik0c9hCMm2Efyj7rB7Us7hL3ZdESYEhE2GBQCfM@mail.gmail.com> <20100509165117.GD20976@ovh.net> <AANLkTins_dUSqRbR371SNnOIPYlatKdTCIVM8oDbtVtX@mail.gmail.com> <AANLkTimKu7l1AtEG-0CI7Q3Ely9PUL2yuyvYuhcMIuSn@mail.gmail.com> <AANLkTikJaHXYM_DF8zqdaH0vVnJ-fCpqvJ3OCQweoeAb@mail.gmail.com> <AANLkTinq7riyV4w3VnCoHyj9GsNf3H7jDzu1awU2PNRb@mail.gmail.com> <AANLkTilrPTCZPj_Tb7bXO5SLym_QY3KUp4J1jkZd5-ZE@mail.gmail.com> <4BE72FF3.3030501@kheb.fr> <4BE7B451.8060700@linuxant.fr> <4BE8776D.4080504@kheb.fr> From: XXX <xxx@xxx.xx> Date: Mon, 10 May 2010 23:20:59 +0200 Message-ID: <AANLkTikC5oN2rO5VTj8HN7U03b2H3HUqt89KYdemGlcJ@mail.gmail.com>
Und um es ganz klar zu sagen, es gibt auch praktische Kopfzeilen, die bei der Verwaltung von Gruppen helfen könnten, wie Reply-To und 'Sender', das sich von 'From' unterscheidet. Alles, was wir im Fediverse tun müssen.
tools.ietf.org/html/rfc5322
Amüsant ist auch die Tatsache, dass es mit einem Header wie x-face auch möglich ist, einen Avatar über ein Protokollfeld zu versenden.
Für den Rest kann der Reichtum von MIME bereits beantworten, wie man Dinge an Nachrichten anhängt.
In diesem Fall würde das Abonnieren eines Benutzers das Abonnieren einer Mailingliste bedeuten, deren Antworten an alle in To oder CC gehen, während eine "Gruppe" eine echte Mailingliste wäre, die bereits ihre eigene Semantik zum An- und Abmelden eingerichtet hat.
Ich weiß schon, dass das beleidigend klingt. Es klingt anstößig, weil wir sagen, dass ein „soziales Netzwerk“ nur ein Webmail ist, dessen Benutzeroberfläche eher einem sozialen Netzwerk als einem Webmail ähnelt.
Das wird alle beleidigen, die sich für kreativ und genial halten, weil sie das Rad neu erfinden: aber es ist nicht meine Schuld, dass Sie Protokolle erfinden wollten (und daran gescheitert sind), wo es bereits gute gab.
Die Tatsache, dass ein soziales Netzwerk nur eine Benutzeroberfläche ist, die jedem Kommunikationsprotokoll vorangestellt wird, ist dagegen nichts Neues: Selbst die Jungs, die „Delta Chat“ auf Basis von SMTP + IMAP machen, hatten dieselbe Idee. Und es funktioniert.
Aber der Punkt ändert sich nicht: Ein soziales Netzwerk ist effektiv eine Benutzeroberfläche, die jeden Kommunikationsfluss darstellen kann, einschließlich E-Mail.
Ein entscheidender Punkt bleibt noch zu diskutieren, nämlich der Transport. Der Transport ist aus mehreren Gründen problematisch:
- SMTP ist in privaten Netzwerken blockiert, was von Selbsthosting abrät
- Protokolle mit 'user @ FQDN'-Semantik hängen stark von DNS ab, die ebenfalls unter staatlicher Kontrolle stehen.
Daher muss SMTP berücksichtigt werden, wobei:
- funktioniert auf anderen Ports (nicht 25)
- arbeitet auf anderen Protokollen (ich weiß nicht, UDP), was uns jedoch der Hegemonie des DNS unterwirft
- verwendet andere Transportprotokolle wie DHT oder libp2p.
Auf diese Weise könnten wir ein möglicherweise besser skalierbares Fediiverse aufbauen, eines, das Programmierer einlädt, Instanzen zu schreiben, und Leute zum Hosten.
Das ActivityPub-Protokoll ist ein nutzloser Versuch, das Rad neu zu schreiben, da fast nichts von dem benötigt wird, was im Protokoll steht, wenn der Zweck nur darin besteht, eine Nachricht an "user @ FQDN" zu senden.
Wird jemand die Richtung ändern? Nein. Das Fediverse erscheint in gewisser Weise gefährlich, in anderer Hinsicht unvermeidlich: Dies zieht viele an, die der nächste Zuckerberg sein wollen, und einige andere.
Etwas Einfaches zu haben und zu erkennen, dass ein soziales Netzwerk nur ein Webmail mit einer bestimmten Schnittstelle ist, ist nicht einfach für diejenigen, die glauben, wer weiß was erfunden zu haben, und es ist nicht einmal einfach für diejenigen, denen morgen gesagt werden könnte, dass alle sozialen Netzwerke miteinander kommunizieren könnten, wenn nur jemand etwas wie smtp verwendet hätte, um sie zur Kommunikation zu bringen.
Ich glaube daher nicht, dass die Annahme eines einfachen und öffentlichen Protokolls jemals in den Sinn derjenigen kommen wird, die sich heute zu sehr darauf konzentrieren, die neue Erfindung zu beherrschen.