How to Change the Summary and Payload of a Registered Known Neuron

What is the best way for a registered known neuron to change the information that is displayed on the dashboard? The Summary and the Payload of the original proposal is used to describe the known neuron. Over time, it is natural that the people that control the known neuron will want to make changes to what is presented to the community. This has already happened many times for changing the name of a known neuron. The solution for a name change is to submit a new register known neuron proposal for the same target neuron ID, but to use a different neuron name. That should work just fine for changing the Summary and the Payload description as well. However, there is one example where a proposal for this purpose failed.

Krzysztof Żelazko is a known neuron that was originally approved by the NNS with proposal 85923. However, he intended to change his description with proposal 127703. That proposal passed by Immediate Majority Decision, but it Failed to execute. According to the information provided on the dashboard for that proposal, the Failure Reason was “The name Krzysztof Żelazko already belongs to a Neuron”. The dashboard still displays the information from the original proposal for the Krzysztof Żelazko known neuron.

Another similar example is the GEEKFACTORY known neuron. Krzysztof actually submitted their original Register Known Neuron proposal 127702 without their consent and he named the neuron GeekFactory. The GeekFactory team supported the proposal because they had plans to create their known neuron themselves at the time, but they wanted much more appropriate Summary and Payload information to be provided. Hence, they followed up with proposal 127750. Instead of giving it the name GeekFactory like they do in most of their literature (e.g. their website geekfactory.app), they named the known neuron GEEKFACTORY. I bring this up as an example because there is only a slight nuanced difference between the name GeekFactory and GEEKFACTORY. The NNS accepted this change and the proposal was Executed successfully. Now the dashboard displays the Summary and Payload information that the GeekFactory known neuron team originally intended.

I’m asking because I want to change the Summary and Payload information that is displayed on the dashboard for the CodeGov.org known neuron. It is time for an update, especially since we have applied for the new Grants for Voting Neurons program. However, when I submit a new Register Known Neuron proposal, I want to use the name CodeGov.org as it is currently registered. Will this proposal fail if I use exactly the same name, or has this limitation changed?

@Dylan @Manu @msumme @chepreghy do any of you know who can answer this question?

4 Likes

@wpb I know you are not my fan and do not expect my opinion on this topic, but still (since I was presented as an example) I will share mine.

I think that the NNS proposal should be used only to register a neuron as known. The rest should be editable by its controller. When making changes I would suggest to follow the current solutions for SNS-DAOs. In this case however we can simply use the “Manage Neuron” proposal.
I also don’t see the point of putting a proposal summary on the ICP Dashboard (under known neurons name and description), since it’s just a proposal. It would be enough to show the known neuron name + description (only data included in payload), since you can’t just “edit” that without adding another NNS proposal.

1 Like

Would you mind clarifying a few details about your comment. I’m not sure if you are saying that there is a way to edit already or if you are describing how you think it should work.

I fully agree this is how it should work, but I’m not aware that I can make changes using the Manage Neuron proposal. Is this feature already available? If so, that would be awesome. If not, I would support your idea would hope that DFINITY would consider adding this feature. I think it will become increasingly important as known neurons become more active in NNS governance, especially related to reviews and independent voting on technical topics.

I’m not sure why both the Summary and the Payload is used on the dashboard other than recognizing that information is typically provided by the proposers in both locations and that information is often different. I wouldn’t have a problem with using only one for display on the dashboard, but there would probably need to be good instructions or even code limitations on the use of each parameter when the proposal is submitted. As long as the known neuron controller is able to provide information that they believe is relevant for the ICP community to see about their neuron, and as long as it can be changed over time, then I think using only one out of Summary and Payload can be fine (assuming similar character limits, markdown capability, , etc).

Hey @krzysztofzelazko. I really appreciate that you shared your opinion here and hope we can spark further discussion and improvements on the registration and maintenance process for known neurons.

