ipfs / community

Discussion and documentation on community practices
https://docs.ipfs.tech/community/
MIT License
416 stars 226 forks source link

Use *.ipfs.io Subdomains for Insulating Sites Hosted on ipfs.io #319

Open ilyaigpetrov opened 6 years ago

ilyaigpetrov commented 6 years ago

IPFS team sustains a great https gateway on ipfs.io (e.g. https://ipfs.io/ipfs/<hash>/file, https//ipfs.io/ipns/<hash>). Example: https://ipfs.io/ipfs/Qme2sLfe9ZMdiuWsEtajWMDzx6B7VbjzpSC2VWhtB6GoB1/wiki/Anasayfa.html

Some people host pages on it, but all they have to share a common domain -- ipfs.io. It means many JavaScript APIs (cookies, localStorage, sessionStorage, IndexedDB, service workers) interfere between pages which is a problem for js-heavy pages.

In the DAT-project community @RangerMauve has built a https gateway for dat protocol with an outstanding idea of insulating DAT-archives from each other by mounting each of them on a subdomain.
The gateway: http://gateway.mauve.moe:3000
Example of a hosted page:
http://8v092weycb1dq0tp1jwag6jdc7ue5069jjzkwbtu3eqvh3nh75wg.gateway.mauve.moe:3000
The repo: https://github.com/RangerMauve/dat-gateway

  1. This subdomain approach solves for problem of interference of pages accessible via https gateway.
  2. With subdomains one may use absolute urls like /assets/css/main.css.
  3. If censor finds forbidden content he may block a subdomain instead of the whole ipfs.io.
  4. If your site hosted on the ipfs gateway, e.g. under whyputinsucks.io.ipns.ipfs.io/index.html, gets censored then you may ask visitors to install ipfs-companion which should unblock your site right after installing extension and ipfs (but I guess the same effect may be reached even without the gateway but with whyputinsucks.io and the extension).

I think subdomains should be implemented in ipfs gateway as well, this offer is the only objective of this document.

RangerMauve commented 6 years ago

To be specific, I added logic that redirects http://domain.com/:key/:path to http://:base32key.domain.com/:path This ensured backwards compatability and made it easier for applications to not have to worry about inserting the subdomain themselves.

With Dat, the key is a full 64 characters representing the public key for the archive. This means that it could not be used as a subdomain as-is. To work around this I used a base32 implementation to shorten the length so it could fit in. Since IPFS uses hashes of public keys, the encoding part won't be necessary and should simplify the implementation.

I detected whether redirection was occuring by detecting whether the subdomain length was the length of a base32 key. Similar logic could be use to detect IPFS hashes in the subdomain.

Before doing the redirection, the gateway resolves any DNS (e.g dat://beakerbrowser.io) entries to the actual dat URL. This has the caveat that if a DNS entry changes which key it points at, it will lose the existing localstorage data, but it simplifies the logic for detecting the subdomain key. I belive the tradeoff will be worth it for IPNS urls using DNS.

kevina commented 6 years ago

Related issue: https://github.com/ipfs/go-ipfs/issues/4143

kevina commented 6 years ago

@ilyaigpetrov @RangerMauve for future comparability please use a valid multibase encoding, see https://github.com/multiformats/multibase.

RangerMauve commented 6 years ago

Aren't most multihash formats going to result in strings smaller than 64 characters, regardless?

kevina commented 6 years ago

@RangerMauve my multihash comment mostly applies when IPFS paths are used.

daviddias commented 5 years ago

Can we move this to http://github.com/ipfs/infrastructure? @eefahy

lidel commented 5 years ago

@diasdavid there is an experimental new feature on the right:

2018-11-04--16-00-01https://blog.github.com/changelog/2018-10-30-issue-transfer/