Open Governance canister for SNS | Design proposal

Big concern! How will people use this thing without a front-end supplied? Are we supposed to all create our own front-ends to even start experimenting with this? Even a simple front-end would be nice to have

8 Likes

Thanks for bringing up the concern.
Note that this particular project is just about the governance canister.
A frontend is planned but will be done separately.
I am currently following up internally regarding when we think we can have that.

3 Likes

I’m just worried no one (really it will just be much harder) will use this and try it out without a front-end. And the point of pushing things out in pieces is to get community feedback.

1 Like

That is certainly one goal.
Another goal is also to already make the code available to developers who might want to reuse parts of this to build their own governance / DAO etc.

But it is valuable feedback that I happily take back.

4 Likes

Is there any implementation started for this beyond the proposal and this thread that I can take a look at?

1 Like

Hi all, please find the design proposal for the next stage of the SNS project here.
Looking forward to your questions and feedback!

2 Likes

Yes, the implementation is started. It is still very much work in progress, but you can follow along here https://github.com/dfinity/ic/tree/master/rs/sns

2 Likes

I see a pathway to set the SNS canister to call a remote canister to call a function. I’d like something like:

type RemoteCall {
principal: Principal;
function: Text;
data: Blob; };

In motoko this could use the call_raw functionality coming in 0.9.1. This would allow services canisters to mark the SNS canister as the “Admin” and then the sns could vote on functions to call on various canisters(not just the SNS canister which I think is the current set up).

I’m working on the spec for a service right now that is trying to be governance service agnostic and just assign a governance canister. As long as that canister knows how to call the issue_command function you can use the SNS or something simpler. It would be great if the SNS supported this. I know there are issues with getting stuck on a bad behaving canister, but maybe you can not wait for the await? Or maybe it is a parameter to the type?

1 Like

Hi @skilesare ,
it is definitively the plan that the SNS governance can call another method on a canister and that the SNS can then be used to execute arbitrary proposals.
For the very first version, we prioritised that a SNS should be able to upgrade another canister, e.g., the dapp (which is also a call to another canister), upgrade SNS canisters, change the SNS parameters, and have motion proposals. Next we would tackle the generic proposal execution (which I think is what you are asking for), but this might not be ready in the very first version in Q1.

Could you elaborate on what you mean by “the issue_command function”?
If I understand you correctly you would like to have the following functionality: a canister that just has a method and specifies that the SNS governance is allowed to call that method. The SNS governance can then call this method as a result of a proposal. Is this right? If so, I think this is what should be possible with the “generic proposal execution” that we envision.

2 Likes

Sounds right! It will be a good feature to have.

2 Likes

@lara Which token standard will SNS governance tokens use?

4 Likes

It will user the same ledger as the NNS.

1 Like

I think he wanted to know what coin standard will be used for coins that make use of SNS, such as you have ERC20 or BEP20 token standard.

Right. What I meant is that we will use the “standard” that is defined by the current ledger implementation. I don’t think this standard has a name in the sense of ERC20, but it does implicitly define how a token is defined and what APIs are available for a token that uses this ledger implementation. In that sense it defines a standard and we intent to use this one.

Does that make sense?

1 Like

Unfortunately, most of the DEXs I’ve seen (namely InfinitySwap or Sonic) are using DIP20 or some variation of DIP20.

I worry this will present compatibility problems and grievances down the road…

1 Like

Excited to share the SNS timelines (that build on the design discussed in this post) here.

1 Like

This make sense, thank you!

1 Like

Infinityswap has informed us that they will support the native ledger from the beginning.(this may have changed, but I don’t think it has cc: @Maxfinity )

This standard thing has become a real pain in the ass and I wish everyone(including dfinity) would lean into interface namespacing(Proposal to Adopt the Namespaced Interfaces Pattern as a Best Practice for IC Developers) before the problem gets even bigger and we have a real problem on our hands. The groups who have defined the standards and who haven’t properly Namespaced their functions are really holding back the ability for DiFi and service composability to move forward. It isn’t their fault as this is an entirely new space where everyone shares the same function naming universe. It’s a whole new problem and we really need to solve it.

DIP20, EXT, and the NNS ledger all need to have namespace functions added to them so that we can all move forward and retro fit as we move forward. There is nothing keeping anyone from implementing both transfer and transfer_dip20 to their existing canisters. The one case where this becomes an issue is when we have blackholed canisters with no upgrade path. As far as I know, that number is currently small. Once it gets big we won’t be able to go backward.

Origyn will be releasing some stuff in the future and the one thing that has kept it moving is that DIP721 was namespace. As a result, Origyn will support both EXT(which needs namespacing added) and DIP721 as well as the enhancements that are added to the standards stoup. Every single one of the proposed functions will be namespaced.

5 Likes

We will definitely be supporting the ledger, and namespacing is a great idea!

1 Like

So is this did file up-to-date with the SNS ledger standard? Are they one and the same? ic/ledger.did at master · dfinity/ic · GitHub