Encrypted Pillar Messaging within syrius and the C# cli

Development
1

Issue

Pillar voting is very low. We generally have 30 Pillars consistently voting which is barely enough to approve AZs and funding requests. In addition, Pillars who control more than one can single handedly kill a vote by simply not voting. Our system was designed to promote a democracy with decentralization, not a monopoly with centralization.

How can we improve voting and engagement by Pillars?

Proposed Solution

Encrypted messaging in syrius. If we can send messages to Pillars they might read them and consider voting.

Background

@sol @vilkris and @aliencoder have investigated messaging solutions. We have also discussed this topic with Mr. Kaine in TG.

Pillars do yield farm even if they don’t vote. If we can send them encrypted messages and show a notification it’s possible they will look at a message. If they will look at a message, we can ask them to look at and/or vote on an AZ or funding request.

Proposal

  • Add messaging functionality to the C# cli that leverage the work that @vilkris did on messaging.
  • Use the cli to send encrypted messages to addresses in NoM. By limiting the message generation to the cli it’s possible we can reduce spam. Barriers to create messages are higher.
  • Add a notification in syrius when an address receives an encrypted message
  • Add a display window to read the message.
  • Consider adding a fee to see a message in syrius. Meaning, for a user to send a message they must pay x znn for that message to appear in the users wallet. If no fee is paid, the message will not appear. This will be enforced in syrius, and not the L1.
  • We could also consider creating a messaging token that is used to send messages. And that token must be purchased. Maybe the dev who codes this could benefit from selling that token. This is not necessary. It’s just an idea.

Issues

  • Mr Kaine encouraged us to reduce chain bloat. And this could encourage spam. However, users will not see messages unless a fee is paid. We could also deposit this fee into AZ.
  • Can we limit message size? Maybe we can enforce the message size at the cli level.
1 Like
2

I received the following idea from a DM in response to this post.

I think it’d be more efficient to have a feature that allows pillars to delegate their votes.

Either a separate binary that runs on pillars along znnd, or as a new feature for znnd

1 Like
3

The only option you have is to rewards vote or reduce rewards of non voters. I highly doubt spamming an onchain mailbox will change the trend. This solution don’t change the amount of ZNN earned by the pillars pack, it simply adjusts the % you get according to your activity. You want 100% of your current rewards? Vote. Or else, these ZNN will get distributed to active Pillars.

1 Like
4

I have to agree with @Chadass here. We don’t want on-chain messaging bloat.

We can implement Web3Inbox from WalletConnect and create a dApp dedicated to Pillar owners where they can post announcements or engage with their delegators.

5

Or perhaps even redirected to Accelerator-Z? Especially giving consideration to how the community’s been looking for ways to make AZ more self-sustaining.

6

I guess we have two problems:

  1. Low pillar participation
  2. Active pillars who do not vote at all (on purpose) to torpedo votes

It’s possible we can solve #2 by changing the way the quorum is established. I think the quorum is 33% of all active Pillars? Maybe the calculation excludes inactive pillars from the quorum. That way Pillars who do vote usually are incentives to actually vote if they want to be considered in a quorum.

I do find it curious that 2 Pillars who never vote actually run Orchestrators. At a minimum, why include Pillars with zero votes in the quorum?

We currently have 23 pillars who have never voted. If we remove them from the quorum (99 - 23 = 76 x .33 = 25). That would reduce the quorum to 25 pillars.

Screenshot 2024-03-01 at 5.40.00 AM
Screenshot 2024-03-01 at 5.40.00 AM2688×1640 285 KB