Discobot Ticket 2: Worker Service

[alexyoung23j]

Description: This ticket handles the creation of a separate worker server that will pull discord thread/comment events from a RabbitMQ queue and hit the Common API (routes like createThread, createComment, etc) to complete the 1-way sync with discord.

Implementation:

1. Determine how we will handle bot permissions -> Current best estimate is we will add a new role to our current list (admin, moderator, member) called "bot"; this will effectively have admin permissions. And a new user associated with the bot will be created, assigned this role in any community that connects a discord forum, and the bot will then interact with the common API as this user. More speccing to do.
2. Set up subscription to RabbitMQ queue (described in #4266)
3. Handle all event flows -> comment event results in post to createComment, etc

Acceptance Criteria:

• Functionality implemented as described, and deployed to heroku succesfully.
• Testing coverage.

[dillchen]

This makes sense. A few bullet points:

• If / as we add a bot role, we will need to generate keys to post as address, this should happen on the worker(?).
• To continue to conform to the interface of roles, we'll need to add the right keys for each chain base, therefore the worker will need to know the chainbase. Other information of the community (this is stuff that the discord bot already has in DB, to be clear)

[ianrowan]

Per some research on our login flow:

1. We will need to create a User(probably via a migration)
2. On the CW side CC: @alexyoung23j - we'll need to automate discord bot user joining a community and grant admin privileges(if we dont create a bot role). I'm thinking we can add this functionality in the background when topics and discord forums are linked(ie check if bot is member yet, if not -> join + admin from backend)
3. Given our login flow we either need to manage a mapping of addresses for the bot or build a bypass into verifyAddress that can return profile details(ie User Id) so that a jwt can be retrieved via status.

Point 3 is probably the most open-ended decision left to complete this project. It almost makes sense to me to create a discordBot only route to issue a jwt but there might still be something in the address model i'm missing that will ultimately require us to assign multiple key types/signing algos to the bot.

CC: @jnaviask

[ianrowan]

Last step here is permissions. I think deciding on how we do this might require a wider conversation and decisions.

In summary we've decided the bot will have its own profile that admins can add to communities with admin-like permissions. We need to decide how 'custom' we should be about jwt issuance + profile details for the bot service.

As mentioned above to accommodate the current Commonwealth system we would need to store private keys for all community types(cosmos, ethereum, evmos, etc) and also build adapters to sign in similar to how UI functionality works.

My thoughts: Imo I feel that b/c the discord bot isnt really a holder of a wallet we should find a way to work around this requirement. And to do that we really just need a way to issue a jwt(a route? provides jwt.sign directly if bot provides a key) and skip any address validation on createThread/comment(need to dig more into this).

Like I said I think this should be an open discussion so I'd like to get thoughts(also probably worth a meeting discussion)

@jnaviask @CowMuon @alexyoung23j

[alexyoung23j]

Agree with jwt approach being the best option. It will be a little work to untangle the createThread and createComment from address validation because that's happening in the middleware, but seems doable.

[ianrowan]

I think something we could do here would be to set up new routes w/ different middleware pointing to the same createThread/comment logic.

We could even remove need for jwt in the first place and just give the bot a secret key that the bot specific endpoints checks for(we also don't need to worry about expiration here)