Creating Discord bots for helping DAOs onboard members onto Wonder

[andywong418]

This is important for DAOs to direct new members to our platform so they can start contributing

[stammbach]

Hey, like I said in the Discord, i'd like to challenge this. Started fiddling around and exploring some ideas. But there are some things that need to be sorted out for this.

• Hosting
  • The bot will need to run 24/7, so an dedicated VPS somewhere would be required; personally I would have to issue providing because there are some hosts that provide that for $3+ per month; but probably you want to have that under org control I guess, then we would have to setup some github actions to automate the deployment
  • Some hosters I found researching with bot hosting in mind, personally I would go with Vultr or Digitial Ocean
  • https://www.vultr.com/products/cloud-compute/
  • https://pebblehost.com/bot-hosting
  • https://www.digitalocean.com/pricing/ (droplets)
  • https://aws.amazon.com/ec2/pricing/on-demand/
• Implementation
  • Adding this to the server would require some restructuring on the Discord Server itself; so probably has to be guided by the bot dev (myself I guess) or even done by the bot dev himself

If you want I can layout some of my ideas here or I can invite to my test server, but like I said, mostly exploration rn.

[andywong418]

@stammbach This is dope! We'll look into getting the hosts running- I've worked with Digital Ocean before but if you have experience with Vultr we can go with that. Would love to get some help on that.

Curious to hear what the restructuring on the Discord Server might mean - also looping in @Lonisss who mentioned he might be interested in helping out here too!

[stammbach]

@andywong418 personally I used Digital Ocean in the past. Easy of use is definitely given there, also because they got preconfigured VMs for stuff like Node out of the box. I would write it in Node using Discord.js because it seems to be the most complete solution out there and I already started with it. Just mentioned the other options because you guys might already work with another host and Vultr was popping up frequently regarding Bot hosting for example.

And restructuring sounds worse that it would actually be. Personally I would suggest that most of the channels are gonna be hidden by default. Because it's just a lot to grasp for new users joining it (myself included).

I think we would need to incorporate a more guided flow on starting at the discord.

1. Joining in a "start" channel being prompted with a nice welcome message and community guidelines/rules
   • Users then have to accept the guidelines via a reaction (like on most discords nowadays)
   • When user accept/react to the guidelines they get a "member" role which grants them access to basic channels including the information category and a new "getting around" channel
2. The "getting around" channel would then let users choose what they are interested into; either connecting with the community or contributing to wonder
   • Users would then self-add rules using discord buttons; "Community" or "Contribution Candidate"
   • Each role would unlock either the community and/or the contribution/wonder-product category
   • Each category would also introduce a getting started channel where
     • Community: Choose desired communities: GM, LGBTW, MEMES, etc
     • Contribution: Applying to Product, Growth, Engineering via custom Commands -> see 3.
3. Reworking Wonder-Product to be closed by default and automating Candidates via Commands; this would also require storing discord user ids, but sqlite should be enough to handle this on the bot VM itself
   • Apply Commands would post Applications via a shared Channel
   • "Contribution Managers" / Admins can then either accept or decline those Applications

[andywong418]

Just checked everything out looks great! I understand the restructure now - each roles unlocks different channels both public and private.

1. Love the start channel idea and this makes sense
2. Agreed with all points but I think certain community channels like 'Report' and 'Community Management' should be open by default to all
3. What applications would these be - is this for vetting candidates for specific working groups like Engineering, product etc? sqlite makes sense for storage within a discord channel

[stammbach]

• 2: After the user accepted the guidelines via the start channel generic channels like report would of corse be available alongside the information category; maybe even consider opening a dedicated help & suggestion category
• 3: by applications I basically would automate a handful of questions via commands; for engineering I has something like: github/gitlab url & about me; in mind, but what would be asked would of course be up to discussion
  • candidates would not have permission to message in the candidates channel; only in threads; I would then automatically add a fancy widget message with the data the candidate provided und start a thread where everyone can talk with the candidate and then either accept or decline

[andywong418]

2. Makes sense!
3. Interesting so this is assuming we want to vet contributors before they contribute. I think having an intro with GitHub/Gitlab link is a good idea, but think contributors should have a chance to prove themselves by taking tasks and creating PRs rather than through their resume or previous GitHub work.

[stammbach]

3: Like i said it's just exploration. Got no issue with that. Could also make it self-joinable like on the other groups. But I would definitely add a Contributor role for people who already have contributed to separate a little and improve visibility. Also because they might get mentioned even tho they just started exploring. Just want to minimize the load on new users as much as possible.

For that self joining we could then also use buttons or keep the command idea to at least prompt a little about me text, that's basically happening rn anyway!

[andywong418]

Connecting each task to Github and Discord (when we have our task management out) will be a great feature as well :)

[stammbach]

@andywong418 depends on how that task management will work on the end; ultimately users then need to be able to connect their wonder account with github & discord using oauth for this to work. But in the end the result would be awesome of course.

[andywong418]

I guess I meant finishing a task via Github would add a message to a channel on Discord. This wouldn't need each member to add oauth right?

[stammbach]

Oh okay! I think there are GH Webhooks that could be implemented for that.

Thought you meant that there will be like a automatic role update and announcement when the actual wonder task is completed. But for that to work the wonder account would at least had to be connected with Discord to work.

[andywong418]

@robertDurst is working on #30 and so yeah we should just make the Wonder Github org connected with Discord to update a channel when tasks get completed. What do you think?

[jreeter]

I read recently that we could use AWS Lambda or GCP Functions for a bot with endpoint integration? This is pretty interesting, here's an article on a Lambda approach: https://gemisis.medium.com/building-a-serverless-discord-bot-on-aws-5dc7d972c9c6

btw, would love to help with this issue.

[andywong418]

@jreeter Yes definitely would be great to have you work on this as well - also really like the GCP functions idea. What are your thoughts @stammbach?

[stammbach]

Very interesting. But we have to factor in the long term. You can choose what type of events you want to handle via the Bot, problem is when we might for example, filter messages using keywords, every message sent on the discord would then result in one Lambda/GCF/Workers call which would then also increases the cost of running it at the end.

Also for Lambda you not only pay per million calls, you also pay for the compute units (CPU time basically). I think GCF works in a similar fashion.

Another point would be that the handling would be a lot more manual; most libraries expect to run a server all the time instead of working in a webhook fashion.

But if thats a better solution for you guys I could look into it. Personally I would suggest Cloudflare Workers then; they are really cheap and eliminate the cold start you would have on Lambda/GCP, which would also improve working with Discord because the medium article said something about a requirement of responding within 3 seconds.

[andywong418]

We have the capabilities of writing our own servers so maybe that would be a better way to go esp to save cost and to add custom functionality. I do think we would need to listen to webhooks on our server anyway though

Looking into hosting servers versus using GCP might be prudent, my thinking is that for high traffic (high call of APIs) hosting our own server would be less costly but I haven't used serverless that much so I might be wrong.

[stammbach]

Both have their advantages; with serverless huge traffic peaks should be no issue for example. But in the end it highly depends on what we want to do with the bot in the long run and even more how much traffic/action is happening on the discord itself. There are some basic community insight for the server right? Can you figure out how many messages are send per day on average? That would be a nice baseline to actual calculate any pricing options. (especially serverless pricing)