• Upon Election finish / Revealing stage over the bot announces new council, tags their discord username as linked with pioneer.
• Announce period starts - Bot announces this and mentions how long is left and how to apply etc
• Each time a candidate announces - Bot announces (i.e. “Fred has applied for the election”)
• Announce period ends/voting period starts - Bot announces + does an update of vote stats every 12h
• Revealing period starts/vote period ends - Bot does updated stats every 12h

Original requirement can be found here.
https://pioneerapp.xyz/#/proposals/preview/237
https://pioneerapp.xyz/#/forum/thread/325

Background

People have expressed an interest in being able to socially tip each other on Discord, right now do not have a way to do that. There has been an attempt at doing that, but it has some significant design flaws - among which is to require users to provide their seeds, so we need some more solid requirements.

Note: I am not conviced about the real value in executing on this now, given how complex it is, and likelihood of it being adopted, but just posting this

Proposal

Maintiner

@DzhideX

Infra

Jsgensis operated.

Target chain

Carhtage

Requirements

The idea in this proposal is to only use Discord handles as identifiers, and sidestep the entire problems of mapping on-chain memberships to users, as that gets very messy and complex. This requires that Discord handles are used as identifiers, and that we are sure that they are obth immutable and unique. This seems to be changing on Discord these days, so we must be careful to get it right.

• Users can tip each other using Discord handles
• Users can tip Discord handles that do not yet have any on-chain membership or accounts, money is instead held by bot.
• Users tip each other using funds they have pre-deposited in a tip bot account, hence they do not share any seed or secret with the tip bot, the bot is in essence a custodian.
• Users settle balances by cashing out, so all intermediate tips are not settled on chain until there is a cashout.
• Users can check the balance of any other user in the tip bot.
• Users can see the tip bot transaction history of any user.
• Users can cash out to a raw account only.
• Admin can set a daily transaction count limit.
• Admint can set a daily cashout limit, in terms of $JOY.
• Admin can set a daily deposit limit, in terms of $JOY.
• There is a help command which links to some external page or something.
• Bot must be versioned!
• There must be a stats endpoint that outputs information about version number, whether bot has gone fractional, or has too much money, etc.

Resource

https://github.com/paritytech/substrate-tip-bot

See below link: #16 (comment)

Problem

I cannot claim my membership.

• The bot asks for the root account which shouldn't be done because this account should be kept in cold storage. The root account is very much not appropriate for this kind of activity. The root account is capable of changing the controller account and although not every user uses this level of security it is not a good idea to depend on people having to use their root account for this kind of activity.
• controller account is also inappropriate because one controller account can be tied to multiple member handles
• The bot should prompt for the Joystream membership handle and then the user should be asked to sign using their controller address
• The bot does not explain how to submit /solve, the prompts should reference this. The only way I understood to do this was seeing other users in the server do so.

Notes

