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@soc.schuerz.at
    link
    fedilink
    arrow-up
    2
    ·
    2 years ago

    @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.