Can I ask why SNS projects are encouraged to utilise the standard asset canister for hosting the frontend assets?
Why are SNSs not encourage to bundle their frontend assets into canister WASM so that the SNS DAO can verify the build before deploying frontend changes?
The verification workflow for the standard asset canister (which doesn’t bundle assets in the WASM) is unnecessarily complicated. I don’t think I’ve ever seen an example of this used for SNS communities to verify frontend changes.
Do we have examples of any such proposals that can be pointed to? Is it supported by the SNS framework?
In any case, the workflow doesn’t seem very decentralised. It necessitates privileges principals.
When configuring an asset canister, a set of permissions that contains a whitelist of principals must be created. This whitelist details who is allowed to submit changes that update assets in the asset canister. Principals that are allowed to submit changes are given the Prepare permission.
The community are only able to vote on, but not propose, changes.
Once a principal with Prepare permissions submits changes to the asset canister, these changes are set in a ‘locked’ state. Then, anyone can submit a proposal that proposes the ‘locked’ changes be applied; there is no permission necessary to submit this proposal.
Why are we instead not concentrating on frontends that can be verified as simply as reproducing the build, just like any other canister (because the assets are bundled into build instead of uploaded afterwards)?
@aterga are you able to shed any light on these questions?
WASMs are notoriously limited in max size. Currently, even with chunked uploads (do SNSes even support that?) you cannot install WASMs larger than 11MB.
As someone who helped with the design and did a fair amount of the implementation I agree it is not very convenient. However, if we agree that many frontends cannot be bundled into the WASM, then I doubt we can get a flow that is substantially better. (Currently you need the live state plus the proposed one to verify, but it would be possible to make it verifiable such that you only need the proposed one)
Here’s the latest frontend update from OpenChat: Proposal 2144. You can see that the commit_proposed_batch gets called and that the rendered payload contains evidence as required by the process.
While you are right that it requires privileged principals, I would say decentralization is not as bad as “the community can only vote”. The list of privileged principals can be updated with an upgrade proposal (see args here), which can be proposed by anyone, so anyone can ask for permission to propose a diff.
The reason we (or I?) introduced that access control is that principals with this permission are allowed to upload arbitrary data. Canisters have limited memory (especially since the asset canister still doesn’t use stable memory much…) and can relatively easily be bricked or close to bricked if someone maliciously uploads too much garbage.
Back when we discussed how to update assets via proposal I also suggested being able to point at an existing asset canister, and the live canister would pull in the new state. This would have had the advantage of not requiring access control, but my suggestion was considered too brittle to maintain. I still wish we went with that proposal anyways.
Thanks @Vivienne, perhaps OpenChat is one of the few SNSs that is using this correctly (or I just happen to have come across SNS that aren’t using this properly).
Can I ask what steps a user would go through to validate the payload?
I agree, this sounds much nicer. It’s a shame this wasn’t the route that was taken.