🔂 Fedbridge

Eine ActivityPub-Basierte Lösung für das RSS "Problem". Auch wenn ich es ungern schreibe, aber RSS ist quasi ausgestorben. Social Media-Plattformen haben jede Möglichkeit eines RSS-Feeds entfernt und unternehmen alles, um es auch Projekten wie RSSBridge so schwer wie möglich zu machen, den Content abzugreifen. Öffnet man einen Tweet als ausgeloggter User, wird der Tweet mit einem so großen Overlay verdeckt, dass man den Text nicht mehr lesen kann. Twitter ist als unbenutzbar geworden, wenn man nicht Teil davon ist. Auch andere Seiten wie News-Seiten etc. haben keinen RSS-Feed mehr.

Das Projekt RSSBridge versucht, den Missstand zu korrigieren, in dem die Seiten ohne RSS-Feed geparsed werden und als RSS-Feed bereitgestellt werden. Leider ist das Projekt selbst in desolatem Zustand und eine Alternative ist leider nicht in Sicht. RSS ist also selbst bei den Nerds obsolete geworden.

Seit 2018 gibt es den ActivityPub Standard, der sehr erfolgreich für SocialMedia-Alternativen wie Mastodon eingesetzt werden. Es liegt also auf der Hand, den Missstand der fehlenden RSS-Feeds mit ActivityPub auf ein neues Level zu heben. So bekommen nahezu alle Seiten und Pattformen einen "Connector" in die ActivityPub Welt. Mastodon User können Posts von Twitter-Usern kommentieren oder die News der lokalen Schule boosten. Einziges Manko: Es fehlt ein "Rückkanal". Die Informationen in Form von Posts, News, Bildern etc. werden abgegriffen und dann im Fediverse verbreitet. Der Autor bekommt davon nichts mit. Dieser Umstand besteht allerdings auch bei RSS, hier ist ebenfalls kein Rückkanal vorgesehen. Hierzu könnte man auf vorhandene Techniken wie PingBack oder sogar E-Mail zurückgreifen. Der neue Service steht als Stellvertreter für den Inhalt und kann so optional einen Rückkanal aufbauen.

Der eigentliche Post, der im Fediverse dann verteilt wird, kann nur den Titel, die ersten Zeilen etc. + eine URL zur eigentlichen Quelle liefern. So ist der "Rückkanal" gegeben und der Post ist nur ein angereicherter "Link" zur eigentlichen Ressource und keine Kopie.

Umsetzung

Konnektoren (Crawler-Classes)

Crawlen "Posts" von irgend welchen Quellen und stellen diese als vereinheitlichte Quelle bereit. Jeder dieser Konnektoren kann konfiguriert werden. Bspw. ein Twitter-Konnektor kann als Konfigurations-Option den Twitter-Handle und ein Flag "Only own posts" besitzen, um Retweets nicht mit zu crawlen.

Instanz (Collection)

Eine konfigurierte Version eines Konnektors. Im Beispiel Twitter nur Tweets von @abc123 und nur eigene Tweets. Diese Instanzen werden in regelmäßigen Abständen verwendet um nach neuen Inhalten zu suchen. Taucht ein neuer Inhalt auf, kommt ActivityPub ins spiel (weiter unten)

Groups (Actor)

Eine Gruppe enthält eine Liste von Instanzen. Dieser Gruppe kann man über ActivityPub folgen. Groups sind die "Primärschlüssel" des Services.

User (DB)

Können Gruppen mit einer oder mehreren Instanzen anlegen. User an sich kann man nicht folgen und sind an sich unrelevant. Es können auch Instanzen aufgesetzt werden, die von nur einem einzelnen User verwaltet werden.

Federation

* Server-Server Kommunikation: Wenn eine Instanz neue Einträge enthält, werden diese verteilt.
* Client-Server Kommunikation: Interaktionen mit den Einträgen. Hier kann der Rückkanal etabliert werden. (Ist noch nicht zu Ende gedacht)

POC

1. Konnektoren-Interface + zwei Beispiel-Konnektoren
2. User/Groups/Instanzen-Struktur anlegen (DB only)
3. "Job-Framework" zur regelmäßigen Abfrage der Insanzen