Wetonomy Dev Diary — voting and group management

Hey again! It is about time for another biweekly Wetonomy/StrongForce update. You can check the previous one here.

What did we do?

Over the last two weeks, we progressed steadily towards getting a working demo of the whole system. With that being mostly done, we are currently polishing things up, and fixing all the corners we’ve cut while making the first demo.

Meanwhile, we are thinking about a bigger goal-implementing the processes here at Comrade Cooperative as a Wetonomy-powered blockchain. The first step towards that would be implementing some kind of voting as well as more advanced group management (we can already make groups using Access Control Lists, but they are a bit clunky and hard to use).

The main issues with this are being able to handle errors coming from other contracts, and getting results from those contracts. Each of those is easy to implement on its own, but getting the two working together nicely proved to be quite a challenge.

StrongForce:

What did we change (merged and in-progress)?

• Renamed actions to messages. While both are equivalent in terms of code, the name “message” better conveys that contracts can communicate things that happened (events) and not just things to do (actions).
• Refactored IStatefulObject so it is more generic. It is now used for the ContractRegistry and the AddressFactory, both of which are now persisted. This finally allows running a StrongForce testnet with multiple peers. While we haven’t tested with many machines yet, we got things working with two Tendermint nodes running on the same machine.
• Made sure contracts cannot catch arbitrary exceptions from other contracts since this could allow them to leave the system in a half-finished state.
• We are working on implementing a way for contracts to receive responses from the messages they send. Unlike some other actor frameworks, in StrongForce responses would always be received, and not just when sent from the other peer.
• We are also working on a way for contracts to handle failure from downstream contracts. We would soon need this for implementing a voting contract. Without contracts being able to handle errors, the last person to vote on an invalid vote would get an error on the whole transaction, and his vote would not be accepted.
• Implemented a way to make a query for all contracts of a given type.

Wetonomy Mobile App:

Wetonomy: No changes of note, waiting for StrongForce to stabilize again before updating versions again.

• Made a demo of the mobile app, which connects to the backend and streams live data from there. Check it out!
• Contributed changes to the webview plugin we are using, which would allow us to stop using a custom fork of it.
• Improved the integration of the Flutter frontend and Go/Tendermint backend, by implementing wallets and properly signing transactions in the frontend.
• Implemented wallet generation from BIP39 mnemonics. Working on saving and loading an encrypted version of the generated wallet.
• We are currently thinking of a way to implement terminal discovery. Currently, there is just one hardcoded terminal, the achievements terminal. In the future, we would like to make it possible to have organization-defined terminals (so that new users don’t have to install a whole bunch of terminals when they first start using the application), as well as manually-added terminals.

Join our Discord community to stay in the loop for updates and follow us on Twitter for more interesting tidbits and discussions on DAO and the future of work!

Originally published at http://blog.wetonomy.com on October 9, 2019.