Podcast

Föderation

Mehr als nur Mastodon

Bei föderierten Informationssystemen denken wohl die Meisten an Social Media-Alternativen wie Mastodon, PeerTube oder PixelFed. Aber was macht föderierte Systeme aus und wie funktionieren sie? Gibt es noch weitere Anwendungsbereiche? Darüber sprechen Nico und Lucas in dieser Podcast-Folge. Gemeinsam beleuchten sie die Vor- und Nachteile föderierter Systeme und gehen auf ActivityPub ein – das Protokoll, auf dem Mastodon & Co basieren.
Weitere Episoden anhören

Shownotes & Links

Transkript

Transkript ausklappen / einklappen

Lucas: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcast. Heute wollen wir über föderierte Informationssysteme sprechen und dafür habe ich mir Nico eingeladen.

Nico: Hallo Lucas, grüß dich.

Lucas: Willst dich mal kurz vorstellen für die Leute, die dich nicht kennen?

Nico: Ja klar, gerne. Ich bin Nico, bin seit Ende 2018 bei INNOQ und bin dort eigentlich querbeet unterwegs von Feststellen der Anforderungen, Formulieren der Anforderungen bei Kunden bis hin zur Implementierung. Ich war mal an jeder Stelle dran und fühle mich da auch eigentlich überall wohl.

Lucas: Eines deiner Steckenpferde sind föderierte Systeme und darüber wollen wir heute mal sprechen. Aber bevor wir das machen, müssen wir erst mal kurz erklären: Was ist denn ein föderiertes Informationssystem?

Nico: Was ein föderiertes Informationssystem ist, ist eigentlich ganz spannend. Im Gegensatz zu einem nichtföderierten System ist ein föderiertes System ein zusammengesetztes System. Ich kann mir das also so vorstellen: Es gibt nicht dieses eine System, sondern einen Verbund von Systemen. Und dieser Verbund ist grundsätzlich erstmal offen. Das heißt, jeder kann dort beitreten und seinen eigenen Server, seine eigene Instanz hinzufügen. Diese Systeme sind an sich erst mal unabhängig, funktionieren auch unabhängig voneinander und haben aber noch einen ganz netten Effekt, der die Föderation erst so richtig schön macht. Nämlich, dass ich von jedem Zugangspunkt, von jeder Instanz aus auf die Daten der anderen Instanzen zugreifen kann. Und dadurch bildet sich dann letztlich die Föderation.

Lucas: Andere Sachen, wo man vielleicht Föderation her kennt, ist Föderalismus von Ländern oder vielleicht auch was wie die Föderation der Vereinten Planeten. Aber um das jetzt mal ein bisschen klarer zu machen, weil das klingt immer noch sehr theoretisch. Da hatten wir beide überlegt, dass wir als Beispiel mal Chat Systeme nehmen. Viele Unternehmen haben mittlerweile irgendein Chat System, mit dem sie intern miteinander sprechen über verschiedene Themen. Und da gibt es ganz unterschiedliche Ansätze. Und ich glaube, das wohl am weitesten verbreitete System aktuell dazu, aus meiner Beobachtung nach als Consultant ist immer noch Slack oder Microsoft Teams. Ist denn Slack ein föderiertes System?

Nico: Wir können uns mal angucken, ob das den Definitionen entspricht. Ist Slack offen, also erlaubt Slack, dass ich mir eine eigene Slack Instanz aufsetze und mich dann verbinde? Ich glaube eher nicht. Slack ist ein geschlossenes System. Slack macht also mehr oder weniger ein Login, wenn ich dort drin bin und mit den Leuten weiter in Kontakt bleiben möchte, die dort drin sind, dann muss ich auch bei Slack bleiben. Und damit sind eigentlich keine der Kriterien für ein föderiertes System erfüllt.

Lucas: Aber es gibt in Slack diese Möglichkeit: Ich habe jetzt beispielsweise mein INNOQ Slack bei mir drin, dann habe ich aber auch noch ein Slack von meinem Kunden drin. Und dann gibt es ja auch noch die Möglichkeit, diese Shared Channels zu haben zwischen diesen beiden Slacks. Ist das dann keine Föderation?

Nico: Nein, nicht wirklich. Shared Channels oder diese Möglichkeit, zwischen Workspaces verschiedener Unternehmen zu kommunizieren, sind keine Föderation, weil es immer noch innerhalb des geschlossenen Systems Slack passiert. Das ist im Prinzip eine Art virtuelle Föderation, wenn man so will innerhalb von Slack. Aber nichts, was mir erlauben würde zu sagen: Ich baue meine eigene Slack Instanz um Herr meiner Daten zu bleiben und dann kann ich trotzdem noch mit den restlichen. So ist es nicht.

