Distributed Web

Lucas Dohmen: Hallo und herzlich Willkommen zu einer neuen Folge des INNOQ-Podcasts. Heute reden wir über das Distributed Web und dafür habe ich mir den Nico eingeladen, Hallo Nico.

Nico Inden: Hi, Lucas.

Lucas Dohmen: Magst du dich den Zuhörern, die dich noch nicht kennen, kurz vorstellen?

Nico Inden: Klar, gerne. Ich bin der Nico und seit ungefähr November letzten Jahres bei INNOQ und bin als Consultant hier, helfe in den Projekten überall dort, wo es um das Gesamtprodukt, um Organisation in der Entwicklung, um Dinge wie Agile Code oder Scrum Master geht. Ich bin davon abgesehen aber auch immer gerne technisch unterwegs, auch schon vor INNOQ und habe mich mit verteilten Systemen beschäftigt.

Lucas Dohmen: Okay. Wenn ich Distributed Web höre, dann ist für mich die erste Frage: Ist das Web nicht sowieso distributed? Was genau ist am Web denn nicht distributed?

Nico Inden: Wenn man mal auf technischer Ebene schaut: Die Protokolle, die wir im Web nutzen, sind ja keine neuen, zumindest, wenn man sich jetzt mal HTTP, SMTP und Co anschaut, sind die von Anfang an mit dabei und haben von sich aus erst einmal keine Konnotation, ob sie distributed sind oder nicht. Ich möchte einfach von einem Ziel Daten auf verschiedene Arten und Weisen haben und frage sie dort an. Das ist auch in den Anfangszeiten des Webs überhaupt kein Problem gewesen und heute eigentlich kein technisches Problem. Ich habe früher meine Universität oder sonstige Einrichtung gehabt, die ihren eigenen Web- und Emailserver hatte. Jemand, der von dort Daten angefragt hat, hat die auch genau von dort bekommen und es gab in dem Sinne kein Problem mit Zentralisierung. Wenn man jetzt mal ein bisschen weiter in die Gegenwart schaut, sieht das schon ein bisschen anders aus, da ist es bei Universitäten vielleicht noch ähnlich, aber jeder, der sich selbst mal anschaut: Was habe ich denn alles für Accounts - ja, okay, meine Mail ist bei Gmail, also in den Händen von Google, mein Social Account hängt wahrscheinlich bei Twitter oder bei Facebook und für meine Webseite habe ich einen Anbieter, der mir einen Homepage-Baukasten zur Verfügung stellt. Die Daten liegen also auch nicht bei mir, sondern woanders. Und gerade, wenn man jetzt mal die sozialen Services anschaut wie Facebook, Twitter oder Mail - was ja durchaus auch etwas Soziales ist - beobachten wir halt heute, dass die Leute sich immer mehr auf die gleichen Services konzentrieren. Ich kann sehen, dass ganz, ganz viele Leute bei WhatsApp sind, weil die Leute, die sie kennen, auch bei WhatsApp sind. Es ist also für mich vollkommen logisch, dass ich auch dahin gehe, weil ich dort alle Leute erreiche. Das ist die Art von Zentralisierung, die wir heute erleben. Die ist eher sozial- und weniger protokollbegründet.

Lucas Dohmen: Okay, also mich würde ja nichts davon abhalten, meinen eigenen Mailserver zu administrieren, aber ist es vielleicht auch eine Komfortfrage? Denn es ist ja gar nicht so einfach, sich damit zu beschäftigen, das ist vermutlich auch ein Aspekt.

