Publish to webui.ipfs.io

[olizilla]

Let's publish the revamp'd Web UI to it's own domain! It could follow the deployment pattern of our other websites; merging to master can trigger a CI built, test and publish of the update. Continuous Deployment! Imagine it! We ned to add more e2e tests to bolster our confidence, but in this'd be a huge improvement for the velocity of the project. No more waiting n months for a release! If a user navigates to webui.ipfs.io without having a local IPFS deamon running we can catch that an encourage them to go install it, and also offer them the option to "try it now" via an embedded js-ipfs version!

For IPFS sites we publish a dns txt record for the domain that points the latest CID for the last successful build and test cycle, so we'd only be deploying tested code, and have a stable address for "i want the latest webui".

We can update go-ipfs and js-ipfs to redirect to https://webui.ipfs.io when users go to :5001/webui. Right now we have to PR go-ipfs with a new CID to redirect to, but the proposal is we change that to redirect to a domain to simplify deployment. We need to enable CORS headers so that js-ipfs-api client can request resources from a node on localhost (or any remote address for that matter), but we could do that by default for webui.ipfs.io which'd be neat.

Companion would detect the dnslink record and serve the webui from IPFS where available. That'd redirect the url to <gateway>/ipfs/<latest-cid-for-webui>. If you are using a custom gateway then you'd have to sort out CORS for that or overlaying the /api routes on the gateway origin, like we do on the main gateway, and that is the same as it is now.

What am I missing? Is there any reason not to do this?

[hacdias]

I personally like the idea and that was actually what I thought we were going to do from the beginning. webui.ipfs.io to rule them all! No more CIDs or hardcoded versions 😄

[lidel]

:+1: for providing https://webui.ipfs.io as an additional "try it!" option. We should be very careful about changing existing conventions tho. Some notes about go-ipfs below.

[..] redirect to https://webui.ipfs.io when users go to :5001/webui. Right now we have to PR go-ipfs with a new CID to redirect to, but the proposal is we change that to redirect to a domain to simplify deployment.

I would not go that far. While I understand the appeal of replacing hardcoded hash with a value read from dnslink for webui.ipfs.io, we need to be aware that DNS can be blocked/censored. Remember ipfs.io was blocked in Spain last year. I am thinking about including assets behind hardcoded WebUI CID as a part of preloaded data shipped with every go-ipfs, so it works in offline/closed/censored networks.

Having that covered in go-ipfs we could load the hardcoded version first, and then do dnslink resolv and load that if new version is available + store new hash in localStorage so it is automatically loaded next time.

Note that such update mechanism requires trust in dnslink which is pretty weak. On the other hand we don't sign releases at https://dist.ipfs.io :upside_down_face: so it is not like we decrease security level.. Jokes aside, we should think about securing releases and updates, maybe along with dist.ipfs.io, and if we start doing that, the same key could be used for signing webui releases.

[olizilla]

@lidel good point. So the plan is to use https://webui.ipfs.io for continuous deployment of the master branch. I'll tag and PR release CIDs to go-ips and js-ipfs after a few days of testing.

Of note, https://webui.ipfs.io when live with #806 🚢

[hacdias]

We already publish to webui.ipfs.io!