Lucas: Ich habe noch nicht mal quasi den Schritt 1, ich kann meine Slack Instanz selbst betreiben, also selbst das fehlt schon. Das heißt, wir sind sehr weit weg von diesem föderierten System. Auch, um das nochmal klar zu machen, damit das jetzt nicht falsch rüberkommt: Es geht nicht unbedingt darum, dass das besser oder schlechter ist. Wir wollen nur erst mal diesen Begriff einordnen und danach können wir immer noch über Vorteile und Nachteile sprechen. Wir haben jetzt als Unternehmen entschieden, irgendwie ist das mit Slack doof, dass wir das nicht selbst betreiben können. Vielleicht haben wir Datenschutzbedenken oder so was. Deswegen betreiben wir stattdessen einen IRC Server. Da gibt es ganz viele zum selber hosten. Wäre IRC ein föderiertes System?

Nico: Mit IRC bin ich was meine Daten angeht schon mal einen kleinen Schritt weiter. In IRC habe ich die Möglichkeit mein eigenes Netzwerk zu hosten. Das heißt, ein oder mehrere IRC Server und kann meine Unternehmenskommunikation darüber laufen lassen und bin auch sicher, dass meine Chatdaten bei mir bleiben. Von dem Gesichtspunkt wäre das schon mal besser. Allerdings wird es dann kniffelig, wenn es darum geht, über Netzwerke hinaus zu kommunizieren. Vielleicht muss man das noch mal explizit sagen. Bei IRC ist es so: Ich kann einen Verbund aus verschiedenen Servern aufsetzen, die zum gleichen IRC Netzwerk gehören. Und wenn Nutzer sich zu einem der Server verbinden, können sie auch mit den Nutzern auf den anderen Servern kommunizieren. Aber es ist immer noch ein Netzwerk, was leider nicht erlaubt mit anderen Netzwerken zu kommunizieren. Von daher, jein.

Lucas: Um das vielleicht noch mal ein bisschen deutlicher zu machen. Wenn man sich überlegt, es gibt so was wie Libera Chat. Das ist ein großer offener Server, wo man irgendwie Channel anlegen kann für Open Source Projekte. Und INNOQ setzt jetzt auch einen IRC Server bei sich auf. Dann besteht wahrscheinlich der Libera Chat aus mehr als einem Computer. Natürlich ein Server, auf dem alles läuft und vielleicht ist das auch bei dem INNOQ Server so. Aber irgendwie können wir nicht eine Nachricht von dem INNOQ IRC Server an den Libera Chat Server schicken. Das ist nicht möglich, richtig?

Nico: Das ist nicht vorgesehen bei IRC. Und das wäre eigentlich schon das, was wir für die Föderation brauchen.

Lucas: Genau. Und da wäre schon der Unterschied, dass ich zum Beispiel jetzt lokal bei mir einen IRC Client installieren kann und da sind dann beide Server drin. Das geht schon, aber ich kann nicht sagen, ich trete dem Channel Föderation auf Libera Chat bei aus meinem INNOQ IRC.

Nico: Genau, das geht nicht. Es ist vielleicht möglich, irgendwelche seltsamen Konstrukte zu bauen, die Netzwerke miteinander verbinden. Aber das ist glaube ich nichts, was jemand dauerhaft live nutzen möchte.

Lucas: Vielleicht gibt es da bestimmt auch noch was bei IRCv3 oder so, wer weiß das schon so genau. Aber grundsätzlich ist erst mal kein föderiertes System und das was wir eher sehen ist eher so was wie Load Balancing. So kann man sich das vorstellen. innoq.com ist auch nicht ein Server, sondern das verteilt die Load über mehrere Server so ähnlich ist es glaube ich auch bei dem.

Nico: Load Balancing oder Latenzgeschichten. Ein Netzwerk was in den USA und in Europa verfügbar sein möchte, hat wahrscheinlich dort und hier einen Server, damit die Latenzen gering gehalten werden und Nachrichten zwischen Nutzern in einem der Kontinente nicht über den großen Teich müssen.

Lucas: Genau, aber dabei sieht das System so aus, als wäre es eins und nicht mehrere und hat keine Unterbrechung. Okay, gut, dann haben wir jetzt also zwei schon mal gesehen, die nicht föderiert sind. Jetzt das als Beispiel XMPP oder auch bekannt als jabber. Wie ist das denn bei XMPP?

Nico: XMPP macht eigentlich genau diesen Schritt. Ich habe die Möglichkeit einen eigenen Server, eine eigene Instanz aufzusetzen. Die hat dann ihre Domain. Das heißt, mein Nutzer Name ist auch nicht mehr wie bei Slack oder bei IRC einfach nur mein Nutzername, sondern es hängt immer noch dieses Appendix dran, die Domain. Das heißt im Prinzip mein Nutzername@domain. Und damit kann das System eigentlich dafür sorgen, dass die Nachrichten immer zugestellt werden. Du hast einen XMPP Server auf deinem Server. Ich habe den auf meiner Domain und wenn ich dich anschreibe und die Nachricht an meinem Server sende, dann weiß der genau, wohin er sie weiterleiten muss.