I actually really appreciate how active you are in NNS governance. There are a couple of things that you often do that I don’t understand and wish you would do differently, but I respect that you are actively involved and are seeking advancement of decentralization of NNS governance.

It’s not clear to me why you submit Register Known Neuron proposals for other organizations without their input or consent. It started with OpenChat and GeekFactory and has continued recently with GoldDAO, NeuronPool, and Open Internet Foundation. In most cases it has worked out ok since the teams behind these known neurons intended to create the register known neuron proposal themselves, but it still seems like those teams should be allowed to create their proposals themselves or at least have input on the naming, summary, and payload that is included in the proposals. I actually have experience submitting these proposals for other known neurons myself. I did it for cycle_dao (which is now Arthur’s Neuron) and the first Motion to register ICDevs.org. However, in those cases I was in discussion with the teams and offered to provide them with support, but they provided the content. That feels like a more appropriate way of handling it. Hence, I have a hard time understanding the logic behind submitting these proposals for teams without first having their permission.

I’ll also admit that I am struggling with wrapping my head around what appears to be your automated voting YES on technical proposals while also applying to receive a grant intended to incentivize active technical reviews for those very same proposal topics. I know a lot of people in the ICP ecosystem have normalized pencil whipping votes and automated voting YES or NO on technical topics and I know it is a lot of work to actually review these proposals and there has previously been no incentive to treat them in any other way. Hence, I think it is perfectly natural to take this automated voting (or pencil whipping) approach when you have the skills. In fact, you have been successful at voting on a handful of proposals over the last year that are missed when DFINITY or Node Providers have initiated proposals on technical topics and then DFINITY failed to actually vote on them. This is rare, but it happens. People who only follow DFINITY miss voting rewards in those situations, but you don’t…so I do understand and appreciate your tactics. However, if ICP Hub Poland is a recipient of the Grants for Voting Neurons, then I hope you will change this automated voting (or pencil whipping) tactic and actually perform a technical review as intended with the grant program. I believe this is what you said you would do in your application, so I have a lot of hope for your success.

I also recognize that it is easy for me to have high expectations when it comes to reviews and independent voting on technical proposals. I saw the need to cultivate a team of developers for this purpose over a year ago and asked for grant funding to pay for this work. I feel like we have been very successful and I’ve been impressed watch the CodeGov team develop this capability, first with IC-OS Version Election, then with System Canister Management. We are now also actively reviewing Subnet Management, Participant Management, and Node Admin to gain experience. There is no doubt in my mind that the only way the community will get actively involved in these reviews is to have incentives that attract talent and skill. It is real work and nobody should be expected to do that work for free. The fact that there have been no incentives for most people in the past means that we can’t really expect for anyone to have put in any significant technical work to arrive at their voting tactics.

Things seem to be changing with this new grant program and I really hope it is successful. Because of the funding, talent and skill will take interest and eventually we should end up with a community of reviewers that people can trust to vote in a decentralized way on technical NNS proposal topics. I want to push everyone who participates as reviewers, and everyone in the NNS community, to start having higher expectations regarding what it means to be a reliable Known Neuron Followee option for technical topics. Hopefully it will not be just about always voting, but will become about always voting in an educated and informed way. This takes a long time do cultivate in the community and I have concerns that the grant program is under funded. We should be supporting all applicants instead of making folks who have expressed an interest in this work compete for limited funds.

I do think you are in a good position to be able to serve the ICP community as a reviewer for Subnet Management, Participant Management, and Node Admin proposal topics since you have been around for such a long time and you know how this governance system works. So please know that I am your fan and I want you to be successful in ways that continue to advance long term improvements of decentralization of the internet computer. I simply don’t agree with some of your past tactics and hope that you will consider changing some of them in the future, especially if you become more properly incentivized for the role.

