MetaMask to start using *.ipfs.dweb.link for ENS-IPFS sites?
rekmarks opened this issue · comments
Hello everyone, I have a support question.
Description
MetaMask, an Ethereum wallet/dapp browser, plans to start resolving ENS-IPFS/EthDNS sites using the *.ipfs.dweb.link gateway, as described in this PR. We're trying to get a hold of the proprietors of the gateway to ensure that it can handle the increased traffic.
Context
MetaMask has roughly 90,000 weekly active users. We anticipate that a small number of these users - at most in the low 1000s, although the number can balloon in the future - may visit an EthDNS website at some point during the week.
Proposal
We want to route our EthDNS traffic through the ipfs.dweb.link gateway. Is this OK?
Usually we suggest running your own gateway, as .ipfs.dweb.link is provided on best-effort basis, and we may throttle when load becomes too expensive.
@rekmarks FYSA ENS project runs a dedicated gateway at <domain>.eth.link, which provides not only origin isolation you seek, but also keeps the human-readable ENS name in URL. ENS project should be able to share setup/configs for this too, if you choose to run your own.
Your users will have better experience if you route .eth domains there, and use raw CID gateway such as <cid>.ipfs.dweb.link only for non-.eth domains.
Including people of interest, you probably want to have a chat with Chris on ENS end:
cc @chris-remus (PM @ensdomains) @parkan (IPFS collabs) @olizilla (IPFS gateway) @autonome (IPFS in web browsers)
@lidel thank you very much for that answer. We'll plan to use <domain>.eth.link at least in the short term. We'd love to talk to @chris-remus or whoever is appropriate at @ensdomains.
confirming that this is probably the best option in the near term
in the longer term, I would like to gently encourage these users to consider installing companion and/or running a local node
Something I just realized:
MetaMask is using gateway.ipfs.io in production right now: lib/ens-ipfs/setup.js#L48 :P
Having that in mind, I believe it is okay for you to go ahead with MetaMask/metamask-extension#7362 and switch those preexisting code paths to {cid}.ipfs.dweb.link. AFAIK both gateways use the same hosting, so there won't be any difference performance-wise for anyone involved so far, but MetaMask users will get Origin-based isolation mitigating security issues described in MetaMask/metamask-extension#5724 before you figure out alternative hosting or how to use js-ipfs and run this in truly distributed fashion.
I hope this sounds ok to everyone involved.
(cc @olizilla @parkan @autonome for visibility)
@danfinlay and I chatted about swapping over to using the infura gateway so they can send increased load without running into any throttling - not sure if Infura supports subdomain gateway yet?
I don't think Infura has it yet. Cloudflare does: https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.cf-ipfs.com/wiki/
FYSA setting up a subdomain gateway is more difficult than it should, namely go-ipfs should support CID in Host header out of the box. We are tracking improvements on our end in ipfs/kubo#6498
@lidel we merged MetaMask/metamask-extension#7362 per your previous message. We allow users to specify different CID gateways, but ipfs.dweb.link is the default. Please let us know if anything changes on your end regarding this.
cc: @danfinlay
Edit: I'm fine with closing this issue, but feel free to leave it open for future communications.
@egalano can you chime in on
- subdomain gateway capability today/using infura gateway here
- pathway for virtual/delegated node in the future
as per call?
I think this ticket can be closed, as it has gone quiet. Please re-open if I'm mistaken.