Durch die YouTube-Alternative DTube bin ich auf IPFS gestoßen, das damit die Videos verteilt und ausfallsicher speichert. IPFS bezeichnet sich selbst als »verteiltes Web«, also als einen Datenspeicher, der nicht an einen Server gebunden ist, sondern dessen Inhalte verteilt gespeichert sind. Im Gegensatz zum herkömmlichen Web werden dafür Inhalte nicht anhand ihres Speicherorts (Server + Pfad + Name) adressiert, sondern über eine eindeutige Kennung CID (Hash-Wert des Inhalts), die dann mithilfe eines Verzeichnisses DHT einem konkreten Speicherort zugeordnet wird.
Diese Technik der Adressierung (»another layer of indirection«) wird zum Beispiel auch vom Betriebssystem für die Speicherverwaltung verwendet: virtuelle Adressen (analog zu CID) werden über die Page-Table in physische Adressen (analog zur URL) überführt.
Da die Kennung vom Inhalt ableitet wird, ist damit das Objekt eingefroren und kann nicht mehr verändert werden. Ein Umstand, dessen man sich zum Beispiel auch bei git bedient, wenn Änderungen einer Datei zwangsweise zu einem neuen Commit führen sollen.
Da die Objekte unveränderlich sind, können sie problemlos dupliziert und im Verzeichnis DHT mehrere Speicherorte hinterlegt werden. So erhöht sich die Ausfallsicherheit und die Objekte werden bei hinreichender Verbreitung unlöschbar.
Welches Problem soll durch IPFS gelöst werden?
Im wahren Leben ist die Bestimmung von Objekten über ihren Inhalt die geläufigere Form, da dies sie freier werden lässt – ein Objekt kann umplatziert oder vervielfältigt und an verschiedenen Orten abgelegt werden.
Als Vergleich zum realen Leben könnte man hier Produktkenncodes (EAN) nennen, über die man Artikel auffinden kann, ohne dass man sich auf einen bestimmten, festgesetzten Standort (Geschäft, Gang, Regal, Einschub) bezieht. Ebenso nutzt man Titel, Autor und Verlag als Kennzeichnung für Bücher und spricht nicht von Küchenregal, 3. Buch von links.
Aber diese Form des Auffindens benötigt immer den Zwischenschritt der Konkretisierung auf einen Ort: (1) um ein Buch in einer Bibliothek zu finden, muss man erst den Katalog aufsuchen, in dem die Zuordnung Name–Standort hinterlegt ist; (2) um eine Bratpfanne zu finden, muss man wissen, dass diese in der Küche in einem Schrank ist und wie sie aussieht.
Einfacher wäre zwar die Bestimmung über »das Ding oben, links, hinten im großen Schrank in der Küche« – aber dann darf niemand umräumen. Denn genau das ist im Internet das Problem: Web-Links funktionieren nicht mehr, wenn jemand die Ressource »wegräumt«. Die Adressierung über den Bezugsort ist zwar einfach, aber fehleranfällig.
Deshalb ist bei IPFS der neue Ansatz, Objekte anhand einer eindeutigen Kennung zu identifizieren, womit es unerheblich wird, wo das Objekt liegt. Der konkrete Ort eines Objekts wird bei IPFS über eine verteilte Datenbank DHT (distributed hash table) ermittelt – denn auch im Internet ist dieser Zwischenschritt notwendig. Dies geht sogar so weit, dass auch die IP-Adressen in einem zweiten Schritt in der DHT nachgeschlagen werden, also DNS umgangen wird.
Da das Verzeichnis wesentlich kleiner ist als die eigentlichen Inhalte (ähnlich wie der Katalog nur einen Bruchteil der Bibliotheksfläche ausmacht), kann er leichter vervielfältigt und ausfallsicher gestaltet werden.
Dieses Verzeichnis ist ein Key-Value-Store, in dem für ein Objekt mehrere Server und für einen Server mehrere Kommunikationswege (z. B. IP-v4, IP-v6) hinterlegt werden. Die Daten können daher redundant und damit ausfallsicherer abgelegt werden.
Konkret sie es so aus, dass man für ein Objekt eine CID hat und diese zum Beispiel im IPLD-Explorer ansehen kann. Dort kann man auch zum IPFS-Gateway wechseln und sich direkt das Objekt ansehen. Über diesen IPFS-Gateway kann man auch auf herkömmlichen Webseite auf Inhalte im IPFS verweisen. Hat man im Browser die Erweiterung für IPFS installiert hat, greift der Browser selbst auf IPFS zu und geht nicht den Umweg über den Gateway.
Verteilung von Daten
(Wie die DHT funktioniert, kann ich leider nicht sagen.)
Die Daten sind analog zu einem normalen Dateisystems innerhalb eines Betriebssystems strukturiert: (1) als kleinste Einheit gibt es Datenblöcke. (2) Mehrere Blöcke mit zugehörigen Angaben wie dem Datentyp bilden eine Datei in der UnixFS-Schicht; analog zu Inodes in Betriebssystemen. (3) Diese Dateien können in einer Hierarchie über das MFS (mutable file system) organisiert werden; analog zu Dnodes in Betriebssystemen.
Wie man es bereits von git kennt, wird bei der Speicherung nicht zwischen diesen Typen unterschieden, sondern alles sind Objekte, die eine CID erhalten und einheitlich in der DHT eingetragen und im System nach den gleichen Regeln verteilt werden.
Ein Knoten, der am Netzwerk teilnimmt, arbeitet wie ein Cache, der Daten, die ein Client anfordert, speichert und nach bestimmten Kriterien auch wieder löscht. Wenn auf Daten also nicht zugegriffen wird, können diese auch aus dem Netzwerk verschwinden – wenn kein Interesse vorhanden ist, altern die Daten aus.
Um diesem Vorzubeugen, kann man auch auf seinem eigenen Server interessante Daten festsetzen (pinning), so dass sie vor dem Löschen geschützt sind. Es wird also im gesamten Netzwerk immer mindestens diesen Knoten geben, der die Daten bereitstellt.
Damit man aber auch Daten aus dem Netzwerk gezielt entfernen kann, wurden schwarze Listen (blacklists) geschaffen. Ein Server kann diese Listen beziehen und freiwillig die eingetragenen CIDs nicht annehmen. Sollte ein Rechteinhaber die Unterlassung der Verbreitung bestimmter Daten fordern, kann man gezielt diese CIDs blockieren.
Der Ablauf bei einer Veröffentlichung ist also immer der:
- man startet seinen eigenen Server und wird Teil des Netzwerks
- man fügt über seinen Server eine neue Datei ein, für deren CID sich dieser in der DHT einträgt
- andere Server greifen auf die Daten zu und duplizieren sie auf ihr System
Veränderbarkeit
Die Unveränderbarkeit ist für viele Daten gewünscht und genau passend. Aber es gibt auch veränderliche Inhalte und sei es nur, dass diese Erweitert werden. Dabei entsteht immer wieder eine neue CID, weshalb die neue Version nicht über die alten Verweise auf die alte CID erreicht wird.
Deshalb gibt es zwei Konzepte: DNSLink und IPNS, die einen veränderlichen Verweis auf einen Knoten ermöglichen. Da der Knoten auch der Anfang einer kompletten Dateihierarchie seien kann, lässt sich somit eine Webpräsenz mit Texten, Bildern und Dateien über IPFS veröffentlichen.
DNSLink nutzt TXT-Einträge in DNS, um immer die aktuelle CID für eine Domain zu bestimmen.
% host -t TXT _dnslink.docs.ipfs.io
_dnslink.docs.ipfs.io descriptive text "dnslink=/ipfs/QmeuAjzFimmJCSM5aLyfLEfASAukhBH2nXVKjr663dnhNT"
IPNS wiederum basiert auf der DHT. Für einen veränderbaren Knoten wird ein Schlüsselpaar erzeugt und die Kennung des öffentlichen Schlüsselteils als Adresse genutzt. Somit kann immer wieder ein neuer Hauptknoten für die Webseite mit der entsprechenden Signatur veröffentlicht werden.