Lucas: Genau, das heißt, diese Handels beinhalten irgendwie die Domain, richtig?

Nico: Genau richtig.

Lucas: Okay. Und das wäre dann ein richtiges föderiertes System. Das würde deine Definition erfüllen.

Nico: Wir können nochmal darüber gehen. Es ist offen. Jeder ist in der Lage einen eigenen Server aufzusetzen. Der Server funktioniert für sich unabhängig. Ich kann durchaus auch ohne mit anderen Server zu kommunizieren das Ganze benutzen. Und ich kann aber auch Nutzer auf anderen Servern kontaktieren und mit denen zusammen schreiben. Das sind alle Punkte, die damit erfüllt sind.

Lucas: Genau. Dabei lohnt sich vielleicht mal kurz noch mal zu erwähnen, dass XMPP, so aus der User Sicht ein bisschen anders funktioniert als IRC und Slack, die beide sehr channelorientiert sind und bei XMPP steht die direkte Nachricht zwischen zwei Personen oder ein Gruppenchat eher im Vordergrund. Darum geht es an der Stelle nicht so sehr. So funktionieren die Clients.

Nico: Tatsächlich ist das eher so eine Geschichte, die sich entwickelt hat. Am Anfang gab es bei XMPP soweit ich weiß zum Beispiel keinen Multi-User Chat. Da ging das nur One on One oder nur schwer mit mehreren. Irgendwann ist dieser Part Multi-User Chat hinzugekommen bei XMPP, der dann auch so was wie Channel erlaubt. Und bei den Channeln ist es dann ganz genauso wie bei den User Handles, dass dieser channel@domain, wo auch immer er gehostet wird, dann identifizierbar ist.

Lucas: Genau, dabei kann man natürlich auch noch mal vielleicht hervorheben, dass sowohl XMPP als auch IRC beides offene Standard sind, wo man sich RFCs für angucken kann, wo man selbst implementieren kann. Das ist etwas, was diese beiden Systeme miteinander teilen. Da sind offene Standards, nicht nur im System, sondern offene Standards. Gut, also jetzt haben wir so ein bisschen ein Gefühl dafür, wie das mit der Föderation funktioniert. Was gibt es denn noch für föderierte Systeme, die man vielleicht schon mal benutzt hat?

Nico: Ich glaube, da gibt es einen Elefanten im Raum, der einem direkt einfällt, wenn man jetzt schon mal den Handle von XMPP gehört hat. Nämlich Email. Genau das gleiche Prinzip. Du kannst deinen E-Mail-Postfach bei Gmail haben. Ich kann meins bei Outlook haben. Vielleicht habe ich nicht die besten Beispiele gewählt, aber ist egal. Und wir können uns gegenseitig Emails schreiben, weil wir kommunizieren mit unseren Mailfächern und die leiten das untereinander weiter. Das ist eigentlich das ursprüngliche föderierte System.

Lucas: Ja, ich glaube zu dem Zeitpunkt hat das wahrscheinlich auch keiner so genannt. Das ist einfach so passiert. Aber es ist auf jeden Fall alles das, was wir gerade bei XMPP gesehen haben, das sieht man da auch und man sieht es auch sehr stark an dem Handle, dass es genauso aussieht wie eine E Mail Adresse.

Nico: Das ist aber vielleicht auch ein bisschen ein Hinweis darauf, wie man sich früher das Internet vorgestellt hat und wie es dann heute tatsächlich ist. Eine E-Mail ist ziemlich von Anfang an mit dabei gewesen und ist auch so designt worden, dass es ohne große Single Points of Failure auskommt, sage ich mal.

Lucas: Und vor allem finde ich, ist es auch ein gutes Beispiel dafür, weil föderierte Systeme klingt immer so unglaublich kompliziert. Es klingt immer so, als ob das nicht für Endverbraucher und Verbraucherinnen freundlich ist zu verwenden. Aber ich meine, trotzdem hat irgendwie jeder Mensch eine E-Mail-Adresse und das funktioniert schon irgendwie. Also kann man das glaube ich nur schwer halten, das Argument, dass man das als nicht-hardcore Techie Mensch nicht versteht oder so was. Ich glaube E-Mail zeigt das ganz gut, dass das funktioniert. Gibt es denn auch andere Beispiele, wo es jetzt nicht unbedingt über Chats oder Nachrichten geht? Oder geht es bei Föderation immer um Nachrichten und Chats?

