Hey Paul - The points you raise are valid. There are indeed advantages to being your own gateway.
We’ve discussed making the loading page customizable - one idea was to load parameters from the canister and template them into the loading page but it’s not something that we’ve prioritized yet.
I think providing a simple way to customize parts of the page might be beneficial for some apps and developers.
I also think that people who currently have the ability to fully customize the look of the page would appreciate being able to do the same.
For that I imagine developers could make an index.html file and linked assets available in an asset canister. Using the same asset canister as the front end canister that’s being loaded would probably be intuitive and convenient.
For reference, here’s what I did for Firebase. Most of this is overhead. Some of the HTML and images are also redundant.
Would that work? Security wise doesn’t it means then that the BN would have first to make an update or certificed call+check to the asset canister to fetch the content which implies that the delivery time of the dapps gonna be slowed down? Something we probably want to avoid both for UX and SEO reason.
Spontaneous thought, maybe I am missing a point of this idea.
@peterparker that’s correct. The service worker is responsible for making sure that assets from an asset canister are certified correctly, so if the page that loads the service worker is now being loaded from an asset canister that responsibility would need to move to the boundary node for that page, which is not ideal.
I think the more ideal approach here will be to find a way to get rid of the service worker and allow developers to work as they would in Web2 and not have to worry about a service worker loading page at all.