Nico Inden: Klar, das ist eine Komfortsache, die großen Anbieter machen es einem natürlich einfach einen Account anzulegen und direkt loszulegen. Direkt zu bloggen, direkt mit den Freunden zu schreiben, Emails zu schreiben. Was dabei aber immer mehr aus dem Fokus gerät ist das Thema Datenschutz und da kriegen wir jetzt so langsam den Bogen Richtung Distributed Web. Datenschutz ist ein Thema, das viele Leute wegklicken. „AGBs, ja, die habe ich gelesen, ich will meinen Account, ich will den nutzen.“ Aber dass dann im Hintergrund wenige Anbieter in den Besitz von Daten von sehr, sehr vielen Leuten kommen und die auch korrelieren können, da denken nicht alle dran. Und das ist ein bisschen das, was hinter Distributed Web steht, das ist also auf nicht-technischer Ebene - da habe ich eine Definition gefunden, die sagt „Das ist eine Bewegung, die versucht das Internet zu demokratisieren“. Also raus aus diesem Schlamassel zu kommen, dass wenige Anbieter im Besitz meiner Daten sind und damit machen können, was sie wollen - hin zu dem Zustand, dass ich im Besitz meiner Daten bleibe und granular sagen kann, wer überhaupt was über mich wissen darf.

Lucas Dohmen: Und das bedeutet erst einmal nicht, dass wir die Protokolle und Formate, die wir kennen, hinter uns lassen müssen? Das heißt, das Distributed Web ist erst einmal nur ein Anspruch daran, dass wir die Daten aus zentralen Händen herausbekommen wollen, richtig?

Nico Inden: Genau, wir wollen die Daten aus zentralen Händen herausbekommen und wir wollen Besitzer unserer eigenen Daten bleiben. Wir wollen eben nicht, dass einzelne Betreiber in der Lage sind, alles aus unseren Daten heraus zu korrelieren.

Lucas Dohmen: Wenn ich mir jetzt vorstelle, dass ich beispielsweise meinen Dropbox-Account habe, in den ich meine Dateien hochlade, die ich dann vielleicht auch mit anderen Dropbox-Usern teilen kann oder ich habe meinen Twitter-Account - welche Alternative hätte ich jetzt dazu, wenn ich nicht in diese zentralen Hände gehen möchte und trotzdem mit möglichst vielen Leuten meine Daten und meine großartigen Gedanken auf Twitter teilen möchte?

Nico Inden: Da gibt es einige Alternativen, das basiert alles auf einem Fediverse-Ansatz, das muss man an dieser Stelle vielleicht nochmal kurz erklären, was Fediverse oder Federated Web ist im Vergleich zu Distributed Web. Ich habe keinen einzelnen großen Betreiber mehr, sondern eine Fülle an kleinen Betreibern. Twitter wäre ein Beispiel, in dem das Twitter-Netzwerk ein großer Betreiber ist und die Alternative aus dem Fediverse wäre jetzt zum Beispiel Mastodon. Ich registriere mich dort als Nutzer auf einem von vielen Servern, die durchaus auch von Privatleuten betrieben werden, die aber untereinander auch kommunizieren können, das ist dann dieses ActivityPub-Protokoll, das definiert wurde, um unter den Servern Daten auszutauschen. Und an der Stelle kann ich dann ein ähnliches Erlebnis haben wie auf Twitter.

Lucas Dohmen: Aber das bedeutet auch, dass das Protokoll, das ich mit dem Server spreche, erstmal weiterhin HTTP ist, das heißt, ich kann meinen ganz normalen Webbrowser benutzen, um mit Mastodon zu chatten?

Nico Inden: Das hat weiterhin Bestand, ich benutze meinen Webbrowser, um dann entweder mit meiner lokalen Mastodon-Instanz oder mit einer, bei der ich mich registriert habe, zu sprechen. Ich habe ein ganz normales Web-Interface, es fühlt sich erst einmal ganz genauso an. Wo man das erste Mal einen Unterschied merkt, ist, wenn ich andere Leute ansprechen möchte. Auf Twitter kennt man das: Ich schreibe @moonbeamlabs, um den Lucas zu erwähnen, da ist für Twitter klar, das ist der Nutzer, mehr Information brauche ich auch nicht. Für Fediverse brauche ich noch die Information, auf welchem der Server dieser Nutzer sitzt.

Lucas Dohmen: Weil es keine zentralen Benutzerverzeichnisse gibt?