Nico: Da gibt es tatsächlich noch mehr, und zwar was viele vielleicht kennen, ist Nextcloud, ein selbst gehostetes File Sharing System. Dort kann ich meine Instanz aufsetzen, habe die Möglichkeit, dort meine Daten hochzuladen und zu verwalten und ein ganzes Meer an Plugins zu installieren, die mir dann noch so Dinge wie eine Kalenderverwaltung oder sogar Zugriff auf meine Emailpostfächer und sowas erlauben. Und dort wird auch föderiert. Zum Beispiel, was das Thema Daten teilen angeht. Du möchtest jetzt eine Datei mit mir teilen, die liegt auf deiner Nextcloud Instanz und dann schickst du mir ein Invite und ich habe die in meiner Nextcloud auf einmal auch drin. Das ist zum Beispiel die Föderation in der Nextcloud. Es gibt aber auch noch etwas feinteiligere Föderation und zwar die App Activities bei Nextcloud. Es ist zwar schön, wenn ich einen Ordner von dir in meiner Nextcloud drin habe, aber ich möchte vielleicht auch wissen, wenn du etwas an deinen Daten geändert hast oder wenn du einen Kalendereintrag geändert hast. Und da gibt es die Activity App, die man in der Nextcloud installieren kann und die nutzt tatsächlich auch ein Föderationsprotokoll um diese Nachrichten auszutauschen, damit du auch direkt Bescheid weißt, wenn sich da was ändert.

Lucas: Ja, ich finde es auch deswegen ein gutes Beispiel, wenn man sich jetzt überlegt, sowas wie Dropbox wäre jetzt eine andere Lösung für das gleiche Problem oder auch vielleicht Google Drive, dann habe ich nicht die Möglichkeit, wenn du jetzt einen Google Account hast und ich habe einen Dropbox Account, da könnten wir keine Ordner miteinander teilen. Das ist nicht möglich. Wir arbeiten jetzt bei verschiedenen Firmen, tun wir nicht, aber wir arbeiten bei verschiedenen Firmen und wir müssen einen Ordner teilen, dann ist das in ownCloud oder in der Nextcloud möglich. Aber sowas wie Dropbox oder Google Drive, ich weiß, da gibt es ganz viele verschiedene Lösungen, ist das nur möglich, wenn sich beide auf denselben Anbieter einigen. Sonst können sie nichts miteinander teilen.

Nico: Genau. Wobei du jetzt schon eigentlich einen Sonderfall wieder genannt hast. ownCloud und Nextcloud. Nextcloud ist mehr oder weniger aus dem Fork von ownCloud entstanden. Und soweit ich das herausfinden konnte, ist da aber keine Föderation untereinander mehr möglich. Die gehen beide eigene Wege, was das Daten teilen angeht. Unter sich jeweils schon, aber nicht untereinander.

Lucas: Okay, das ist ein guter Hinweis. Das sind jetzt mal ein paar Beispiele für viele föderierte Systeme, aber ich glaube, es gibt da noch eine ganze weitere Gruppe von Systemen unter diesem Stichwort ActivityPub.

Nico: Ja, genau.

Lucas: Vielleicht magst du mal kurz erklären, was ActivityPub erstmal grundsätzlich ist und was man damit machen kann.

Nico: Genau. Ich wette es sind einige in den Podcast gekommen: Föderation, ah da reden die bestimmt über Mastodon und wie sie alle heißen. Und jetzt zehn Minuten lang nichts, wann kommt das denn endlich? Genau, der Teil kommt jetzt und zwar unter ActivityPub. ActivityPub ist letztlich ein Protokoll, was sehr viele föderierte Systeme benutzen, um einmal mit ihren Clients und einmal auch untereinander zu kommunizieren. Im Prinzip sagt ActivityPub nur: Ich habe Nutzer, die kommunizieren mit ihren Instanzen. Das ist dann der Client-Server Part des Protokolls und ich habe Instanzen, die untereinander kommunizieren, um Informationen weiterzuleiten. Das ist der Server-Server Part von ActivityPub. Und das nehmen sich sehr viele Systeme und setzen darauf, wie zum Beispiel Mastodon, Pixelfed oder PeerTube und wie sie alle heißen.

Lucas: Okay, lass uns doch erst mal noch mal kurz, weil vielleicht nicht alle Leute Mastodon kennen, mal kurz erklären: Was ist Mastodon? Wie muss ich mir das vorstellen?

Nico: Zu den allgemein bekannten Social Media Netzwerken haben sich seit einiger Zeit schon so föderierte Varianten etabliert und Mastodon ist im Prinzip das Pendant zu Twitter. Als föderiertes, offenes System. Das heißt, ich habe genau die Möglichkeit meinen eigenen Mastodon Server aufzusetzen und das zu nutzen und zu kommunizieren mit Leuten, die auf meinem oder auf anderen Mastodon Servern sind. Ein Kurznachrichtendienst, kleiner Unterschied zum echten Twitter. Wir haben 500 Zeichen zur Verfügung. Ich glaube, das ist ein bisschen Glaubenskrieg, ob man jetzt 280 oder 500 Zeichen braucht. Aber es gibt da so ein paar feine Unterschiede im Detail tatsächlich. Aber Mastodon wäre im Prinzip das Twitter Pendant. Dann habe ich eben noch erwähnt PeerTube. Man kann es vom Namen her vielleicht schon raten. PeerTube ist das Pendant zu YouTube. Auch da habe ich die Möglichkeit eine eigene Instanz aufzusetzen und kann meine Videos dort hochladen und auch über Instanzen hinweg teil. Und ich glaube, eins hatte ich noch erwähnt. PixelFed, genau. Instagram darf natürlich nicht fehlen. Das ist die Inspiration für PixelFed. Die Links packen wir alle auch noch mal unten gleich in den Podcast rein.

Lucas: Das machen wir auf jeden Fall. Genau, in den Shownotes werdet ihr das alles finden. Um vielleicht noch mal kurz Mastodon als Beispiel zu nehmen. Sagen wir es mal, du bist auf a.com hast du deinen Account, ich habe meinen auf b.com. Kann ich dir folgen und dich erwähnen? Also wie muss ich mir das vorstellen?

Nico: Genau, das kannst du. Wenn du eine Nachricht auf deine Instanz a.com schickst, dann geht die in deine Outbox. Du hast auf deiner Instanz eine Outbox und da wird die Nachricht rein geschickt und kann entweder von anderen gelesen werden oder an deine Follower verteilt werden. Das sind alles Dinge, die in diesem ActivityPub Protokoll schon vordefiniert sind. Da gibt es diverse Aktivitäten, das hat ActivityPub wie das Erstellen einer Nachricht, also Create. Oder liken einer Nachricht, Like. Also erstellst du eine Nachricht und dein Server sorgt im Prinzip dafür, weil er deine Follower kennt, dass alle Follower, auch wenn sie auf einer anderen Instanz sind, deine Nachricht weitergeleitet bekommen. Gehen wir nochmal dieses Client-Server, Server-Server durch. Du sitzt an deinem Smartphone, schreibst eine Nachricht in Mastodon rein und schickst ab. Das heißt Client-Server. Auf deinem Server wird deine Nachricht in deiner Outbox erstellt. Dein Server sieht: Aha, es ist eine neue Nachricht in der Outbox und die soll an meine Follower gehen. Also schaue ich mal nach, welche Leute followen dem Lucas und auf welchen Instanzen sind die? Also schicke ich die Nachricht an diese Instanzen weiter. Das ist dann die Server-Server Kommunikation, die da passiert. Und auf der anderen Seite, wenn ich jetzt meine Timeline aufrufe und deine Nachricht sehen möchte, frage ich meine Instanz an: Was ist denn da alles Neues drin? Und da ist dann in meiner Inbox deine neue Nachricht zu sehen.

Lucas: Okay, das heißt also, es fühlt sich für mich an wie ein System ein bisschen, aber ich sehe es auch ein bisschen an den Handles. Wenn ich dir folge, kann ich, also wahrscheinlich wieder ähnlich wie bei E-Mails und IRC, da irgendwie die Domain sehen von dir, richtig?

Nico: Richtig, genau. Die Handles sind Benutzername@instanzname.

Lucas: Und du hast jetzt eben so ein bisschen nebenher gesagt, ActivityPub ist wie Mastodon, PixelFed, PeerTube, das sind alles irgendwie soziale Netzwerke. Bedeutet das auch, dass Mastodon mit PixelFed funktioniert? Oder funktioniert nur Mastodon mit Mastodon, aber sie benutzen dieselben Protokolle. Wie muss ich mir das vorstellen?

Nico: Das ist tatsächlich sehr schön. Alle Systeme, die auf ActivityPub aufsetzen, sind auch untereinander kompatibel. Das heißt, wenn du jetzt dein PixelFed Account zum Beispiel hast, und dort immer schöne Bilder postest, dann kann ich auf Mastodon dir folgen. Ich brauche also keinen eigenen Account auf deinem PixelFed Server, sondern kann das mit meinem Mastodon Account auf meiner eigenen Instanz machen, weil alle im Hintergrund die gleiche Sprache sprechen.

Lucas: Okay, das heißt also, du könntest etwas benutzen, was so aussieht wie Instagram und Bilder posten und ich könnte dir von meinem Twitter-artigen Mastodon aus folgen und deine Bilder sehen, ohne dass ich zwei verschiedene Programme brauche?

