That is a very reasonable response. To be honest, @dralves is weighing a few things (common in software engineering):
he knows there are unobvious lessons and patterns in current ledger canister that they don’t want to re-learn painfully
he also knows how he would refactor the NNS and the ledger canister given what he has learned the last few months
he also wants to move fast
He and @jwiegley are analyzing their reuse or refactor options by looking at the code.
This reminds me of the classic story of when the iPhone was built. The apple team had two choices for iOS: take the MacBook OS and shrink it, or take the iPod OS and grow it. I believe the winning one was the “grow the iPod OS” (from what I recall, I could be very wrong), but it was a non obvious outcome.
"idea of making ICP tokens locked in NNS neurons liquid
"
Based on my limited understanding, these would be new neurons that are not locked that would be supplying the “liquidity”.
“Why not just let each owner decide which projects they want to invest in themselves?”
Again based on my limited understanding, individual owners of new neurons would decide how much slice of the neuron (i.e. ICP) would go into each project.
@diegop can you please chime in if above assertions are not accurate?
Also the consequences of this to the design of the SNS project are also manifest. I am not sure whether the ledger canister code can be effectively “copied” or a whole redesign/rethink is required.
I wanted to give you feedback that I am not entirely certain myself so I was waiting for David to confirm and I do not want to add to the confusion. But i will get you an answer that I am 100% certain of (i am only 80% certain currently).
Last week Lara mentioned our meeting with community developers, and that we had shifted to a reduced scope in our thinking about what the first iteration of the SNS should look like.
Since that decision, David and I have met a few times on how to approach this redesign: which parts of the NNS do or don’t need to be implemented in the SNS right now; and how we might refactor the code to allow a more flexible approach to things like reward calculation and voting, since some projects may wish to create different incentive structures or different market opportunities within their own communities.
As with any redesign, these are only the first steps, but we do want to get the SNS off the ground quickly, so our initial effort will seek to reuse as much existing NNS functionality as possible, while omitting details that clearly do not apply. But while this is focused more on the low-level details, we’ll be sure to keep you up to date as we discover what makes an SNS truly portable among projects, and how it might differ from the NNS.
Please add a feature to the SNS where a User can set a Commission Rate (%) where if a Vote is Delegated to that user that that user earns a commission on the voting rewards. This is a common practice in delegation for many existing web3 apps and would be useful to have it prebuilt as part of the SNS.
It’s used in Delegated Proof of Stake, but is it used for governance?
I’m not sure we should charge a fee for liquid democracy.
The reason they charge in DPoS is because delegators vote for the delegate; without their support, the delegate might not even be elected as a validator.
Here, having people follow your vote doesn’t directly benefit you in the same way IMO.
Here’s my use case for why I would pay to follow a specific neuron. I sincerely believe that IC will, one day, become the “world computer” on which vast majority of software will be executed.(i.e. I have drunk Dominic’s kool aid).
In that context, because I stay in a specific country, I don’t want run foul of that country’s laws (blasphemy, anti-hate etc). So if someone else is doing the research on all the issues that might be potentially illegal in my country and voting so as not to run foul of the law, then I would follow that neuron. Obviously it takes time and money to do that research and I am willing to pay for it.
If Join Community Fund can get additional rewards, this will incentivize more people to participate in pledging and neurons become newly liquid while increasing governance and decentralization, am I understanding this right?
I wish that, someone from dfinity, who really knows, posts an update on the inner workings. Absent that post, here a brief CONJECTURE based on my interpretation of the medium article.
Then , assuming that the vote passes for the auction, the neuron gets the tokens associated with the Dapp in exchange of ICP staked in proportion to the total ICP staked for the Dapp token auction by all community fund neurons participating in that auction. (if this sounds like a mouthful, it is). This exchange is immediate according to the linked article.
Delegated Proof of Stake is a form of governance (even though typically it is just allocating to block producers). There are several applications where the delegation functionality is used in more advanced ways (e.g. The Graph). I am aware of a project that highly values timely engagement on voting for DAO decisions. For this project, once a threshold of votes are met the proposal is finalized.
There is no requirement to charge a fee.
Also, @lastmjs called out that some type of reward might be a useful strategy for increasing decentralization of active voters. By rewarding voters for their time, there is more of a reason for individuals/team to review every proposal in a timely manner and be vocal about why a decision is good or bad. It is not a silver bullet, but it could be combined with logarithmic returns to encourage delegators to either be active or find under supported active voters.
Building it as a functionality, expands the out of the box uses of the SNS which will speed up development on the IC.
What if there were a decentralized Git commit strategy. Shouldn’t informed voters who thoroughly reviewed the code be rewarded? What if they cannot afford to put up a large stake? Is their contribution less valuable?
Interesting point about decentralized Git commits.
That’s true, not everyone has the time or expertise to vote on code changes, and it wouldn’t be great from a democracy POV to reward only programmers and engineers (or worse, non-technical people voting randomly just to collect rewards).
I’m just not sure a commission rate is the right way to delegate. For example, what if I don’t want to share 2% of my voting rewards to people who delegate their vote to me? It’s not like I get anything out of it (besides having a bigger say over the end result).
It works in the real world, e.g. Congress, because if you delegate your vote to me (i.e. elect me to Congress), then I get a paying job with benefits. I think that incentive structure is currently missing in IC governance. Needs more work I think.
Hi all,
happy to provide you with a new end-of-the-week update.
We have spent some time thinking about Open Governance / SNS and how this fits into the bigger context of providing the community with tools for tokenisation, decentralisation, access to funding etc.
Therefore, rather than going into SNS details, I want to share our current view of how these things could fit together and in what stages we could tackle them:
Ledger canister: A ledger canister, including Rosetta-integration. Currently we think the design might be similar to the NNS ledger, but we want to improve it a bit with the lessons that we already learned during the last months. This effort is lead by @bogwar
Open Governance: Canister(s) implementing an open governance system. As with the ledger, rather than just reusing the NNS governance canister, we are considering alternative designs that omit some of the NNS governance canister’s complexity due to NNS specifics. We also think about how we can make the governance modular so that it is easier for developers to change / (re-) use just some parts.
Service Nervous System (SNS): An out of the box version of the SNS. The current idea is that, in addition to the above ledger and governance canister, further functionality would be provided such as automatic upgrades of the SNS canisters by the NNS and integrated means for a decentralised initial token distribution (e.g., the “auction” that was included in the SNS community conversation).
Community funds / community neurons: A mechanism to invest the staked ICP tokens from the NNS neurons in SNS projects and thereby enable even more funding for SNS projects.
We are currently focusing on detailing the designs for 1. and 2. and plan to have concrete design proposals for them roughly in the next 2 weeks.
As you may be aware the community fund button been introduced on NNS dapp IN PRODUCTION AS AN IRREVERSIBLE CHANGE.
The community has been patient in waiting for an answer here(Community fund on nns - #16 by mparikh) on what exactly is this functionality (at the detailed level)
Would it be fair to say that , on (4) (community funds/community neurons), depends ( both what it is supposed to do at a detailed level and how to do what it is supposed to do) on 1, 2 & 3?
If so , we will need to wait for weeks to figure this out?
Will there be any chances to revert the community fund participation for those who may have clicked accidentally on the button on early stages?
Also, if this is an irreversible decision, there should be a more complex way to confirm the participation on this fund, because this means that the neuron is lost forever. Some way of doing this, could be: before the final confirmation click, for the button to be active, the user should write the word confirm on a text field. I’m saying this because there are many scenarios that things could go wrong:
the user could leave the wallet open for some minutes, where a child could mess with it and activate the “community fund” function;
touching the button while being unaware, in the pocket, while driving, while speaking to someone, while dozing away etc.
I think this is the mos critical button in the NNS app, at therefore it should have a more complex activating mechanism.
If someone may say that how could something like this happen, I assure you that it could happen, as it did to me, while being tired I tried to merge maturity and while dozing away ended up touching the “community fund” button, and my biggest neuron went to the community fund.
Hi there, thank you for your patience!
While the implementation and realisation of the community neurons depend on the SNS work, we can work on the design of the two projects simultaneously. In fact, we want to do this simultaneously to ensure that in the end all the APIs fit together. As soon as we have a better understanding, we will share our proposed design with the community as usual.