Nico Inden: Richtig, es gibt keine zentralen Benutzerverzeichnisse und dadurch ist eben auch keiner in der Lage alle Daten irgendwo zu sammeln und zentral zu korrelieren. Ich kann mich entweder einem Server, der schon existiert, anschließen, da gibt es ziemlich viele von oder ich kann sagen „Das ist mir trotzdem noch zu heikel, ich setze meinen eigenen auf“. Dann habe ich meinen VServer oder was auch immer und kann dort eine Mastodon-Instanz hochziehen und bin dann alleiniger Besitzer meiner Daten. Und diese Information darüber, wo jetzt ein Nutzer ist, brauche ich eben, um dann serverübergreifend zu kommunizieren.

Lucas Dohmen: Das heißt also, wie würde ich dann jemanden auf einem anderen Server adressieren, wie würde das funktionieren?

Nico Inden: Jetzt hast du zum Beispiel einen Account auf einem Mastodon-Server von INNOQ, dann würde ich dich erwähnen mit @[email protected].

Lucas Dohmen: Das heißt also ähnlich wie bei Emails?

Nico Inden: Genau.

**Lucas Dohmen. Das ist jetzt der förderierte Ansatz. Welche Rolle spielt jetzt das Protokoll da, an welcher Stelle kommt das in dieser Technologie vor?

Nico Inden: Das ActivityPub kommt ins Spiel, sobald mehrere Server miteinander kommunizieren. Nehmen wir nochmal ein Beispiel aus Twitter. Du kannst jemandem auf Twitter folgen, das kannst du genauso auf Mastodon tun, ich kann dir folgen, obwohl du auf einem anderen Server bist. ActivityPub wird dann nachher dafür benutzt, meinen Server zu informieren, wenn du auf deinem Server etwas Neues geschrieben hast.

Lucas Dohmen: Das heißt also für mich als Benutzer ist es genauso wie Twitter. Wenn ich meine Homepage aktualisiere, sehe ich deine Tweets oder Toots].

Nico Inden: Richtig. Es fühlt sich ganz genauso an. Jetzt muss man zu ActivityPub sagen: Das ist ein Anwendungsfall, in dem Kontext. ActivityPub wird aber noch in ganz, ganz vielen anderen förderierten Anwendungen genutzt und ist an sich erst einmal ein generisches Protokoll, das nur sagt: Ich interessiere mich für etwas und wenn es da Neuigkeiten gibt, informiere mich darüber. Das funktioniert genauso bei Nextcloud, wenn ich auf meiner Nextcloud-Instanz Daten teile und du dass auf deiner Instanz zur Verfügung haben möchtest. Das funktioniert genauso bei Friendica, das ist ein soziales Netzwerk, neben Mastodon auch noch im Fediverse, die nutzen alle im Hintergrund ActivityPub.

Lucas Dohmen: Aber das Protokoll ist so allgemein gehalten, dass ich damit jetzt auch mit dir meine Bilder teilen kann, obwohl wir auf zwei verschiedenen Nextcloud-Servern sind? Das gleiche Protokoll, aber vollständig verschiedener Use Case?

Nico Inden: Genau. Das ist ein bisschen wie „Ich sage Bescheid: Hier ist etwas Neues, also kannst du es von mir abholen“, auf Server-zu-Server-Ebene. Und das ist vielleicht auch ein ganz cooler Ansatzpunkt, um mal den Unterschied zu einem voll dezentralen, zu einem Distributed-Web-Ansatz zu zeigen, denn da kann ich natürlich genau das gleiche machen, ich habe nur diese Zwischenebene nicht mehr. In einem Distributed Web bin ich eben ein vollwertiger Knoten im gesamten Netzwerk, ich habe nicht mehr dieses „Ich melde mich an einem Server an und der redet mit anderen Servern“, sondern es läuft auf meinem Rechner gerade eine Software, die Teil des Netzwerks ist. Und wenn du jetzt Daten zur Verfügung stellst, dann meldest du diese Daten zum Beispiel in einem Peer-to-Peer-Netzwerk an und darüber kann ich dann erfahren, dass ich die von dir herunterladen kann, wenn ich möchte.

Lucas Dohmen: Ist das BitTorrent?

Nico Inden: Genau, ein BitTorrent ist genau dieser Ansatz. Du kannst entweder ein Torrent-File nehmen, in dem drin steht welche Datenblöcke mit welchen Hashes jetzt Teil der Datenübertragung sind oder Magnet-Links benutzen, die im Prinzip eigentlich nur ein Hash von diesem ganzen Dateninhalt sind und dann aus dem DHT holen.

