Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Role bot requirements #5

Open
bedeho opened this issue May 19, 2023 · 5 comments
Open

Role bot requirements #5

bedeho opened this issue May 19, 2023 · 5 comments
Assignees

Comments

@bedeho
Copy link
Member

bedeho commented May 19, 2023

IMPORTANTLY: we are starting from scratch here, the current bots have all sorts of legacy behaviours which should not carry over.

Background

Often in Discord one may want to address the member currently occupying a role, but one does not know who this member is, and looking it up on-chain is very tedious. Likewise, there are channel permissions which one wants to assocaited with on-chain roles, rather than Discord memberships. The solution for both of these problems is to automatically maintain what set of on-chain members should have a given Discord role membership, by exploiting the fact that on-chain memberships include the possibility of specifying.

Proposal

Maintiner

@DzhideX

Infra

Jsgensis operated.

Target chain

Carhtage

Requirements

  • Must be versioned.

  • On-chain roles for which we want to maintain correct set of Discord members in corresponding Discord roles

    • Founding Member
    • Creator: anyone with channel > 1 video.
    • Council Member
    • Content Lead
    • Content Worker
    • Storage Lead
    • Storage Worker
    • Distribution Lead
    • Distribution Worker
    • Builder Lead
    • Builder Worker
    • HR Lead
    • HR Worker
    • Marketing Lead
    • Marketing Worker
    • Forum Lead
    • Forum Worker
    • App Lead
    • App Worker
  • We need full synchronization, meaning that Discord roles should exactly map all on-chain role sets with minimal slippage, and this will not be disrupted if a the Discord bot is temporarily halted, or if roles on Discord are manually changed, etc.

  • It is probably best to do the synchronization in a stateless way, i.e. not maintain any assumption about what on-chain events you have or have not processed at any given time, just instead at regular intervals do the following

    1. Collect a full list of Discord members and their handles/IDs.
    2. For each Discord role above
    • remove all Discord members from that role
    • execute a QN query to build a list of on-chain members associated with with the corresponding on-chain role. For each on-chain member also store whether they have an associated Discord handle in their metadata.
    • store this list and a timestamp & block of query locally: is not used for synchronization, but for a command.
    • for each on-chain member who has both a Discord handle in their metadat, and that handle exists on exactly one Discord member, then add that Discord member to that Discord role.

This way of doing it means that regardless what interventinos members do in terms of changin their Discord handle on-chain, or someone manually updates Role sets in Discord, or Discord bot is down for maintenance, it will always just work, and it will be very easy to debug. The synchronization interval must be configurable.

  • The following user commands should be available
    • who_is [discord_handle] lists member id, on-chain roles above, or if no mapping exists, this shoul be said, along with a link to some external resource about how to establish it.
    • list_role_members [discord role]: same as doing who_is on all discord handles in discord role, and include discord handles that hve no mapping, just as in who_is.
    • status lists
      • on-chain roles that are empty
      • what version of bot is running.
      • whether everything is OK or not, some sort of status indicator basically
      • last block where synchronization happened (assuming its poll based as above), current
@mochet
Copy link

mochet commented Aug 2, 2023

for each on-chain member who has both a Discord handle in their metadat, and that handle exists on exactly one Discord member, then add that Discord member to that Discord role.

This part is a problem in that people can do impersonation attacks, especially if we assign distinct permissions to Discord roles. There is no clarification on what to do if two or more members claim the Discord handle. Furthermore, entering a Discord username on a Joystream profile does not verify it.

The current implementation of the bot requires a user to sign a challenge using polkadot-js to prove they own the Joystream membership handle.

image

This isn't included in your specification, but is this an acceptable method of verifying users?

@bedeho
Copy link
Member Author

bedeho commented Aug 2, 2023

I did not understand this, can you raise the issue on a DAO meeting in the near future?

@DzhideX DzhideX mentioned this issue Aug 9, 2023
@chrlschwb
Copy link

@bedeho
We have a question about the requirements.
image
Currently, the list_role_members [discord_role] command displays all users with [discord_role] like this.
image
If the viewer is interested in one of the displayed users, they can use the who_is command to learn more.
I think it's excessive to display all the roles of all the users with [discord_role]

For example: If I type, list_role_members @FoundingMember, I want to see who are the founding members, and not what roles each of the founding members are occupying.

@bedeho
Copy link
Member Author

bedeho commented Sep 27, 2023

I think it's excessive to display all the roles of all the users with [discord_role]

Agreed.

@mochet
Copy link

mochet commented Sep 27, 2023

@chrlschwb I would suggest one thing in addition to what is present. There should be a discord role called something like on-chain member or similar which is registered to all users who have their Discord set up in their Pioneer profile.
Although most people are founding members due to our community size, this could change and we could have workers etc that aren't--it makes it a bit easier in the long term in Discord to communicate with people who have actually gone to the trouble of properly setting up their Discord profiles.

We had the same thing with the old bot but it was called on-chain identity verified--we could use the same name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants