Ich mache mir ja schon seit riniger Zeit Gedanken, über die immer wieder sehr kaputte Föderation der vielen Dienste im Fediverse.
Jedes Service hat immer nur rinen Teil der Features implementiert, und diese passen oft nicht zusammen.
Mir schwebt eine Lösung, ähnlich wie sie bei Datenbanken vor Jahren beschritten wurde, vor.
Viele Dienste haben die Föderation und/oder Activitypub erst später zu ihrem bestehenden Projekt hinzugefügt. Auf die Schnelke falken mir da Lemmy, Funkwhale, Pixelfed und Friendica ein.
Wenn es jetzt einen oder mehrere Implrmentierungen rines Föderation-Services gäbe, auf den eine Anwendung - ganz ähnlich wie bei den Datenbanken - zugreift.
So ein Dienst kann in verschiedenen Sprachen implementiert sein, oder einer ist mittels Plugins um weitere Protokolle erweiterbar, der andere hat sie direkt eingebaut…
So ein Dienst kann von der Applikation mit einem Protokoll oder einer API angesprochen werden. Die Applikation kann das volle Featureset nutzen, oder nur einen Teil. Wichtig ist, dass die Föderation mit anderen Services korrekt und vollständig abgebildet wird.
Das soll heißen, wenn Friendica ein “article” an Service X schickt, dann kommt das dort korrekt an. Und Service C schickt ein Dislike an Service D. Usw. usf.
Was das Zielservice dann mit diesen Events/Verben macht, bleibt dem Zielservice überlassen. Stellt es die Kommentare dar, oder nicht, gibts einen Kalender oder nicht… egal. Das Fediservice stellt sicher, dass die Anwendung diese Features auch später implementieren kann, aber vorher die Server2Server-Kommunikation schon korrekt abläuft.
Die Applikationsentwickler können dann ihre ganze Energie ins Frontend, die Authentifizierung, Bildverarbeitung, Videodarstellung und was auch immer stecken. Die Föderation wird funktionieren. So wie die Datenbank auch immer funktioniert. Egal ob mysql, mariadb oder postgresql oder gar sqlite verwendet wird.
Kroeg übrigens ist ein in C geschriebener Activitypub-Server, der das ganze Protokoll als einziger kann. (Siehe https://activitypub.rocks/implementation-report/ )
@jakob Hrm… wenn ich dich richtig verstehe, beschreibst du grad ActivityPub und wie der verknüpfung der einzelnen dienste untereinander funktionieren soll…
Am ende wirds dann aber dennoch darauf hinauslaufen, das du auf friendica einen post mit markup veröffentlichst und der bei mastodonten nur als plaintext rausfällt … und andersherum, mastodonten werden ihre wirren umfragen veröffentlichen und die kommen bei friendica nur so halbgar an…
Wenn es dazwischen nun einen server gibt, der alles sauber implementiert … bringt das den usern an den einzelnen interfaces aber immernoch nichts.
@hackbyte @jakob Es geht darum, dass friendica einen “article” postet, aber in lemmy löst das eine fehlermeldung aus, weil das “article” gar nicht kennt, weil nicht implementiert… (ich glaub, das war ein problem).
Oder friendica implementiert events anders als mobilizon. mobilizon kann auf friendica ein neues event erstellen, updaten aber nicht mehr löschen…
friendica hat einen “ich nehme teil”-Button für events… aber mobilizon versteht den wieder nicht…
was die anwendung dann dahinter macht… ist sache der anwendung. es geht mir wirklich rein um die föderation.
Ich hab das jetzt bei einigen bugmeldungen zwischen verschiedenen diensten die ich selbst aufgemacht habe, erlebt, dass die implementierungen irgendwie nicht sauber waren… oft mussten nur “kleinigkeiten” dafür mit jedem anderen service extra “nachgebessert” werden, dann klappte es.
Wenn ich allerdings einen Fediservice (so wie einen Datenbankservice) habe, wo sich die Devs wirklich nur mit der Föderation auseinandersetzen, und diese perfektionieren können, dann muss nicht jeder dev jedes noch so kleinen oder großen Fediverse-Dienstes sich auch noch um das kümmern.
JSON-LD dürfte schwierig zu implementieren sein. Es gibt schon Anleitungen, wie Basics “richtig” implementiert werden sollen, weil das bei jedem Service offenbar anfangs falsch gemacht wird…
Bei Datenbanken regt sich ja heute auch niemand mehr auf, dass der eine mariadb und der andere postgresql verwendet, und jeweils nur ein Subset der Funktionen einsetzt… Aber es kann einfach die Applikation auf weitere Features der Datenbank erweitert werden, wenn das notwendig ist.
Genauso stell ich mir das bzgl. Föderation vor.
Ich installiere mir z.B. friendica, was die abhängigkeiten zu mariadb/mysql hat, dann halt eben auch zu fediserv oder apd (activitypubd). Dann braucht man noch einen Webserver (apache, nginx…)
vorne dran bleibt es immer noch friendica. Die Userverwaltung, die Darstellung, die Funktionen (Blog, Gruppen, Events…) kommt von friendica. Aber die s2s-Kommunikation läuft über fediserv oder adb (das sind zwei Phantasienamen von mir für den Föderations-Teil)
Glaube die Idee ist gar nicht so schlecht, dazu müssten aber eine einwandfreie und gut dokumentierte API her und bestehende Objekte ihren backend komplett über den Haufen werfen.
Damit löst du aber wie @hackbyte@friendica.utzer.de schon gesagt hat weniger das Problem der User, sondern nur der Fehlermeldungen. Ein paar Kleinigkeiten, die du gerade erwähnt hast werden dann sicher glatt gebügelt; aber vieles hängt ja dennoch von dem Frontend ab und was er anbietet. Bei Friendica hatte ich z.B. das Problem, dass das Teilen, von Kalendereinträgen mit einer bestimmten Gruppe von Benutzern intern schon nie gut funktioniert hat, (Wollte das für die Rundenverwaltung P&P nutzen) aber das nicht immer sauber bei allen angekommen ist.
Das Erwähnen von Nutzern von Lemmy aus funktioniert wohl auch nicht.
@hackbyte @Tealk Genau das ist ja das Problem.
Es müssen sich die Devs ALLER Projekte immer wieder mit dem selben Thema herumschlagen. Wie kriege ich die Föderation hin.
Ich bin mir sicher, dass sich auch in den nächsten Jahren so ein Projekt entwickeln wird, welches nicht nur zwischen Applikations-Front- und Backend aufteilt, sondern auch noch einen expliziten Service für die Föderation abspaltet, der dann von anderen Projekten übernommen werden kann.
Es sind ja nicht nur die Fehlermeldungen und Warnings im Serverlog… Es sind ja schlicht einfach unterschiedliche Implementierungen der Föderation. So wie ich das mitbekommen habe. Kleinigkeiten, warum das Event nicht ankommt oder der Beitrag, oder warum das Like nicht zurückgeschickt wird…
Dass es mit der Formatierung im Frontend noch nicht so klappt… das liegt in der Natur der Sache… Ein auf Plaintext optimierter Microblogging-Dienst wird mit der Darstellung von Markdown-Blog-Einträgen Probleme haben.
Ob Videos jetzt richtig dargestellt werden, die von Peertube kommen… das klappt ja - soweit ich das jetzt überschauen konnte - doch relativ gut.
Pixelfed zeigt Kommentare nur bis Ebene 2 an… ungünstig.
Aber dass Mastodon bei Lemmy in einer Community zwar kommentieren und Liken kann, aber keine neue Beiträge erstellen… ist ungut, weil Mastodon keine Gruppen/Communitys kennt… Wer kennt schon die Gründe, die den Dev bei Mastodon bewogen haben, das aus dem Protokoll auszulassen… Vielleicht hat er sich einfach damals mit der Programmierung der Föderationsgeschichte schwer getan… ein Fediserv könnte ihm das abnehmen. (Ja… “ich habe mich entschlossen, es nicht zu implementieren” kann ein guter Grund sein, kann aber auch ein “ich wusste damit nix anzufangen, also hab ich es sein lassen” sein)
Ich bin mir bewusst, dass hier auch noch viel Diskussionsarbeit reingesteckt werden muss. Und vielleicht - sollte sich diese Trennung ergeben - verschwinden dann manche dieser Projekte, die es heute gibt. Wenn es dann besser funktionierende Services gibt… warum nicht?
@jakob @Tealk Hrm … ich fürchte sogar fast, du bist da ein wenig auf dem falschen dampfer…
Du beschreibst also im grunde einen dedizierten server der nur die S2S rolle übernimmt und dabei konkret die ActivityPub api (vollständig und definitionsgetreu) anbietet. So weit so gut für sich ersteinmal.
Im grunde allerdings, machen das bisher alle so oder so bereits… ActivityPub ist in sehr großen teilen des #FediVerse so oder so das protokoll der wahl.
Den punkt das jeder diesen standard am ende für sich wieder auf seine eigene weise implementiert, wirst du aber nicht durch das etablieren eines neuen standard-middleman-servers abstellen können…
Ohne unken zu wollen wir es mit sehr großer wahrscheinlichkeit darauf hinauslaufen:
Btw, lokal den usern als eingabemöglichkeit kein markdown oder sonstige formatierungen zu geben ist ja noch eines. Die standard-formatierungen die _alle_ anderen unterstützen mutwillig auszublenden ist halt…
Wie gesagt, das sind auch alles dinge die du mit einem daemon der die standard-protokolle sauber implementiert nicht ändern können wirst imho.
@hackbyte @Tealk Nein. Du verstehst nicht, was ich will.
Ich hab schon einige Bugreports bzgl. Föderation bei verschiedenen Projekten aufgemacht… und es ist überall das selbe gewesen… Irgend einer der Dienste hat das AP nicht sauber implementiert oder eigens interpretiert. Damit wurde es inkompatibel zur anderen Implementation… Dialektfehler sozusagen.
Früher einmal haben sich die Programmierer auch ihre eigenen relationalen Datenbanken für jedes Projekt selbst programmiert… jedes mal neu, jedes mal ein wenig anders, jedes mal genau auf die Applikation hin optimiert und angepasst… Irgendwann einmal etablierten sich dann die universelleren Lösungen wie mysql, postgresql, hsql, sqlite, mariadb…
Du kannst auch mit Bibliotheken von python einen kleinen Webserver zusammenbauen… oder mit anderen Sprachen… aber wirklich gut nach außen kommunizieren ist doch eher angesagt, es mit apache, nginx oder lighthttp zu tun… da hat nämlich jemand verdammt viel Hirnschmalz reingesteckt, um es in beide Richtungen so flexibel anpassbar wie möglich und so sicher wie möglich zu machen.
Und ich sehe für Activitypub das selbe. Vielleicht greife ich dann mit meiner Anwendung nur auf ein Subset der Funktionen zu… mache das aber über einen “Reverseproxy für Activitypub”… Ich kann ja heute auch eine kleine python-Anwendung schreiben, die mir Interaktion mit http zulässt… aber davor hängt der nginx oder der apache der mir ssl oder sogar basic-auth macht…
Ich will ja keinen neuen Standard etablieren, wie das xkcd-Comic so schön zeigt… ich will den bestehenden Standard im Rahmen dieses Standards verbessert implementiert sehen.
Nicht mehr, aber auch nicht weniger.
@hackbyte @Tealk Und vor allem:
Schau dir die Entwicklung der verschiedenen Projekte an:
Funkwhale:
Entstand als Einzelprojekt um die eigene private Musiksammlung online anhören zu können. Die Föderation wurde erst später außen drangeflanscht. (und ist daher dementsprechend krakelig)
Lemmy entstand als Alternative zu reddit. Es war zwar von Anfang an mit Activitypub als Föderations-Protokoll ausgelegt. Aber nur von lemmy zu lemmy… die Föderation ins ganze Fediverse erfolgte vor wenigen Monaten mit einer Neuimplementation und Umbau der ganzen Software.
Pixelfed wurde als Einzelanwendung gebaut. Die Föderation wurde erst vor geraumer Zeit (ich glaub ~2 Jahre) außen drangeflanscht.
Die Föderation bei Mobilizon ist auch erst im letzten Jahr herangereift und noch lange nicht fertig… Anfangs nur von Mobilizon zu Mobilizon.
Bei Friendica wurde Activitypub erst später dazu implementiert. Anfangs hatte das Statusnet (glaub so hieß das) und das eigene DFRN… die weiteren Protokolle folgten später.
Für mich klingt das genau danach, dass alle diese Services, hätte es so einen Fediserv-Dienst schon gegeben, genau den hätten nutzen können. Ich bin überzeugt, die Föderation würde heute besser klappen.
@jakob @Tealk Ich drück dir definitiv die daumen…
Dennoch fürchte ich das mit einem sinnvollem framework zur implementation von ActivityPub mehr gewonnen wäre … allein, den muss mensch dann auch wieder für zig sprachen pflegen usw…
Dennoch viel erfolg. ;)