Nico: Ganz, genau.

Lucas: Okay, das ist tatsächlich ein Feature, das könnte ich mir vorstellen, dass wäre für viele Leute sehr praktisch. Da braucht man nicht so viele verschiedene soziale Netzwerke, weil schlussendlich sind alle Bilder plus Text. Mir fällt gerade noch auf, du hattest in der Vorbesprechung noch ein weiteres erwähnt und das war Funkwhale, kannst du dazu auch noch was sagen als föderiertes System?

Nico: Genau, Funkwhale ist das Pendant zu Soundcloud. Ich kam dort also Tondateien hochladen und teilen und dort gilt eigentlich das gleiche wie bei den anderen Systemen auch. Jeder kann seine Instanz aufsetzen, ich kann teilen, über Instanzen hinweg. Ist so von der Nutzerzahl wohl noch nicht so riesig groß. Aber ich glaub, das müssen wir auch ganz ehrlich sagen, ein Problem von den meisten föderierten System. Verglichen mit den großen bekannten sozialen Netzwerken sind wir nutzerzahltechnisch noch nicht so weit wie die. Aber das heißt nicht, dass das noch kommen kann.

Lucas: Da würde ich dann vielleicht auch in den Block einsteigen zu Vor- und Nachteile von Föderation, dass man durchaus, wenn jetzt jemand, der tolle Musik macht, dem ich gerne folgen möchte, hat jetzt ein Funkwhale Account, dann brauche ich jetzt erst mal nicht Funkwhale zu installieren, sondern ich könnte den auch mit meinem existierenden Mastodon Account folgen, richtig?

Nico: Im Prinzip schon, genau. Das erlaubt mir das ActivityPub Protokoll. Dort habe ich eben schon mal ganz kurz erwähnt, gibt es verschiedene vordefinierte Dinge, die man benutzen kann, wie zum Beispiel: Ich kann eine Nachricht erstellen, also eine Create Activity, ein Like und dann können diese einzelnen Nachrichtenobjekte noch verschiedene Eigenschaften haben, wie zum Beispiel ein Link zu meiner Inbox, ein Link zu meiner Outbox. Das sind alles Daten, die man für die Kommunikation braucht. Jetzt ist es aber vielleicht so, dass einzelne Anwendungen noch ihre eigenen Properties in diesen Objekten haben wollen. Und das können sie machen. Sie können das ist letztlich ein JSON-LD Objekt. Sie können also eine eigene Schema Definition aufsetzen, wo sie sagen: Es gibt jetzt nicht nur die Properties Inbox, Outbox und Nachricht, sondern es gibt noch eine Property, Interpret oder Genre. Also könnte ich jetzt hingehen und sagen: Diese Nachrichten, die ich austausche, haben weitere Eigenschaften, sodass sie auch woanders dann erkannt werden können.

Lucas: Okay, weil für mich wäre das jetzt schon ein großer Vorteil, den man jetzt im Vergleich zu dem Erfinden von einem neuen habe. Wenn ich jetzt eine Twitter Alternative aufbauen möchte, dann habe ich den Vorteil, wenn ich mich auf diesen Standard draufsetze, dass ich zumindest schon mal alle Leute, die in diesem föderierten System drin sind, folgen könnte. Das ist natürlich nicht dasselbe wie jetzt bei Twitter.com, weil das sind natürlich auch die gesamten föderierten Netzwerke zusammen. Die sind nicht ansatzweise so groß wie jetzt irgendwie Twitter oder auch YouTube oder sowas, aber es ist zumindest schon mal eine größere Startmenge von Menschen, als wenn ich jetzt mir ein ganz neues Ding ausdenke, wo ich die einzige Person bin, die darauf ist.

Nico: Ich habe nicht nur das Ökosystem Twitter oder besser gesagt dann Mastodon, sondern ich habe eigentlich alle Nutzer, die Systeme, die auf ActivityPub basieren, die ich erreichen kann, mit meinem Client. Das heißt auch, wenn ich jetzt zum Beispiel eine neue Instanz aufsetze, ich nehme jetzt einfach wieder das Beispiel Mastodon. Ein Schritt zurück. Wenn ich zu Twitter reingehe, habe ich natürlich den Fall: Okay, es gibt schon x Millionen Nutzer auf Twitter und eigentlich ist meine Timeline instant voll. Es sind ganz viele Nachrichten drin, ob ich die jetzt lesen möchte oder nicht. Wenn ich das auf Mastodon mache, ist das ein Schritt weit entfernt, aber es geht natürlich auch. Ich habe meine Instanz und erstmal zeigt mir diese neue Instanz dann die Timeline auf meiner Instanz an und da bin ich nun mal gerade alleine. Aber dafür gibt es auch ein cooles Feature bei Mastodon. Das nennt sich Relay. Es gibt nämlich viele Mastodon Instanzen, die ein Relay anbieten. Das sind vornehmlich auch große Instanzen, die sagen: Hey, wenn du eine kleine Instanz hast und trotzdem was vom großen Netzwerk mitbekommen möchtest, dann melde dich bei mir. Ich relaye dir meine Nachrichten, damit auch deine Timeline schon von Anfang an gefüllt ist und du schneller in Kontakt mit anderen Leuten kommst. Zum Beispiel.