Lucas Dohmen: Ich glaube, wir müssen mal ein bis zwei Schritte zurückgehen. Ich fange mal an: Ich habe das neue Ubuntu Base Image und ich möchte jetzt, dass die Welt das herunterladen kann, über BitTorrent von meinen Computer. Wie würde das funktionieren?

Nico Inden: Als erstes gehst du hin und erstellst von diesem Ubuntu Image ein Torrent-File. Wenn man jetzt ein Ubuntu Image nimmt, dann kriegt man das meist auch schon von der Webseite von Ubuntu, denn die machen genau das: Sie verteilen ihre Images von sich aus per Torrent. In diesem Torrent-File steht halt drin: Ich habe diese und jene Dateien, die ich verteilen möchte, die bestehen aus Blöcken und diese Blöcke haben diese und jene Hashes. Das sind dann SHA-256-Hashes von den einzelnen Blöcken und die kann ich dann nachher abfragen. Dieses Torrent-File verteile ich an Interessierte, die können das in einem Client öffnen, der dann entweder einen Tracker, wie das am Anfang funktioniert hat, also einen Server abfragt: „Wer stellt denn diese Blöcke, die ich herunterladen möchte, zur Verfügung?“. Oder man geht einen voll dezentralen Ansatz und ich erfrage diese Blöcke in einem Peer-to-Peer-Netzwerk.

Lucas Dohmen: Aber nochmal einen Schritt zurück zu diesem Tracker-Ansatz, ist das dasselbe wie förderiert? Also ist der Tracker-Ansatz für BitTorrent auch ein förderierter Ansatz oder ist das etwas anderes?

Nico Inden: Einen Tracker kann auch jeder aufsetzen. Das ist kein hochkomplexes Programm, das merkt sich schlicht und ergreifend welche Peers etwas zur Verfügung stellen und das war es.

Lucas Dohmen: Okay, also einfach nur eine Liste von „Diese Leute haben Daten für diesen Hash“?

Nico Inden: Genau und das kann auch jeder aufsetzen, deshalb ist es ein förderierter Ansatz.

Lucas Dohmen: Okay. Und was ist dann anders bei diesem Magnet-Link?

Nico Inden: Da habe ich nicht mehr diese Anlaufstellen, die ich nach dem Inhalt frage, sondern ich habe ein Netzwerk aus Teilnehmern, worüber ich das auflöse. Das Stichwort ist hier DHT, also Distributed Hash Table. Ich habe also ein Netzwerk von vielen Teilnehmern, an die ich Fragen stellen kann. Ich habe eine verteilte Tabelle, in die ich meinen Hash reinschmeiße oder kann einen Lookup nach diesem Hash machen und dann eine Antwort aus dem Netzwerk zurück kriegen, welche Knoten im Besitz der Daten sind, die ich haben möchte.

Lucas Dohmen: Ich muss mich also nicht mehr an einen bestimmten Tracker wenden, sondern ich wende mich quasi an das gesamte Netzwerk?

Nico Inden: Genau, an einen beliebigen Teilnehmer dieses Netzwerks. Der Teilnehmer muss die Antwort auf deine Frage auch nicht selbst wissen, sondern kann das dann rekursiv weiterleiten und im Netzwerk dann die Antwort auflösen.

Lucas Dohmen: Das heißt also, jeder kennt ein paar andere und trägt die Frage einfach weiter bis eine Antwort gefunden ist?

Nico Inden: Genau.

Lucas Dohmen: Okay, das ist jetzt BitTorrent. Was ist jetzt IPFS, ist das etwas ähnliches oder etwas ganz anderes?

