Does anyone know what this mysterious neuron is about? (who owns it, and why it’s the only neuron represented in ballot data returned from list_proposals on the NNS governance canister, for the last 19 proposals) → 14315117116521128082
Ballot data is empty beyond the last 19 proposals.
@msumme is this something you’re able to shed any light on? What is ballots supposed to contain?
The ballots include the ones the caller has access to. I believe this neuron added the anonymous principal as its hotkey and the dashboard uses the anonymous principal for all the calls.
So you’re saying it IS a conspiracy?
Good to know, that’s useful. Thanks @jasonzhu
I’ve just spotted include_ballots_by_caller. Looks like it’s always set to true, but I’m guessing this is there in case in the future there’s a need to drop ballot data from the results (in which case the caller will be made aware via this field)? If I’ve understood this correctly, would you be able to provide reasons this might happen (and how a caller might be able to avoid ballot data being dropped in the response)?
I also came across this comment which suggests calling get_proposal in the event of dropped ballot data in the response, which makes sense (just wondering how best to avoid the data being dropped in the list_proposals response in the first place, if possible).
Good questions. Before I get into either of them, I just wanted to point out that both are related to SNS Governance, while the this thread started with NNS Governance. It doesn’t invalidate your questions though.
I’ve just spotted include_ballots_by_caller. Looks like it’s always set to true, but I’m guessing this is there in case in the future there’s a need to drop ballot data from the results (in which case the caller will be made aware via this field)? If I’ve understood this correctly, would you be able to provide reasons this might happen (and how a caller might be able to avoid ballot data being dropped in the response)?
Perhaps the comments should be improved, but there is no plan to NOT include the ballots by caller. In fact, it’s quite the opposite - in the past, the ballots of caller were not included at all. However, if we simply include the ballots by caller, when the ballots in a particular response are indeed empty, the client has no way of telling whether the caller indeed has no ballots, or simply the SNS Governance was on an older version. If we include this new field, then the client can use it to distinguish those 2 cases.
This reasoning is kind of unique to SNS, as clients often need to call different SNSes on different versions.
Now that you mention it, this field should probably be cleaned up, since all SNSes have progressed to a version where ballots by callers are included.
I also came across this comment which suggests calling
get_proposalin the event of dropped ballot data in the response, which makes sense (just wondering how best to avoid the data being dropped in thelist_proposalsresponse in the first place, if possible).
First, ballots by callers are always returned. I think the comment is a bit outdated.
The remaining ballots and some “large payloads” are indeed “dropped”. The main reason is to avoid exceeding the message size limit when there are either multiple proposals with large payloads, or the SNS has a lot of voting neurons (therefore ballots). I guess the only sane alternative is to return fewer proposals when the response is full (as opposed to trapping when response is too large) while returning a continuation token. On the other hand, delegating to get_proposal seems a much simpler option, especially considering the full ballots and large payloads are typically less useful.
Perfect, thanks @jasonzhu for the detailed answer 
