modmail-dev / Modmail

A Discord bot that functions as a shared inbox between staff and members, similar to Reddit's Modmail.
https://docs.modmail.dev
GNU Affero General Public License v3.0
1.58k stars 4.59k forks source link

Provide support for multiple servers instead of one #99

Closed ghost closed 4 years ago

ghost commented 5 years ago

self explanatory

fourjr commented 5 years ago

Can you elaborate on why this feature would be useful? Use cases

sircam191 commented 5 years ago

Why not just make different bots for each server?

ghost commented 5 years ago

It’s pointless.

Taaku18 commented 5 years ago

IMO this is a great future enhancement idea.

The primary method of deployment for modmail is through heroku:

Main arguments:

kyb3r commented 5 years ago

Modmail is meant to be used with only one/two servers since that way you know which server the member is messaging from. Currently, there are two server setup options:

Both are supported. However, if you add the bot to more servers and the user that is messaging is not in the specified main guild, the thread created embed will not have member-related info such as roles etc. image

So technically adding it to multiple servers is supported but is not exactly suitable for the uses of this bot.

fourjr commented 5 years ago

About the heroku issue:

  1. Dyno Hours Limit - Modmail isn't affected by it
  2. Apps Limit - Create a new account
Taaku18 commented 5 years ago

I propose the enhancement to introduce segregation within the bot, not exactly a centralized server (although that can be an addiction). Where the bot wouldn’t be single server targeted, instead, all the configurations will be configured within the individual servers that the bot were deployed to. The backend database can also be modified accordingly, perhaps categorized by the server that the bot is serving. Different servers that the same bot is serving can have little or no connection with one another. If implemented correctly, there shouldn’t be any changes (other than you can use the same bot thread to manage multiple servers).

The bottom line I’m trying to make is that instead of making separate bots and hard coding config vars to setup the bots, the same task can be accomplished through dynamic addition of servers, server independent configurations, and segmentation of the database. All of that while consuming less resources.

fourjr commented 5 years ago

Config carries over if you use the same modmail api token

kyb3r commented 5 years ago

If a user shares multiple servers with the bot, there would be no way to know where the user is messaging from, and where to direct the message (with your suggestion).

Taaku18 commented 5 years ago

I guess that’s true, since the best one can do is get a list of all the servers the bot and the user have in common. You can, though, embed information about the user for all servers, and if you really need to know where they are from, you can always just ask. I see and partially agree that this might be considered going slightly different direction as you had planned with this bot. Still, I hope this gets considered in the future as the practicality of running separate apps for different servers is still questionable.

fourjr commented 5 years ago

How is it questionable? 🤔

Having different modmail bots for different servers is what you should do.

kyb3r commented 5 years ago

Having a dedicated bot for each server gives customisability that a lot of larger servers need. Also asking a user where they are from is not a streamlined user experience and isn't something I personally like.

Taaku18 commented 5 years ago

@fourjr Managing 50 servers isn’t all that uncommon, I suppose you expect me to first sign up for 10 emails and apply for 10 heroku accounts? 😅

fourjr commented 5 years ago

50 servers? what kind of thing are you even running?

kyb3r commented 5 years ago

If there's a centralized inbox location, support for multiple guilds shouldn't be hard, just a bit of checking which guild the user is in. If there are multiple shared guilds then sure you could explore different options as to how to display member info. However multiple inbox locations seems kind of far fetched.

kyb3r commented 5 years ago

You can surely make changes here to allow at least basic support for multiple guilds.

WebKide commented 5 years ago

Working on this, I'll keep you posted as new development comes available on the official repo

WebKide commented 5 years ago

FIRST CASE SCENARIO

1) user messages modmail
2) modmail shares single server with user, then messages there to the mods
3) everything goes on as usual

SECOND CASE SCENARIO

1) user messages modmail
2a) modmail shares 2 or more servers with user
2b) modmail acknowledges message received and asks which server user wants to message
2c) modmails gives options with names, maybe reacting or sending a number [or guild name]
3) after user answers, modmail starts the ticket where it belongs
4a) user's DMs are linked to that server until ticket is closed by Mods
4b) maybe user can also request to finish the ticket directly in DM to contact a different server's mods
WebKide commented 5 years ago

One more thought came to mind

If user shares a few servers with modmail and a few mods. How about instead of replying with Discord name, rather use user nick of the mod in the server they are replying?

Personally I have several nicks in various servers, and though people know it's me, the interactions tend to change based on the nick they see

Sasiko commented 5 years ago

i like second case solution by webkide. If bot detect that the recipient and bot share same server it will just give list which they are contacting from.

In order to relay your message to the right server please input the following option of which server you are contacting from: Server A Server B Server C

And then have the bot addreaction emojis A B C Once user react to either of it then the server thread creation message popup

kyb3r commented 5 years ago

Adding a ?newthread command or clickable emoji to start a thread (#224) would resolve which guild a thread is coming from.

github-actions[bot] commented 4 years ago

This issue is stale because it has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 5 days