Nico Inden: IPFS setzt noch oben drauf. BitTorrent wird verwendet in IPFS, wir sagen immer, dass Mechanismen von BitTorrent in IPFS verwendet werden. An sich, wenn man es wörtlich nimmt, ist IPFS ein Dateisystem. InterPlanetary File System heißt es, wenn man das Ganze ausspricht. Die Grundidee dahinter ist, dass ich Daten zur Verfügung stellen kann und andere dann eine Frage stellen können an das Netzwerk „Wer hat denn die Daten zu diesem und jenem Hash“? Jetzt kommen da noch Ideen von Git rein; ich kann Verzeichnisse zur Verfügung stellen, die einen eigenen Hash haben und wenn ich in diesem Verzeichnis Daten ändere, dann ändert sich natürlich der Hash dieser Datei, aber auch der Hash des Verzeichnisses, wodurch ich dann eine Versionierung habe, da kommen noch ein paar Dinge hinzu, die eigentlich ganz cool sind.

Lucas Dohmen: Okay. Ich will jetzt meine Webseite über IPFS verteilen, dann habe ich eine index.html und eine index.css, mehr habe ich erst einmal nicht, eine einfache Webseite. Wie kommt dann da ein Hash raus? Das habe ich noch nicht verstanden.

Nico Inden: Man kann sich das ein bisschen wie eine Baumstruktur vorstellen. Ich habe ja in meinem Dateisystem auch irgendwo ein Verzeichnis oder einen Teilbaum, in dem diese index.html und index.css drinliegen und in diesem Minimalbeispiel hätte ich jetzt drei Hashes. Einmal logischerweise die zwei Hashes für die Dateien und ein Hash für das Verzeichnis, in dem diese Dateien liegen.

Lucas Dohmen: Das bedeutet ich habe jetzt einen neuen Blogpost für meine Seite geschrieben, ich habe das CSS nicht verändert, dann ändert sich der Hash von meiner index.html, aber nicht von meiner index.css und dadurch verändert sich aber auch der von meinem Gesamtverzeichnis, richtig?

Nico Inden: Genau. Ich kann also, wenn ich über IPFS meine geänderte Version zur Verfügung stelle, über den neuen Verzeichnis-Hash auf die neue Version zugreifen, über den alten Verzeichnis-Hash aber immer noch auf meine alte Version zugreifen.

Lucas Dohmen: Das bedeutet, das ist ein System, das nicht vergisst, das heißt alte Sachen können immer weiter bestehen?

Nico Inden: Genau, das ist eine der Intentionen, dass Dinge nicht verloren gehen, es ist aber immer noch die Frage, ob dieser Inhalt auch zur Verfügung gestellt wird. Ich kann auf meinem lokalen IPFS-Knoten Daten hinzufügen und dann stellt dieser Knoten diese Daten auch zur Verfügung, wenn andere Teilnehmer dieses Netzwerks diese anfragen, aber wenn ich irgendwann meinen Knoten herunternehme und kein anderer in der Zwischenzeit diese Daten angefragt hat, dann sind sie natürlich auch raus aus dem Netzwerk.

Lucas Dohmen: Aber das heißt, wenn ich den Hash bekommen habe für die erste Version von meinem Blog, dann kann ich von dieser erst einmal nicht darauf schließen, was die neue Version von dem Blog ist, in dem dann ein Blogpost mehr drin ist, richtig?

Nico Inden: Nee, darauf kann ich nicht schließen.

Lucas Dohmen: Weil es rein inhaltsbasiert ist?

Nico Inden: Richtig, es ist ein Content Address Protocol, das heißt, ich sage nicht, von welchem Server ich einen Inhalt haben möchte, sondern ich sage einfach nur, dass ich diesen Inhalt möchte und IPFS findet dann heraus, von wo ich diesen Inhalt am günstigsten kriege.

Lucas Dohmen: Das ist dann so ähnlich, wie du es eben bei BitTorrent erklärt hast mit einer Distributed Hash Table, dass er sich durch das Netzwerk sucht, bis er es dann irgendwo findet. Das heißt aber auch, dass, wenn ich so einen Knoten habe, dass ich dann für mich offline meine Lieblingsblogs alle sammeln kann, richtig? Also die aktuelle Version von allen herunterladen kann?

