Proof of Pillar, Sentinel and Delegator Integration with Discourse

Zenon ╰ Network
1

We need a way to automatically assign badges and group membership in Discourse based on a signed message from the syrius wallet. That way Pillars, Sentinels and Delegators can securely communicate in the forum.

We need a discourse plugin that takes 5 (maybe 6) fields. 4 the field below will be pasted into a text field by the user (under preferences). The 5th field will be a drop down with “Pillar, Sentinel, or Delegator” below in the User’s Profile

{
  "message": "deeZNNutz.com",
  "address": "z1qrztagl9rukq3ltdflnvg4zrvpfp84mydfejk9",
  "publickey": "88c0ebc7de1aa0b6e1958b4ead1f43df15f2e92f3f876c564005ee38da9a77f0",
  "signature": "24b719f5209bbf653d27445e8c298a4cd4f4f5a1c384e079de9945516d4b999a5acc57dca49a6778110176f409144db645243fc7f88550e0f42b93bb17ed190e"
}

The plugin will then interact with this API

The output will be either True or False.

If the user selects “Pillar” and returns True, a Pillar badge will be assigned along with the Pillar group. If the API returns False, Produce Error

If the user selects “Sentinel” and returns True, a Sentinel badge will be assigned along with the Sentinel group. If the API returns False, Produce Error

If the user selects “Delegator” and returns True, a Delegator badge will be assigned along with the Delegator group. If the API returns False, Produce Error. Ideally we can add a 6th field where a delegator indicates the pillar address they are delegating to. And the API can check that too. Not sure if this is possible.

Results will be stored in the DB. In addition, setup a job to run daily to retest the proof to ensure the user has not moved delegation or removed a pillar / sentinel. All fields should be encrypted in the DB.

I will fund and seek reimbursement through A Z.

1 Like
2

Right now the endpoint doesn’t do any checks on what the address is linked to. So the plugin would have to consult with a node to make this work or the endpoint would need to be amended.

Yes this is possible to do.

I think this needs some special consideration. Playing devil’s advocate here but this would essentially be a database of all community members linked with their znn addresses. They would have to trust this database to be secure and that the admins of the database don’t misuse the information.

3

True. This is a problem. A couple ideas:

  1. No DB. The badge / membership needs to be renewed monthly? So you sign a message in Discourse, and then get the badge / membership for 30 days. The system then reminds you to renew on day 25, 26, 27…. If you do not renew then you lose membership / badge. No data is stored.
  2. then, once you are in the Pillar / Sentinel group, you need to sign a message in order to post in that pillar / sentinel group. You would create a post normally, but to post you need to provide the signed message. The API would then authenticate the message. if true, it posts. If false it fails with error?

I think this is a temp solution until there is something better in the wallet. Thoughts?

4

Maybe you modify the endpoint and we include this in the project scope of work?

5

TBH I have no experience with Discourse plugins so off the top of my head I’m not sure what the best solution for this would be. Would require some digging.

6

Yeah this could be added to the endpoint.

7

Discourse has an active marketplace for plugin developers. I was hoping to post this over there and get a price once we have a scope of work. Maybe you can handle the API endpoint changes and the discourse plugin expert can handle the rest.

8

Oh that’s cool. Yeah that could work.

1 Like
9

@romeo now that the project is approved, i want to work on this automated plugin. Have a look at the discussion above and let us know your thoughts. This could be a fast (centralized) way to verify Pillars, Sentinels and Delegators until these functions are available in the wallet. At a minimum people in the forum.

I want to rethink this a little too. I think we should have the plugin first generate a UUID. That is given to the user to put in the message field of Syrius. The user signs that message in the wallet and then provides the signature and public key. That way people can’t share signed messages to get a designation they don’t own.

The question is how do we store or update or refresh this information. Gotta think through that.

10

let me ponder on that too - don’t want to over-engineer a solution but making the request unique would be beneficial

11

Good reference link to investigate