cosmos-sdk: Governance API: The Proposal JSON response does not include who submitted the proposal
Summary of Bug
The API response for calling proposal does not include who submitted the proposal. That would be useful information to know.
Steps to Reproduce
- Create proposal.
- Call API:
cosmos-sdk HEAD % curl -k https://0.0.0.0:1317/gov/proposals/4
{
"type": "gov/TextProposal",
"value": {
"proposal_id": "4",
"title": "Stupid Test Proposal",
"description": "This is a description of my proposal to move to the Yukon and disappear.",
"proposal_type": "Text",
"proposal_status": "VotingPeriod",
"tally_result": {
"yes": "0.0000000000",
"abstain": "0.0000000000",
"no": "0.0000000000",
"no_with_veto": "0.0000000000"
},
"submit_time": "2018-12-06T02:53:14.9623162Z",
"deposit_end_time": "2018-12-08T02:53:14.9623162Z",
"total_deposit": [
{
"denom": "STAKE",
"amount": "10"
},
{
"denom": "node0Token",
"amount": "500"
}
],
"voting_start_time": "2018-12-06T02:53:14.9623162Z",
"voting_end_time": "2018-12-08T02:53:14.9623162Z"
}
}%
For Admin Use
- Not duplicate issue
- Appropriate labels applied
- Appropriate contributors tagged
- Contributor assigned/self-assigned
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 1
- Comments: 21 (21 by maintainers)
@cwgoes A lot of users want to know who has submitted a given proposal. You’re not protecting anything by not displaying it, it’s just bad UX and pointless obfuscation.
@sunnya97 It comes down to what is the point of LCD and its API? This is basic information, that does not cost a lot to store, or at the very least if it’s not stored LCD should take care of finding and assembling the information for the proper API response. Several times now you’ve given me the answer of ‘just query the TX’ without acknowledging that LCD is supposed to reduce those kinds of scenarios, or even in the case of the deposit API returning nil after voting period has closed HOW to perform such a query when the block height isn’t even returned as part of the response.
If this is not the role that LCD is supposed to perform then I think the team needs to have a clear statement about what IS the purpose of LCD, because right now a lot of the APIs seem to give half responses that can’t be semantically linked together as one would expect with any proper API.
Not quite, because the deposits in state are just put lexigraphically by depositer address, not by time. If you really wanted to know who submitted the proposal, you could see who submitted the tx by doing a tx query rather than a state query.
That’s a fair point. The reason I made the decision at the SDK level to not include the proposer is that it isn’t used anywhere in the state machine logic, so it didn’t make sense to store it in state, as that is additional storage data that isn’t necessary. Do you think it’s really necessary enough to burden all nodes with storing that data, or would it be sufficient for UIs that want to show the proposer to get it through a tx query.
Tbh, I prefer not to store it in state, but don’t care too strongly about this.
@jaekwon @cwgoes @gamarin2 what are your thoughts?
Ok, I’m going to implement this endpoint using a tx query under the hood.
The choice of what information to show in a UI definitely influences what users will do with the interface, and in particular which information they will consider in voting on proposals. Personally, I think that we want to minimize the importance of the identity of the proposer, and maximize the importance of the content of the proposal. Other UI implementers may make different decisions (and the Voyager team may well disagree with me!).
On the SDK side, since it’s certainly possible to query the transaction submitting the proposal and return the proposer address, I agree that not implementing an endpoint exposing it would amount to “pointless obfuscation” - so let’s do that.
Well, we’d have to modify the proposal structs I imagine. At that point we might as well keep it in state…
I would be more than happy to implement that API endpoint (
/proposals/{id}/proposer)!Would like further thoughts if this is OK from @fedekunze, @faboweb or @jackzampolin.
@faboweb Totally understand things are chaotic right now. I just feel it’s important to challenge these tacit decisions before things become concrete and we end up paying the cost of needing an Infura to do basic things 😉
@sunnya97 sorry, misunderstanding. We’d have to modify the proposal structs in order to get the existing endpoint to display this data. I’m suggesting we don’t do that 😉
@alexanderbez Lets do that, but ideally it just gets added to the original endpoint. If that requires extensive mods to the exiting endpoint then I don’t have an issue exposing it like you mention there.
So what is the exact consensus on the actionable item(s) here? PR #3091 fixes/adds some tags, namely you can get the tx where the proposal was created via
'action=proposal-created&proposal-id=N'.Are we looking to implement another endpoint here?
@johnmcdowall love your statement! I think we need a proper description of purpose for the LCD. I will take the feedback and bring it up with the maintaining teams. I agree with all of your points, but to be fair: The teams are working hard and the LCD is just not the very top priority right now.
i’m not sure i understand why we need to make this kind of decision at the SDK level. both the proposal and it’s associated data are important and may be relevant to some users in some use cases.
some UIs might agree with you and make the choice not expose the proposers information, while others may decide for their use case it would be best to expose this information.
strongly agree with @johnmcdowall here.
also on his desire to move to the Yukon.