Nico Inden: Das passiert ein bisschen automatisch. Wenn ich auf IPFS-Content zugreifen möchte, dann habe ich erst einmal zwei Möglichkeiten. Die erste Möglichkeit ist, ich setze einen eigenen IPFS-Knoten bei mir auf und kann mir dann direkt, Peer-to-Peer, die Inhalte, die mich interessieren, holen. Die Alternative ist - ich möchte das ja wahrscheinlich gerne über den Browser machen - also setze ich ein IPFS-to-HTTP-Gateway auf, der ist netterweise in IPFS in der [20:00]-Implementierung von IPFS schon mit drin. Das heißt, ich kann über den Browser bestimmte IPFS-Hashes anfragen und kriege die dann dort angezeigt. Das heißt also das Herunterladen, die Offline-Fähigkeit ist quasi mit eingebaut. Automatisch, wenn ich solch einen Knoten benutze.

Nico Inden: Genau. Das liegt daran, dass wenn ich Content irgendwo anfrage und ihn mir lokal anschaue, dann ist dieser Content ja de facto auf meinem Rechner gelandet und ich bin dann auch zum Verteiler dieses Contents geworden. Wenn du also deinen Blog aktualisierst und jemand liest diesen Blog, dann ist er selbst auch Verteiler dieser Information. Da gab es ein ganz cooles Beispiel für jemanden, der sich gesagt hat „Ich mache meinen Blog über IPFS“. Das hat über statische Webseiten-Generierung funktioniert und er hat gesagt „Ich mache einen VServer in den USA, einen in Europa und einen in Asien“, sodass die Latenzen, wer auch immer zugreift, möglichst gering sind. Ich werde mal schauen, ob wir für die Shownotes den Link kriegen. Das Interessante an der Geschichte war ein Blog-Beitrag, der richtig stark eingeschlagen ist und er konnte mit diesen drei wirklich nicht groß dimensionierten, billigen VServern eine große Anzahl von Nutzern problemlos bedienen, weil das Ganze eben über IPFS verteilt wurde und alle Leute, die das sehen wollten, selbst zu Verteilern geworden sind. Thema Skalierbarkeit.

Lucas Dohmen: Das heißt: Das, was man im Web über ein CDN - ein Content Delivery Network - machen würde, braucht man gar nicht, weil das quasi automatisch passiert?

Nico Inden: In dem Fall ist das mit integriert, genau.

Lucas Dohmen: Das heißt: Einfach nur dadurch, dass ich meinen Content auch noch auf meinem australischen Server ablege ist das eine Kopie und jemand, der das haben möchte, kann es auch aus Australien laden?

Nico Inden: Richtig, genau. Da gibt es bei IPFS auch die Möglichkeit zu sagen, dass ein Knoten den Inhalt eines anderen Knotens per se immer replizieren soll und darüber wurden diese drei IPFS-Knoten im Prinzip verbunden. Er brauchte also nur an einer Stelle den neuen Content hochladen und die anderen zwei Knoten haben das dann per se schonmal repliziert und jede Anfrage wurde aus der günstigsten Region beantwortet. Selbst wenn jetzt eine mal down gegangen wäre, wären immer noch zwei andere da gewesen, um das zu übernehmen.

Lucas Dohmen: Zugleich ist es natürlich so: Je beliebter der Blogpost wird, desto mehr Leute haben ihn, also load balanced sich das quasi selbst.

Nico Inden: Genau, das load balanced sich am Anfang selbst, gerade wenn jetzt viele Leute einen neuen Blogbeitrag sehen wollen oder einen bestimmten Inhalt. Es gibt aber auch sogenannte Pinning Services. Wenn ich etwas längerfristig zur Verfügung stellen möchte, ist natürlich die Frage: Wie kriege ich jemand anders dazu bewegt, meinen Inhalt lange zur Verfügung zu stellen? Wenn ich selbst zum Beispiel nicht dazu in der Lage bin einen Server zu betreiben, auf dem das dauerhaft drauf ist. Da gibt es etwas, das nennt sich Pinning Service, da kann ich gegen Einwurf von Münzen jemanden bitten „Wenn ich etwas bei mir in IPFS hinzufüge, dann lade das doch bitte auf deinen IPFS-Knoten und stelle es auch zur Verfügung“. Das nennt sich dann Pinning. Gleich noch eine kurze Ergänzung: Das Rüberladen auf den Knoten passiert natürlich sobald dieser andere Knoten sich diese Daten anschauen möchte, aber irgendwann kommt bei einem IPFS-Knoten der Garbage-Collector und sagt „Hey, du hast jetzt schon soviele Sachen bei IPFS angeschaut, jetzt lösche ich mal hier den Cash, um wieder Platz zu schaffen.“ Genau das umgehe ich halt mit diesem Pinning, ich sage „Den Content, den habe ich jetzt geladen und der soll bitte auch nicht vom Garbage Collector gelöscht werden“.

