Signal IPFS hashes in HTTP headers

[flyingzumwalt]

This is described in an issue @nicola wrote in IPFS/notes

More info to come.

[ghost]

I'm not sure which notes issue you are referring to. Is this about having the websockets transport listener on the gateway? We've got it covered in #34 and in fact already have a hacky gateway-listener on https://strawberry.i.ipfs.io/ and https://blueberry.i.ipfs.io/ -- this is through nginx hackery at the moment, ideally the websockets listener will work out of the box with the go-ipfs gateway, e.g. also on localhost:8080.

[nicola]

This is a follow up from this: ipfs/notes#184

The idea is that one could use HTTP requests to gateway.ipfs.io (or any other gateway) that mount /ipfs or /ipfs/hash and announce it in the HTTP Headers, so that we could intercept that, add the gateway as a peer and serve that request via IPFS. In this way you can have a somewhat web-compatible IPFS.

How does that sound?

[ghost]

I have no idea what you're talking about :)

[ghost]

Okay I think I understand. This boils down to sending a header which signals the respective hash of the response entity, and somehow signaling that there's websockets transport mounted on the same gateway.

[nicola]

@lgierth I am sorry, when I wrote that, I felt it was really condensed and rushed. It is about what you are saying, but let me write it here for the reader:

1. Web browser does an HTTP GET on a web address
2. HTTP Response announces:
   • the IPFS path that is mounted behind that URL, for example:
     • http://gateway.ipfs.io/ mounts /
     • http://nicola.io/blog mounts /ipfs/nicolahash/blog
   • (optional) the multiaddress of the website serving this data on IPFS
3. Web browser intercepts the hash and the multiaddress and proxy that request via IPFS

[ghost]

Closing in favor of #50