• /claim
  • Asks for root account--this should ask for controller account as root account is typically kept in cold storage.
  • Bot replies with Go to this URL [https://polkadot.js.org/apps/?rpc=wss://rpc.joystream.org:9944#/signing](https://polkadot.js.org/apps/?rpc=wss://rpc.joystream.org:9944#/signing "https://polkadot.js.org/apps/?rpc=wss://rpc.joystream.org:9944#/signing") and sign the following data with the given account. Zb0mbbk7RG
    • I do this action and it doesn't explain where to put the signed data on Discord. Replying to the bot or just pasting it in chat does not do anything.
    • If I /claim with the signed data the bot appears to get stuck thinking for a long time/crashes.
  • Changes needed
    • Instructions to user must be far clearer--"Use /solve to submit your signed data". The bot currently doesn't explain how to do this step.
    • /claim takes any input, it should validate an address
    • /claim should be asking for membership controller address and not root address (!).
      • It should really prompt for the member handle and then ask them to sign using the controller address.
    • How does bot deal with an address that has multiple memberships attached to it?

https://pioneerapp.xyz/#/forum/thread/316

The current discord bot already couples the discord ID to a certain membership.
So this new feature requires to call the tokenSend extrinsic.

The parameters should be like this.
/send discordId amount rationale privatekey

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

Requirements:

• discord posts for important on-chain events
  -- New threads and posts in Pioneer Forum should be displayed in "Forum" channel
  -- New proposals and posts in Pioneer Proposals should be displayed in "Proposals" channel
  -- Salary adjustment and discretionary spendings for each WG in their respective channels
  -- New openings, hires, fires for each WG in their respective channels
• The election stats notifications should be incorporated here
  #9
• has a help command
• should be versioned

• All leads should be added to appropriate worker tags, so someone can tag the worker role and it will automatically tag the lead of that WG as well
• All leads should be added to the @WG Leads tag
• All council members, leads and workers should be added to the @DAO Workers tag
• @Newbie tag should be automatically assigned to new users until they decide to remove it.
• Membership name should be displayed somewhere in the discord profile

Problem

Currently we have a channel called Opportunities & Openings on Discord and users are referred to this if they are interested in work. The problem is that no one has written a message in that channel since September and there have been dozens of openings that have created and hired in that time.
While we could assign the HR working group to manually post openings as they are created, this is tedious and repetitive work. The openings are sometimes advertised in other channels, but this isn't as consistent as having a bot that can do the work.

Solution

• A bot that monitors the query node for new openings and posts a brief summary in the Opportunities & Openings channel with a truncated description, the working group and other important information.
• The bot could also indicate when an opening has closed but this seems tedious and not of substantial use.
• A user should basically be able to join the relevant channel and be able to scroll through the recent openings, see if anything interests them and click a link to go to the relevant opening on Pioneer.

A new bot idea suggested by HR.

• Welcome messages: HR usually sends this messages some minutes after a user joins the server, we assume that they have verified in "N minutes" because there is no notification that a user has successfully verified before sending them welcome messages. If we want to use the mee6 bot as a side bot and not tamper with JSG bot, it will have to send welcome messages when a new user joins the server (with no knowledge if they have verified or not) but if we want to fully optimise this, we'll have to use the mee6 bot as our server's bot to handle verification as well and send welcome Messages after a member has verified.

• Frequently posted messages/questions like: hi, hello, I am new here, great project, when listing?, Nice project, good project, Just joined what to do? Etc. And HR workers or any Community member can take it up from there upon the user's respone. These are messages mostly coming from new members that HR is going to get overwhelmed replying to each and everyone of them with the ongoing campaign and soon listing

• assign role "Newbie" to properly tag only them for updates and useful information on how to get started.

SSIA
Leads are currently not included with the workers which is annoying and means people have to tag both the workers and the lead individually to address the entire WG.

SSIA - add a Discord role that is applied to current candidates in an election cycle. This would be useful for several reasons, such as being able to ask the current candidates questions

• The role should be removed once the election finishes

SSIA
bot assigns/unassigns roles repeatedly (see related issue: #27)

SSIA, this role is important because it makes communication and coordination a lot easier and we don't currently have a role that does this so people have to tag various other roles.

Problem

SSIA but the role bot basically keeps assigning and unassigning roles on a continuous basis (even though there is no change in the roles). This makes navigating Discord's Audit Log very difficult and makes monitoring important moderation events impossible.

Problem

We are trying to build more activity in the NFT marketplace on Joystream. While there are notifications that are user-specific within Gleev these don't really communicate current activity super well. We have 2 NFT related channels on Discord that aren't used very much. If users were able to be more aware of current bids and sales on Discord it may help quite a bit with increasing activity.

Solution

A bot that shows

• new listings/auctions
• new bids
• purchases

This would obviously be a very hectic bot at some stage, but we can scale the amount of messages and add certain thresholds at a later date that cut down the amount of messages

Background

For a long period of time, the Discord bots have either not been working, or not had the right features. An attempt was made to update one of the existing bots and add a new tipping bot here #4, however it is both old and also there are issues in implementation and feature set.

Proposal

I am here introducing three distinct and explicit requirements for each of the bots we see a role for in the Discord at this time. The purpose of this initiative is to level set on exactly what each bot should do, and how implementation, review and deployment should work.

1. Role bot requirements: #5
2. Tip bot requirements: #6
3. Notification bot requirements: WIP, unclear if worth it - given that Pioneer notifications will soon work, and it can easily backfire if it gets noisy, as it often has.

These have been ordered in terms of desdending ROI, so executing in order is probably a good idea. These bots should be in separate codebases, but one repo, and PRs should be updating one at a time if at all possible. If there is some generic code that needs to be shared, put that in some new common util/commons folder.

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