Lucas Dohmen: Aber jetzt habe ich natürlich das Problem: Ich möchte ja immer die neueste Version von deinem Blog lesen, das heißt jetzt einmal den Hash herauszufinden, hilft mit nicht viel, denn der wird sich ja ändern, wenn du das nächste Mal postest. Wie löst man denn das? Über den Hash des Contents hinaus gibt es noch einen weiteren Hash, das ist nämlich der meiner Peer-ID. Ich habe einen IPFS-Knoten mit einer bestimmten ID und ich kann jetzt den neuesten Content-Hash an meine Peer-ID koppeln. Das heißt, wenn jetzt jemand hingeht und löst nicht den Content-Hash auf, sondern fragt einfach nach meiner Peer-ID, dann kriegt der den neuesten Content-Hash geliefert. Dann muss ich natürlich als Seitenbetreiber daran denken, wenn ich den neuen Inhalt hochgepusht habe, dass ich dann auch den neuen Content-Hash an meine Peer-ID hänge, aber das kann man ja automatisieren. 24:58

Lucas Dohmen: Aber das muss ich mir so ähnlich vorstellen wie eine Domain, ne? Hinter der Domain liegt keine IP-Adresse, sondern ein Hash. Richtig?

Nico Inden: Genau, die Anfrage ist dann im Prinzip ipns/peer_id und aus dem Netzwerk kriege ich dann die entsprechende Content-ID zurück, die jetzt gerade an diesem Peer dranhängt. Es ist immer noch alles ein bisschen frickelig und man muss sich mit der Sache auseinandersetzen. Man kann noch einen Schritt weitergehen und die eigene Peer-ID als TXT-Eintrag bei einer Domain im DNS hinterlegen. Dann kann ich sogar darüber auch an IPFS-Inhalte weitergeleitet werden.

Lucas Dohmen: Hänge ich da dann meine IPNS-Namen dran oder wirklich den Hash von dem Inhalt, den ich verteilen will?

Nico Inden: Es geht beides. Ich kann einen Inhalts-Hash als TXT-Eintrag machen an der Stelle, das macht aber insofern nur bedingt Sinn, als dass der sich jedes Mal ändert. Aber wenn ich meine Peer-ID, die sich hoffentlich nur sehr, sehr selten ändert, dort hinterlege, kann ich die Domain auflösen, mein IPFS-Gateway kann dann die Peer-ID entdecken und auflösen und ich komme an den Content.

Lucas Dohmen: Okay, jetzt stelle ich mir vor, ich möchte von deinem Blog - wir tun jetzt mal so, als wäre der „nico.de“ - möchte ich deinen neuesten Content sehen. Wie würde das funktionieren?

Nico Inden: Ich würde hingehen und, wie eben beschrieben, meine Peer-ID heraussuchen und bei meiner Domain „nico.de“ als TXT-Eintrag hinterlegen. Da steht dann TXT-Link = /ipns/meine_peer_id und damit habe ich jetzt erstmal alles vorbereitet. Jetzt gucken wir uns mal auf der anderen Seite an: Es kann jemand mit seinem IPFS-Knoten hingehen und nicht mehr /ipfs/hash auflösen, sondern kann jetzt sagen „Gib mir mal bitte den Inhalt, der hinter /ipns/nico.de steckt“. Dann geht im Hintergrund der Knoten hin, macht einmal eine DNS-Auflösung - das ist das Opfer, das ich an der Stelle bringen muss, wenn ich einen Namen und keinen Hash haben möchte - und holt sich dann meine Peer-ID aus dem TXT-Eintrag heraus und ab da ist es eine ganz normale IPNS-Auflösung meiner Peer-ID. Ich frage also das DHT „Wer ist diese Peer-ID und was für einen Content hat sie gerade verbunden?“ und kriege dann diesen Content heraus und kann ihn wiederum auflösen und im Netzwerk fragen „Wer kann mir diesen Inhalt überhaupt liefern?“

