Feature request: ability to customize service worker loading page for custom domains via boundary nodes

I’ve seen some progress on the feature described below:

I’m currently using Firebase and love to be able to remove that.

However, the Firebase approach allows me to customize the service worker page to match the rest of my site (see codebase.org)

Other people value this too:

https://share.taggr.link/thread/10217

no custom service worker means no custom theming for the load screen which I like a lot

If it was possibly to do the same thing without Firebase then I’d definitely do that.

1 Like

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.

Did you have any ideas for how it would work?

Hi Raymond

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.

1 Like

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.

Stop right there, I’m in :wink:

1 Like