Some time ago, I was searching for something in older proposals and found one where the link to the full proposal was not working.
I want to open discussion about the fact that many (if not most) proposals submitted to open gov are usually very brief and have “full proposal” links in the text. Most of the time, these links are open Google Docs that can be modified and changed without voters’ knowledge.
Imagine someone posting a proposal and then changing stuff in it while it’s open for voting or after it was approved. There is no easy way to verify whether the external document was altered. In some cases, the links can stop working, or the owner can limit their visibility or delete them, making it harder to check them over time.
Since the treasury is distributing a lot of money, it would make sense to have the option to review older proposals with certainty that the document you are reading is the same document that was submitted on the first day of posting the proposal. For the sake of transparency, that’s how it should work. What we like to say - Less trust, more truth?
I’m curious about the opinions of others; how can this be solved? Do you think this is an issue that needs to be tackled? What can be done?
Maybe a common agreement could work, like submitting formats that cannot be changed. Maybe Subsquare or Polkassembly can implement some solutions. Or perhaps this can be a task for UX bounty? Anyway, I’m curious about your opinions.
The fellowship approves its rank retention proposals through a vote on a hash.
The same process could be used here; additionally to the spending call it can remark the hash of the proposal.
It would also be possible to store the proposal in the preimages pallet or something along those lines.
Relying on UI front ends is possibly problematic if they are recipients of grants themselves but would probably be easier short-term. Also they should eventually enforce the convention that OpenGov settles on.
We could even create a new treasury spending call that takes a memo hash that is mandatory.
The referenda pallet already supports to set metadata of a referendum. This could be used to store the hash of the document. It also sends an event to follow any changes.
Yeah, it definitely needs tackled. It’s hardly acceptable in a ‘trustless’ ecosystem for proposers to have the one main document as to their accountability under their own control to be altered or removed at will.
IPFS uses content based addressing - which means that a given address is a hash and the content it links to cannot be changed.
You can, of course, store another version under a different hash.
Pinning to IPFS is not as obvious as making a Google doc, but can (if my info is still valid) be done for free by signing up to a service like Pinata - so not much more overhead for the user than signing up to ‘Google’, whoever that is.
Pinning through one free provider is reasonably reliable but doesn’t actually guarantee that the content will stay up for ever, though it would be not technically complex or expensive for treasury to fund auto-pinning of every proposal text.
Also, Crust network is a gateway to IPFS so normalising IPFS for proposals would leave us the option in future to build tools, working on a Polkadot parachian to easily integrate into subsquare, polkassembly, etc.
I seem to have got a rep for bashing web2 services for (for example) the fact that they ultimately control the content you store on them and, yeah, we should get away from that.
But seems to me the far more important problem in this case is that on Google/ Gdrive (but in reality almost anywhere else too), that proposer has the power to alter, hide or permission access to the content - the ability to erase or manipulate evidence is a big plus for dishonest, grifty or spammy proposers.
I agree we should definitely enforce the hash of the actual proposal to be in the metadata of the referendum. We should put it in https://opengov.watch (@alice_und_bob) and start making noise about it
I also chatted with Nino from UX Bounty, and he said they are already working on something. I shared this forum post with him, maybe the comments above will somehow help them decide what to do next. Thanks to everyone who shared their opinion, I hope this issue will be tackled in the near future.
The problem is the metadata hash isn’t worth much when documents just disappear. You need to actually store the document somewhere.
Also most of the time the proposal is a Google doc, not a persisted file.
If you want to enforce it, there needs to be a persistent storage where files are submitted to and only then you can submit the ref on-chain. E.g. have a storage chain and require a valid pointer to a file on the storage chain
