MetaMask to start using *.ipfs.dweb.link for ENS-IPFS sites? about infra HOT 9 CLOSED

@rekmarks @danfinlay

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)

from infra.

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)

from infra.

@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.

from infra.

@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.

from infra.

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

from infra.

@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?

from infra.

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

from infra.

@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?

from infra.

I think this ticket can be closed, as it has gone quiet. Please re-open if I'm mistaken.

from infra.