Lucas: Das ist auf jeden Fall eine sehr praktische Eigenschaft. Cool. Das heißt, wenn wir jetzt aber dann trotzdem noch mal kurz auf die Nachteile schauen. Weil wenn es keine Nachteile hätte, dann wäre es schon längst das dominante System. Was würdest du denn als Nachteile von so einem föderierten System sehen?

Nico: Ich glaube, dass der größte Nachteil tatsächlich immer noch die Menge der Nutzer ist. Wenn ich jetzt mal auf der Straße Menschen frage, werden die wenigsten irgendwie Mastodon kennen, die meisten aber Twitter kennen. Das ist ein Problem, was sich wahrscheinlich nur mit der Zeit lösen lässt, wenn überhaupt. Dann ist es so, dass so eine föderierte Instanz, ich sage es jetzt mal allgemein auch von irgendjemanden betreut werden muss. Wenn ich jetzt engagiert bin und sage, ich setze meine eigene Mastodon Instanz auf, ich habe daran Spaß. Dann ist das vielleicht mit ein paar Nutzern noch relativ einfach. Das wird aber schwieriger, wenn es mehrere Nutzer werden, weil du willst auch gewisse Regeln auf einem Server haben. Du willst den moderieren und du willst dafür sorgen, dass die Daten gesichert bleiben. Das ist zumindest aus Sicht eines Systemadmins ein Nachteil, weil ich dann eigene Arbeit habe, die ich machen muss.

Lucas: Ja, ich glaube, eine andere Sache, die man zumindest im Kopf behalten muss, ist, dass wenn ich jetzt sage: Hey, willst du nicht Mastodon benutzen? Dann ist es genau falsch, wenn ich dieser Person direkt sage: Benutze bitte diese Instanz, weil wir wollen gerade, dass die Leute sich verteilen. Das heißt, da muss man, wenn man jetzt sagt: Hey, ihr könnt mir irgendwie auch auf Mastodon folgen, dann gehört dazu immer auch so ein bisschen die Erklärung: Ja, schau mal, dass du einen Server findest, der nett für dich aussieht. Das muss aber nicht der gleiche sein wie mein Server. Und da hängt einfach ein bisschen mehr dran, als wenn ich jetzt einfach sage: Hey, folgt mir auf Twitter. Selbst wenn die Leute Twitter nicht kennen würden, brauchen sie nur auf eine Webseite zu gehen und da ist alles erklärt. Und das ist eben bei Mastodon und Konsorten schon noch mal ein bisschen anders.

Nico: Genau. Der Einstiegspunkt ist ein bisschen schwieriger und wenn man sich auch diverse Seiten anschaut, es gibt Seiten, die einen Überblick über existierende Föderationsinstanzen bieten. Wenn man sich die anschaut, sind meistens die großen Server auch oben gelistet. Das heißt, hier in Deutschland ist zum Beispiel chaos.social einer der riesigen Mastodon Instanzen und die haben teilweise schon Registrier-Stops ausgerufen, weil sie gesagt haben, das ist nicht der Sinn des Systems, wenn auf einmal alle Nutzer bei uns landen. Wir wollen, dass es sich verteilt über viele Instanzen.

Lucas: Ja, und interessant ist, dass das nicht ein spezifisches Problem von Mastodon ist, sondern dass es da bei XMPP auch passiert ist. Da war so der größte Server in Deutschland jabber.ccc.de. Ich weiß nicht, ob das immer noch so ist, deswegen bin ich in der Vergangenheit, die gibt es immer noch, aber ich weiß nicht, ob die noch die größte ist. Und die haben auch irgendwann gesagt: Leute, klar könnt ihr euch bei uns anmelden, aber schaut doch auch mal auf andere Server. Wir wollen nicht, dass alle Leute auf jabber.ccc.de sind. Dieses Muster erkennt man durchaus bei solchen Systemen wieder. Und ich würde auch argumentieren, selbst bei E-Mail erkennt man das so ein bisschen, weil doch sehr viele Leute bei gmail.com sind, um ihre Email-Adresse zu haben. Für mich ist aber trotzdem, selbst wenn es sich innerhalb von diesem föderierten System zentralisiert finde ich, ist es immer noch ein Vorteil, dass so lange das System sich es sich abkappt vom Rest des Netzwerks. Wenn jetzt Google sich entscheiden würde, er würde nicht mehr XMPP und so weiter zu sprechen, dann wäre es blöd. Aber so wie es aktuell funktioniert, kann ich es zumindest immer noch, auch von meinem Email Server, der auf meiner eigenen Domain läuft, immer noch eine Mail an die Leute schicken, die bei Gmail sind. Das ist für mich glaube ich der größte Vorteil von dieser Art von System.