Lucas Dohmen: Brauche ich nur wie im Web eine Domain zu kennen und kann auf deine Inhalte zugreifen?

Nico Inden: Genau, mit der kleinen Einschränkung eben, dass ich dann einen quasi-zentralen Schritt habe, dass ich noch ein DNS brauche.

Lucas Dohmen: Und wo sind die Nachteile oder Probleme mit diesem IPFS oder dem Distributed Web im Allgemeinen?

Nico Inden: Wir haben ja schon gemerkt, dass wir teilweise ein wenig technisch geworden sind. Das Ganze ist halt noch eine Menge Handarbeit: Man schreibt sich Skripte, die Content pushen, die Content an Hashes dranhängen und so weiter, das ist also noch nicht so wirklich für den durchschnittlichen Endnutzer fertig. Da gibt es zwar Ansätze, die das versuchen, aber oft ist das eben noch nicht so einfach. Dann kommt noch hinzu, dass viele förderierte oder dezentrale Ansätze noch nicht die kritische Masse haben. Wir haben anfangs gesagt „Warum gehe ich zu WhatsApp? Weil da alle anderen Leute sind, die ich kenne, also gehe ich dahin.“ Das ist im Moment noch nicht so. Die meisten Leute, die man kennt, sind eben noch bei den Großen, deshalb ist das Incentive für einen selbst, wenn man nicht gerade ideologisch bewegt ist, relativ gering, zu einem von den förderierten oder distributed Lösungen zu gehen.

Lucas Dohmen: Gibt es denn Ansätze oder Ideen, wie man das verbessern könnte?

Nico Inden: Ja, absolut. Um einen leichten Einstieg zu kriegen, picke ich mir mal ein Beispiel bei Twitter und Mastodon heraus. Ich selbst habe ja meinen Twitter-Account als [30:26 Smash-Net] und bin auch auf Mastodon vertreten. Da gibt es jetzt einen Service, der sich moa.bridge [30:35 Anm.: Ich habe nur moa.party gefunden?] nennt, da kann man auf die Webseite gehen und das ist im Prinzip eine Art Crossposter. Der kriegt Tokens und Berechtigungen auf meinen beiden Accounts, um dort zu schreiben und erkennt dann, wenn ich auf Mastodon etwas schreibe, dann crosspostet er das auf meinem Twitter-Account und umgekehrt. Das funktioniert wirklich hervorragend, so kann ich beide Seiten auch bedienen.

Lucas Dohmen: Kannst du dann auch mit Mastodon einem Twitter-Account folgen?

Nico Inden: Es geht hier nur um Crossposting an der Stelle.

Lucas Dohmen: Achso, verstanden. Gibt es denn bei IPFS auch etwas Ähnliches?

Nico Inden: Bei IPFS ist es so, dass es ein HTTP-Gateway gibt, damit ich IPFS-Inhalte in meinem Browser anzeigen kann. Der kann entweder auf meinem lokalen IPFS-Knoten laufen, ich kann aber auch hingehen und IPFS-Gateways, die von anderen zur Verfügung gestellt werden, nutzen. Also auch auf „ipfs.io“ wird zum Beispiel auch ein öffentlicher HTTP-Gateway betrieben, sodass ich mir mit ipfs.io/ipfs/hash ganz normal im Browser IPFS-Inhalte anzeigen lassen kann, ohne selbst einen eigenen Knoten zu betreiben. Das ist natürlich für die Ideologie des Gesamtnetzwerkes nicht das, wo man hin möchte, man möchte dahin, dass jeder seinen eigenen Knoten betreibt und voller Teilnehmer ist, aber es ist schonmal etwas, um die Leute, die es nicht betreiben, da hinein zu kriegen.

Lucas Dohmen: Okay, verstehe. Dann danke ich dir für den Überblick und den Hörerinnen und Hörern, bis zum nächsten Mal!

Nico Inden: Tschö zusammen!