feat: support for versioning Dither protocol implementations #494
Conversation
✅ Deploy Preview for dither-staging ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
jeronimoalbi
changed the title
jeronimoalbi
changed the title
|
cc @Kouteki |
luciorubeens
left a comment
luciorubeens
left a comment
There was a problem hiding this comment.
The idea of versioning based on the address looks great, but there are also some considerations on the front-end side. Since we build the transaction to be sent to the community wallet, we would also need to update it in this case, right?
https://github.com/allinbits/dither.chat/blob/main/packages/frontend-main/.env.example#L15
I’m also thinking that this process of "generating" a new address every time we change something in the protocol is not automated, so it could slow down development.
It would also be great to document this somewhere in the docs/ folder.
Yes
You are right, a Also, having a CI workflow that detects protocol updates and fails if the addresses are not updated would be a great addition, if possible. |
Dither protocol is open, it uses a memo field and a send message, so anyone can "pollute" Dither namespace sending multiple transactions using different non existent function names, which might be expected to be supported in the future. Apart from polluting the namespace they could also generate issues when replaying historical transactions to restore the data.
Versioning dither protocol implementation makes the protocol safer.
Versions are defined by the address of the destination account used in the send messages.
New versions must be created when the protocol changes because new functions are added, or because existing function parameters change. A new version means that the destination account for the send transactions must be changed to a different one.