Nico: Es gibt tatsächlich noch einen Vorteil gegenüber E-Mail, wenn man das mal so sagen kann. Bei E-Mail ist es zum Beispiel so, ich bin mehr oder weniger dem Betreiber ausgeliefert, wenn ich es jetzt mal so drastisch beschreiben darf. Wenn der sagt, mit bestimmten anderen E-Mails kommuniziere ich nicht. Ich habe einen Kumpel, der möchte seinen Server irgendwie selbst betreiben oder so, soll’s geben, aber den erreiche ich leider nicht. Dann finde ich das blöd und möchte eigentlich ein Postfach, wo ich dann wieder mit meinem Kumpel schreiben kann. Tatsächlich kann man das Problem sehr gut auf die Föderation übertragen, weil dort ist es auch durchaus so, dass die Instanzen die Möglichkeit haben, die Kommunikation mit anderen Instanzen aus Regelgründen oder was auch immer zu verbieten. Das heißt, Instanz A kann nicht mehr mit Instanz B kommunizieren. Ich kann also als Nutzer von Instanz A auch niemanden mehr von Instanz B folgen. Bei E-Mail ist es dann schwierig. Dann ist das schon ein ganz schöner Aufwand, irgendwie eine neue Adresse anzulegen, dann vielleicht noch mein Postfach hin und her zu kopieren und so weiter. In verdrehten Systemen ist das tatsächlich einfacher. Es gibt eine sehr einfache Möglichkeit, einen neuen Account auf einer anderen Instanz anzulegen, die mir wieder die Freiheiten, die ich gerne haben möchte, auch bietet.

Lucas: Kann man sich das so vorstellen wie bei einem Umzug, dass man dann sagt: Weiterleitung oder so was?

Nico: Ja, genau. Du sagst im Prinzip deiner alten Instanz: Mein neuer Account liegt jetzt hier und da und sollten dann über ActivityPub noch irgendwelche Nachrichten an meine alten Instanz ankommen, dann wird es entsprechend redirected.

Lucas: Sehr cool. Ein bisschen wie der Nachsende Service von der Deutschen Post. Gut, wir sind nicht neutral, deswegen haben wir glaube ich nicht ganz geschafft, die Nachteile ganz so ausführlich zu beschreiben. Aber ich glaube trotzdem, dass die Übersicht den Leuten helfen kann, zumindest mal in das Thema reinzukommen und sich das mal anzuschauen. Wir versuchen euch in den Shownotes ein paar Links zur Verfügung zu stellen, wo ihr vielleicht einen Einstieg finden könnt, wo vielleicht interessante Instanzen sind, wenn ihr euch für das Thema interessiert. Und dann danke ich dir, Nico, für deine Zeit.

Nico: Ich danke dir, Lucas.

Lucas: Und dann sage ich mal den Hörerinnen und Hörern: Bis zum nächsten Mal. Tschüß.

Nico: Tschüß zusammen!

TAGS

Alumnus

Lucas war bis August 2023 Senior Consultant bei INNOQ. Er beschäftigt sich mit der Architektur, Konzeption und Umsetzung von Web Anwendungen in Front- und Backend. Er programmiert in Ruby und JavaScript und hilft bei der Entscheidung und Einführung verschiedener NoSQL Lösungen. Lucas ist Autor des Buchs „The Rails 7 Way“. Seine Stimme ist regelmäßig im INNOQ Podcast zu hören. Außerhalb seiner Arbeit beschäftigt er sich mit Open Source und Community Arbeit (wie die Organisation und das Coaching beim lokalen CoderDojo).

Senior Consultant

Nicolas arbeitet als Senior Consultant bei INNOQ in Monheim. Er hat mehrjährige Erfahrung als Product Owner und mit der Einführung von agilen Prozessen in Unternehmen. Er kümmert sich um die systematische Aufnahme von Anforderungen und deren Ausarbeitung in User Stories für die Umsetzung in agilen Entwicklungsteams. Er bildet außerdem Kommunikationsbrücken zwischen den beteiligten Teams und dem Kunden. Darüberhinaus hat er Erfahrung in der Implementierung von Microservice-basierten Web-Anwendungen in Python.