Updated - SNS wasm vote: recommended -follow DFINITY

I’m going to ask a few questions that may be very stupid and/or obvious, so please forgive the ignorance where it occurs.

This is a complex system. Please feel free to ask questions.

Let me try to clarify what I can:

  1. Can I install these wasms myself without an SNS interaction to a non-sns sub net? I would consider this “application mode.”

Yes, you can download the code, build the wasm and install them on an application subnet or you can download the already built wasms and install them on an application subnet.
The difference of an SNS on the SNS subnet and what you call “application mode” would be that the SNSs on the SNS subnet can only upgrade to wasms that are in SNS-W (although the time of upgrade is up to SNS vote). An SNS in “application mode” could potentially diverge from this.
I have to admit: This is the design and I have to double check if the “possibility to diverge” is currently behind a feature flag or already enabled if you install an SNS canisters right now. We focused a bit more on the other path, but this is the plan.

  1. If I do the above, I’d assume that the wasm hashes of the canisters in my controlled canister would be the same and just as easy to verify as a subnet ID.

It is correct that you could verify the wasm hashes.
Whether this is just as easy I think depends on the perspective, on who you trust, and on the technical knowledge of a user.

  • For an SNS on the SNS subnet, if I verify once that the SNS is on the SNS subnet and if I trust the NNS community to make good choices, then I don’t need to verify this every time I interact with the SNS canisters. You could claim something similar for an SNS in “application mode”, but the difference is that you need to trust the SNS community (as they could upgrade to any random SNS ledger e.g.).
  • If a frontend (for example the NNS frontend dapp) has the convention that they only display SNSs on the SNS subnet and if I am a user who trusts this frontend but am not able/ willing to use CLI tools, then this could be considered to be easier.
    Of course a FE could have another convention of what is a “good/ vetted SNS”, but letting the NNS community verify the code seemed like a good first step.
  1. Is there anything in the SNS code that would require a different subnet with different rules(like cycle limits).

You mean different compared to an application subnet? No there is not. The SNS subnet is really just an application subnet with the exception that there is only one way to deploy canisters to it (which is over the SNS-W).

  1. Can I self compile these wasms?

Yes this should be possible

  1. Do I have to ask the NNS if I can have an instance of these in the SNS subnet or can anyone deploy them if they pay the cycles.
  • In the long-term design: Everyone can install SNS canisters on the SNS subnet as long as they pay enough cycles, but the governance will be in a “pre-genesis” mode as it might not yet be decentralised. An NNS proposal is then used to start the SNS sale, which will lead to SNS genesis if successful.
    This is just one way to decentralise and alternatives might be added in the future (see this original forum post).

  • Right now and in the coming weeks: Right now it is not (yet) true that anyone can install the SNS canisters. This is currently guarded by a whitelist on SNS-W that can however be changed via NNS proposal in a decentralised way.

    • The main reason for this is that we want to launch an experimental SNS in production to show users how SNSs will work and to get some more confidence that all works smoothly in production before launching an SNS for any major project. At this stage we do not recommend that real projects release SNSs.
    • If the NNS community agrees, we could then leave the whitelist there for the first SNSs as a means to control of how quickly SNSs are deployed (and e.g., monitor that all still works smoothly with multiple SNSs). Eventually, the plan would be to remove the whitelist and it would be as stated in “long-term design” above.
  1. If the NNS won’t approve my request will there be a clear pathway to deploying them in my own on day 0 to a non-NNS subnet.

You mean whether it is then possible to deploy the SNS canisters on another subnet? It should be, but to be honest we focused our efforts, including testing and documentation to the path for SNSs on the SNS subnet in the last weeks as we thought focusing on one path first is more efficient.

When this change to NNS is suggested, what kind of proposal will it be? Any chance we could have a “temp check” on this. /:duck: I can’t wait to see the amazing work you all have done on this, but, maybe at beta.sns.app at first?

I think this will just be an upgrade of the NNS frontend dapp to enable this functionality.
As I said I am not the expert here and will leave the answer to this for others.