Governance Polling System Aepp Introduction

Hey all!

As mentioned in this weeks development update, we did start work to build a polling system to be used as first version of aeternity governance system.

Find first description of the workings of this system in the repository https://github.com/aeternity/aepp-governance/blob/master/Readme.md

Let me know if there are any questions, concerns or other feedback. We’ll be happy to discuss this proposal with the whole community.

3 Likes

is there a way to do a notification system for initiated polls and finished polls? So we dont rely only on forum/telegram etc to spread the news about the poll. It could increase engagement and voting turnout

3 Likes

Thanks @Luka this is a great idea, we will integrate events that can be listened for. A service for this will not be build in the first version, but will be enabled by this.

Unfortunately finished poll is not a metric we can deliver easily out of the smart contracts, but a secondary server can observe the contract and look out for those.

maybe other people and service could dock to those events and trigger messages by

  • email via newsletter API’s like mailchimp.org
  • SMS via Twillio.com or comparable services
  • telegram bot messages
  • browser push notifications (example via third party services like https://onesignal.com/)
  • mobile push notifications

And maybe the Base wallet @stoyan_ae or AEXpansion team @emil and or middlware @jsnewby could think about a standard for this then different wallets, blockchain explorers etc. could use that standard to trigger mobile or browser push notifications etc.

4 Likes

@piwo thanks for sharing! should the description include some points on how polls are created/added? from my perspective this is a very important part–understanding anyone could create a poll and the UI for doing so.

@emin you mean a standard for broadcasting the poll announcement/duration/ending/results?

1 Like

@stoyan_ae currently the description includes no implementation details, wireframes or UI proposals. This will be figured out as we go. With the current discussion we want to make sure the polling mechanics work as intended. Creating a poll will be a simple form available to any user.

I think @emin was referring to a notification standard overall, where the discussion would be out of scope for this thread.

2 Likes

Are there already mockups and/or screens for the UI/UX?

1 Like

@emin we will post them as soon as we have some first drafts that are representative

Hello @emin, here you can find a first draft of the voting and delegation functionality, keep in mind this is nowhere near finality, lots of design changes will be made, caching and oder performance optimizations will have to be done as well as proper handling of errors and more testing.

6 Likes

Great work! I am eager to test this. Also, I am all for the notifications proposed by Emin above. This is essential for an engaged community. Would love to receive a notification in the Base aepp, but other options should be available too. Let’s first get the mechanics and UX/UI right :slight_smile:

2 Likes

Notification service should be created as a separated service IMO. The core governance polling system should be created in a decentralized fashion:

  • backend implemented on blockchain (as a system of smart contracts)
  • frontend which source will be maintained as a git repo (on github let’s say)

As above parts will have no relations to the external systems there will be a possibility to build them and operate them permissionlessly.

Apart of them, there might be another centralized system build that again will have two parts:

  • backend - normal centralized webapp - it will connect to external notification services (ie. to send email, etc.)
  • frontend - it can be a new app or it can extend “core governance polling system” frontend app

But as @ae-vlad mentioned it, the BaseApp can also be another app to monitor polls - it will have to combine backend and frontend functionality.

1 Like

I do fully agree @drag0x. But we will need a fully trustless backend server as well. Some aggregations would be way to slow to be counted by every client. Imagine 1000 voters, having to check their balances would be 1000 requests to the node. Then voters may have delegations and delegations can be recursive, for each we will have to get balance at height to show a preliminary result.

The backend service will be able to be hosted and verified by anybody and only assists the voting experience with additional aggregated data and is not necessary for voting.

Maybe you can try to create a general API service that will serve such applications (dApp + frontend). Think about https://infura.io/ for Aeternity.

For example, if the logic how to calculate the final result will be implemented in the smart contract, it should be possible to call that entrypoint via general API to see what is the result at that moment. Similarly, you will have to just implement all the entrypoints that will be useful to expose all necessary data in the frontend app.

1 Like

sadly counting this is not easily possible with a generic service, with the features we want to allow.

sophia currently has some limitation why we can’t do it in the smart contract…

Would you mind to shed a light on these limitations and if they will be overcome?

1 Like

There is 2 problems that keep us from doing it.

  1. Recursive datatypes are not available in the sophia language right now. This is planned to be implemented after the next hardfork but is a limiting factor right now in discovery of delegation chains, as delegations can be done with recursion and thus will be great to be represented by a recursive datatypes. There are possible workarounds, but they would be very costly in gas and amount of code.
  2. There is no Chain.balance(height) function in sophia, without this fetching stakes for past polls can’t be done in a trustless and reliable way within the smart contract. If we would have this feature in sophia it would be quite costly as well, as either all past account states would have to be persisted or will have to be recalculated for every call.
  3. Some endpoints need lots of calls, as explained in a prior post. Imagine 1000 voters, having to check their balances would be 1000 requests to the node. Then voters may have delegations and delegations can be recursive, for each we will have to get balance at height to show a preliminary result.
    Even if this would be possible to do without a backend it would lead to extensive load times when opening the aepp, in early testing over a minute for polls with > 50 participants.

All of these can easily be overcome by using a trustless backend server, that can be hosted and verified by anyone.

2 Likes

Updated demo video, with new features:

  • correct delegation counting
  • show delegations or what delegatee voted for account
  • new accounts presentation

Consider the issues list as tracker for upcoming features: https://github.com/aeternity/aepp-governance/issues

2 Likes

OK, not everything need to be implemented in a smart-contract especially if it will blow up complexity. But then I suggest to extract from the backend some essential logic as a separate library that implements that logic. Everybody will be able to clone it and run it on their own computer to verify polling results. I guess it can connects to any Aeternity node and then generates polling stats. Will it need any special middleware to be run on the node?

1 Like

Yes this is the plan, the Backend will be mostly verification script and caching method. We will provide a way for anyone to verify the poll results just with access to a node.

Aeternity’s infua is @jsnewby Middleware (API Server) maybe he has a few ideas input here