The same assets load at times… also the smaller assets load always from the error messages
For example the 40mb one was loading fine last night and might load again later
The same assets load at times… also the smaller assets load always from the error messages
For example the 40mb one was loading fine last night and might load again later
40MB is consistently failing for me
i can ascertain that the asset loads at times…
this is what is confusing me.
any idea how I can work around this limitation?
the same asset, if I change it to raw.ic0.app it does load…
how can I make the front end call the raw URL instead?
What do you think?
https://rbsr6-fyaaa-aaaai-aarwa-cai.ic0.app/resources/guard/castle_guard_01.fbx does not load
https://rbsr6-fyaaa-aaaai-aarwa-cai.raw.ic0.app/resources/guard/castle_guard_01.fbx does indeed load
the overall workflow is.
For raw URL xxxx.raw.ic0.app
the flow bypasses the service worker so there is NO content signature verification.
For the non-raw URL xxxx.ic0.app
this call goes through the service worker that performs the verification after downloading the complete asset. the service worker keeps aside memory to download the asset, if this memory is not enough to store the complete asset (as in your case) the verification bails out.
Do you really need the asset verification, can this requirement be relaxed ? If so then, a workaround would be to fetch via the raw endpoint. Of course, this is a temporary workaround. Once streaming is implemented you can switch back to using the service worker (aka non-raw endpoint)
Thanks a lot for the detailed overview.
However I am not sure how to fetch from the raw.ic0.app endpoint in the code
One way I can think of is to hardcore the raw ic0 link where I am loading the asset, however I’m not sure if it’s the best idea.
I have also seen apps where all the assets are loaded (with a loading screen) which I would like to implement.
If you can point me to some code where this is being done, that would be super helpful.
Thanks for your help once again
One way I can think of is to hardcode the raw ic0 link where I am loading the asset, however, I’m not sure if it’s the best idea.
Yes, that’s what I am suggesting, i.e. you change the fetch URL to xxx.raw.ic0.app.
It’s not a solution, but avoids the worst-case scenario where you are not able to upload/download large assets
I havent got around to trying this yet… Will update here once i try it
When a canister sets
certified_data
, does it request a canister signature? Is this how the internet identity canister signs the delegation to the session key? tagging @bjoern aswell
Yes. See the system API in the interface specification. The system call ic0.certified_data_set
sets a 32-byte value (which is usually the root of a Merke tree) and the ic0.data_certificate_*
methods are used to retrieve the subnet signature on that value. This is exactly how canister signatures are specified, and this is how II (or any other canister) can sign delegations.
seems to be working fine when I use the xyz.raw.ic0.app instead of xyz.ic0.app - the assets are now loading from the raw url, and that seems to be doing the trick so far!
Thanks for all your suggestions