By the way, it’s not just you. Many others in the ICP ecosystem feel it is acceptable to automate voting on NNS topics. Taggr does this today by voting NO for all proposals other than Governance, SNS & Neurons Fund, IC-OS Version Election, and Network Economics. For those proposals the Taggr vote is cast according to the majority vote on a poll for each proposal. The first draft of the WaterNeuron white paper called for automatic NO voting on all NNS proposals. Fortunately, they actually implemented a tactic where all NNS proposals are replicated in the WTN SNS and the WTN neuron owners get to vote on how the large WTN neurons will vote. Other known neurons such as NeuronPool, ICP Hub Poland, Rakeoff.io seem to be following you (or vice versa) at this time. This culture of accepting automated voting on proposals that actually change the protocol is a dangerous precedent in my opinion. If it continues, then we will become lax in our protection of the protocol and eventually harm can be done. I’m just hoping to heighten awareness of this issue to get people to think about how it affects the protocol long term. It becomes a lot more relevant when there are actual incentives to perform technical reviews, and eventually with changes such as periodic confirmation of neuron followees. Basically, if we want decentralization, then we need to reconsider how and why we vote on technical proposals.

4 Likes

There is no such option for now, but I also agree with you and think it would be good if neurons could decide what their names and descriptions are after registration. In response to your entire post, I only posted a comparison of how all SNS-DAOs set their names and descriptions.
The first proposal “Create SNS” appears with the name and description of the DAO provided. However, then each SNS can freely change its name and description without the consent of the NNS. Naming neurons could potentially work on the same principle. This has not been implemented so far and has never been presented before.

Another interesting and worth considering fact is that many data presented on the ICP Dashboard are only available there and not on the blockchain. As is commonly known, the NNS canister stores only up to 100 latest proposals, after which they are overwritten by newer ones (similar to e.g. surveillance recordings in stores). I would like to someday submit a proposal that increases the proposal history write buffer and storage across multiple NNS subnet canisters.

2 Likes

I agree that this is a very good idea. It has been an issue for us in the past when trying to develop a NNS governance related app. In fact, I struggle all the time with another similar limitation that only stores the last 100 votes on proposals by neurons that are not known neurons. I’d like to see that increased as well. When the new public/private neuron changes are implemented, I hope to see the proposal history of public neurons and known neurons saved indefinitely on the blockchain instead of it only being available on the dashboard.

Would you be interested in starting a new forum thread to present these ideas and seek DFINITY and community feedback? You could present it yourself and I would reply to support. We could also present it together and co-sponsor the request. I’m fine either way. I have no idea if DFINITY would be willing to implement such a request or how long it would take, but I think this would be valuable feedback from the community. I just request that this type of proposal go through the commonly accepted work process of getting posted on the forum under the Governance topic for 1-2 weeks before it hits the NNS. There may be people who have great ideas to improve the proposal and I’d like to give them a chance to comment. You (or we) don’t have to accept every idea, but the exercise of seeking community feedback can often be very helpful for making a proposal stronger and for gauging support. These topics are very relevant to my NNS governance work process and they are pain points, so I would love to see improvements in this area. I suspect the same is true for you, which is why you have been thinking about potential solutions. It would be awesome to see you (or us) push these ideas forward.

1 Like

Hi @wpb, I believe the limitation is still there, but you make a good point and I’ve shared this with the NNS team.

1 Like

Hi Wenzel, thank you for your thoughtful message. I’m definitely interested in starting a new forum thread to present these ideas and seek feedback from DFINITY and the ICP community. Collaborating on this sounds like a great idea, and I’m open to either presenting it myself or co-sponsoring the request with you.

I appreciate the suggestion to follow the accepted work process of posting under the Governance topic for 1-2 weeks before moving forward to the NNS. I agree that community feedback can be incredibly valuable for refining the proposal and gauging support.

However, I’ll be on vacation until next week, so I’ll be able to start working on this and collaborate with you after I return. I’ll reach out to you once I’m back to discuss the details and next steps.

1 Like

Will this proposal fail if I use exactly the same name, or has this limitation changed?

@wpb Without responding to the rest of this thread, I wanted to address this question - yes, the proposal will fail if you use the exact name.

1 Like