Open ilyaigpetrov opened 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.
Related issue: https://github.com/ipfs/go-ipfs/issues/4143
@ilyaigpetrov @RangerMauve for future comparability please use a valid multibase encoding, see https://github.com/multiformats/multibase.
Aren't most multihash formats going to result in strings smaller than 64 characters, regardless?
@RangerMauve my multihash comment mostly applies when IPFS paths are used.
Can we move this to http://github.com/ipfs/infrastructure? @eefahy
@diasdavid there is an experimental new feature on the right:
– https://blog.github.com/changelog/2018-10-30-issue-transfer/
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.htmlSome 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
/assets/css/main.css
.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 withwhyputinsucks.io
and the extension).I think subdomains should be implemented in ipfs gateway as well, this offer is the only objective of this document.