Ich möchte einen Verweis auf eine Datei für alle verfügbar machen. Das heißt, du sollst einfach eine HTTP-URL aufrufen können und an die Datei kommen ohne eine eigene IPFS Node.

Da du in diesem Fall aus dem HTTP Kosmos in den IPFS Kosmos wechseln willst, braucht es Instanz dazwischen, die mit beiden Welten kommunizieren kann: ein Gateway.

Der Entschluss ist gefasst, nun drängen sich die Fragen auf:

• Welche Public IPFS Gateways gibt es überhaupt?
• Welches soll ich benutzen?

Wenn du weiter liest, nehme ich dich mit auf meine Entdeckungsreise und wir können gemeinsam versuchen diese Fragen zu beantworten.

Frage 1: Welche Public IPFS Gateways gibt es überhaupt?

Dazu habe ich die Ressource gefunden: https://ipfs.github.io/public-gateway-checker/
Bei mir sah das zum Testzeitpunkt so aus:

Ok super, ich habe neue Gateways kennengelernt. Bisher kannte ich nur ipfs.io.

Wir nehmen uns jetzt einfach alle die Online sind und vergleichen sie.
Dazu habe ich einen Verweis im IPNS erstellt, gegen den wir prüfen. Was IPNS ist könnt ihr hier oder hier nachlesen und wie ich den Link erstellt habe ist in diesem Post beschrieben.

Frage 2: Welchen soll ich benutzen?

Test 1: Antwortzeiten messen

Als ersten Test versuchen wir mal die Datei hinter unserem IPFS Link zu laden.
Dazu habe ich jeden Gateway 3x hintereinander abgefragt und dabei die Zeit gemessen.
Der Befehl dazu:
time curl https://JEWEILIGE_GATEWAY_ADDRESSE/ipns/QmeUET...ER7

Die Daten habe ich verdichtet und so kommt diese Tabelle raus:

Anfrage URL	Antwortzeiten 1, 2, 3
https://ipfs.io/ipns/QmeUET...ER7	1m58.668s, 1m18.315s, 1m1.908s
https://gateway.ipfs.io/ipns/QmeUET...ER7	0m1.712s, 0m1.905s, 0m1.826s
https://siderus.io/ipns/QmeUET...ER7	0m37.366s, 0m1.663s, 0m1.922s
https://ipfs.infura.io/ipns/QmeUET...ER7	0m22.676s, 0m2.107s, 0m2.116s
https://www.eternum.io/ipns/QmeUET...ER7	0m47.093s, 0m2.015s, 0m1.703s
https://hardbin.com/ipns/QmeUET...ER7	0m54.465s, 0m21.888s, 0m1.567s
https://ipfs.jes.xxx/ipns/QmeUET...ER7	0m1.590s, 0m14.685s, 0m1.711s
https://ipfs.wa.hle.rs/ipns/QmeUET...ER7	0m42.369s, 0m3.035s, 0m2.844s
https://xmine128.tk/ipns/QmeUET...ER7	0m27.670s, 0m2.595s, 0m1.767s

• Der erste Messwert ist meistens hoch
  • Vermutlich ist der Response danach gecached.
  • Es sieht so aus, als wäre die Verbindung zum Gateway schnell hergestellt, aber dessen Antwort dauert unterschiedlich lange. Je nachdem, ob der IPNS-Record auf dem Gateway gecached ist oder nicht.

Test 2: Zeitabschnitte messen

Wenn unsere Annahme aus Test 1 richtig ist, dann müssten wir immer schnell eine Verbindung zum Server herstellen können, aber der Server braucht unterschiedlich lang für eine Antwort.
Das testen wir mal:
curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total} https://JEWEILIGE_GATEWAY_ADDRESSE/ipns/QmeUET...ER7

Auch diesmal gilt: 3x jeden Server Anfragen und zusätzlich folgende Zeiten messen:

Im Befehl	In der Grafik	Beschreibung
time_connect	init	Die Zeit, die wir brauchen, um uns mit dem Server zu verbinden.
time_starttransfer	start	Die Zeit, die es dauert, bis der Server anfängt uns zu Antworten.
time_total	-	Die Zeit von Start bis Ende. Von unserer Anfrage bis die Antwort bei uns angekommen ist.

Da das noch komplexer wird, habe ich das mal visualisiert. Dazu das gemessene Minimum (der schnellste Wert) und das gemessene Maximum (der langsamste Wert).
Es gilt: Je kleiner der Balken, umso schneller kam die Antwort. Kleiner ist in dem Fall besser :)

• In der Grafik über den Maximalwert fällt auf, dass "ipfs.jes.xxx" und "siderus.io" immer schnell antworten.
  • Unserer Annahme nach müsste erste Aufruf aber immer länger dauern.
  • Das würde bedeuten, es sind schnelle Cache-Ergebnisse.
  • Wie kann es dann sein, dass die 2 auch initial so flott antworten?

Test 3: Wir prüfen die Server

Dazu lösen wir auf welche Server hinter den Domains liegen:

Domain	Server-IP(s)	Standort	Bemerkung
ipfs.io	217.182.195.23 147.135.130.181	FR (OVH SAS)
gateway.ipfs.io	217.182.195.23 147.135.130.181	FR (OVH SAS)	Das war naheliegend :)
siderus.io	104.27.158.37 104.27.159.37	Cloudflare	vermutlich 104.198.14.52 USA (Google Cloud, CA)
ipfs.infura.io	34.192.181.130	Amazon EC2
www.eternum.io	104.31.66.146 104.31.67.146	Cloudflare	Konnte keine Infos zu dahinter liegenden Servern finden.
hardbin.com	178.62.243.230	NL (DigitalOcean Amsterdam)
ipfs.jes.xxx	178.62.243.230	NL (DigitalOcean Amsterdam)
ipfs.wa.hle.rs	165.227.15.228	US (DigitalOcean, LLC, NY)
xmine128.tk	94.199.213.140	DE (VCServer Network oHG)

ipfs.jes.xxx und hardbin.com zeigen auf den selben Server. Damit ist klar, warum ipfs.jes.xxx in der Grafik so gut abschneidet. Ich hatte ja direkt vorher hardbin.com getestet und somit ist das Ergebnis vermutlich im Cache.

Nun bleibt die Frage: Was ist mit siderus.io? Warum ist der so schnell?

• Es könnte sein, dass er letztendlich auch nur auf einen anderen Server verweist, den ich vorher schon getestet hatte. Dazu kann ich nichts eindeutiges herausfinden.
• Oder er ist wirklich, selbst bei einer ungecachten Anfrage, so flott.
• Oder er hält den Cache noch seit unserer allerersten Anfrage von Test 1 vor.
• Oder etwas, was mir noch nicht einfällt :)

Schauen wir mal weiter in die Richtung!

Ich mach meine Abfrage einfach 1h später nochmal:

curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total} https://siderus.io/ipns/QmeUET...ER7
0.090:0.882:0.907

Rennt immer noch. Angeblich wird der Wert für 24h gecached. Ich weiß nicht, ob das stimmt. Ich habe gesehen, dass ich beim "publish" eine TTL mitgeben könnte. Wie ich hinterher die TTL auslese für ein IPNS Record weiß ich leider (noch) nicht.

Gut, anderer Ansatz:
Wir adden einfach eine neue Datei ins IPFS und erneuern unseren IPNS Record. Danach prüfen wir, ob uns der Server wirklich die neue Datei liefert oder noch mit einem alten Cache-Hit antwortet.

Test 4: IPNS Record Update prüfen

added QmSe4g...FxfqG
ipfs name publish QmSe4g...FxfqG
Published to QmeUET...ER7: /ipfs/QmSe4g...FxfqG

Also Link auf neue Datei steht. Wir machen die Abfrage auf den IPNS Record über siderus.io:

curl -s -w %{time_connect}:%{time_starttransfer}:%{time_total} https://siderus.io/ipns/QmeUET...ER7
0.085:0.709:0.754

Das ging sehr flott, aber meine Änderung ist nicht drin. Das heißt, wir haben die veraltete Datei erhalten (vermutlich Cache-Treffer).

Gegentest - Wir prüfen bei gateway.ipfs.io:

curl -s -w %{time_connect}:%{time_starttransfer}:%{time_total} https://gateway.ipfs.io/ipns/QmeUET...ER7
0.287:73.130:74.435

Das dauert eine halbe Ewigkeit (über 1 Minute), aber dafür haben wir die neue Datei erhalten. Meine Änderung ist drin.

Daraus kann ich nur schlussfolgern, dass die Gateway-Server unterschiedlich cachen.

Was mache ich nun mit der Info? Soll ich einen schnell antwortenden Server nehmen, der vermutlich 1 Tag lang ein veraltetes Ergebnis ausliefert oder einen Server der für so gut wie jeden Anfrage eine Minute braucht?

---

	Die hier gezeigten Daten sind keine Bewertung der IPFS Gateways. Es handelt sich nur um eine Stichprobenanlayse zu einem bestimmten Zeitpunkt.

---

Fazit

Ich weiß noch nicht, wie ich meine Datei publizieren soll. Ich bin voller Begeisterung gestartet und dachte mir: Wenn du jetzt schon den Feed in der Steem Blockchain veröffentlichst, dann nutzt du natürlich auch das dazugehörige dezentrale System.
Die Schwierigkeit kam auf, da ein Gateway überhaupt benötigt wird. Wünschenswert wäre ein Client der direkt IPFS kann, aber das ist kurzfristig unrealistisch. Also kann ich entweder meine coole Datei in der alten Welt einfach schnell jedem verfügbar machen und alles geht simpel und performant oder ich benutze eine Krücke (IPFS Gateway), die eine Verbindung zwischen dem alten bekannten HTTP basierten Web und dem IPFS permanent Web herstellt.

Vermutlich werde ich den Weg mit der Krücke wählen. Auch wenn es noch nicht so gut funktioniert, ist das der einzige Weg den Fortschritt voran zu bringen und zu testen.

---

Ich freue mich auf euer Feedback und eure Tipps!