a... feature request... I think?

[AeSix]

Ok, so, I'm using BungeeMail in an unusual manner. I have two BungeeCord servers. One is production, the other is for testing/demo.

I accidentally found out today that with BungeeMail on each proxy, pointing to the same database, it is possible for players to send mail between the two networks. Pretty awesome!

The problem, and I understand why it is such, is that BungeeMail, not being a network application per`se, does not send notification of new mail to the backend server and instead just handles it internally. This is great, but for my use, there is no notification of new mail to the recipient, because that instance of BungeeMail is separate from the instance which sent the mail. Like I said, I completely understand it being like this.

Several solutions I came up with:
So, I thought about having a single "Push Notification" table, row or even single field on the MySQL server, and have BungeeMail periodically check that to see if it has new mail from another instance elsewhere. Then, I thought about how much data that could be, and the potential bugs, if there is a lot of mail sent from each instance - which instance set the field, which instance unsets it, etc. So, maybe something like that could work, but it'd be more than a "simple" enhancement.

Then, I thought about instance-to-instance socket communications. That'd work, but a lot of overhead, annnnd then yet more ports to open/forward, etc. This solution could work, but would really turn it into a network application... and probably more than it's worth.

Another solution, would be for BungeeMail to just periodically check for new mail for each online player. I'm not certain how notifications are currently handled, but I believe BungeeMail keeps track of who has new mail internally. If I'm right, then the db would need to be modified to have a new entry for that. But, if I'm wrong, and notifications are stored in the DB, then it should be pretty simple to add a (configurable) update time for checking mails.

The last solution I came up with, which I think is the most elegant, but would take a bit more work.
First, if the recipient is on the same proxy as the sender, then the internal notification system (as currently implimented) would be used. No point in doing anything else. However, if the user is not on the same proxy, then, the instance of BungeeMail could use the MySQL DB to send out a "Hey! Is Name online?" This could be done with a table which is updated when ever new mail does not have a local receiver. BungeeMail would then be set to look for these entries in the DB by name. So, each instance would be required to have it's own name set in the config. When the receiving instance sees that there's an entry from one of it's configured look-for servers, it reads it and attempts to notify the user.

The simplest method, would be to use MySQL Triggers - if that's possible. I'm not sure it's something a plugin can do, and may need to be done by the DB admin. I'm neither a programmer nor a DBA. I found this: https://www.techonthenet.com/mysql/triggers/after_insert.php

TL;DR: I'd like for both instances of BungeeMail to be able to notify users of new mail when received from the other instance. Web sockets, periodic checks of online users, periodic checks of database, or possible db trigger push notifications to the BungeeMail instance. I'm not sure there's any other solution.

I'd love for this to be implemented, in one way or another. I was unable to confirm where/how new mail notifications are stored, and so one of those solutions may be really simple to do, or they may not be easy at all.

[CodeCrafter47]

Hi,

I think a simple and efficient solution would be to use RedisBungee's message API. Of cause this would require you to use RedisBungee, but chances are if you're having multiple proxies you're already using it. An alternative would be to use Redis directly, however that's more work to implement (still quite simple, though) and will require more configuration work from the user.

Using RedisBungee would be my preferred solution. If that works out for you I can look into implementing it.

[AeSix]

No, I'm not using Redis.

I was a bit drunk last night when I wrote this. Honestly don't remember my train of thought lol.

Our network uses 1 bungee proxy for our production servers. I have HAProxy on several VPSs throughout the globe, acting as regional pops, which the players are all redirected to the same bungee. I have the occasional downtime because of that, but it works well enough for us.

The second Bungee is for our testing and demo servers, basically a completely separate network. I'd like for staff to be able to communicate quickly and easily, but honestly only because of my accidental "discovery" with BungeeMail.

Would it be possible for BungeeMail to just periodically check for mail for online users?
I see there's already a few instances when users can be notified - on join, on server change and on new mail. Obviously, the sender's process is what triggers the recipients notification, I'm just not sure how that's done. If it's all kept local to the BungeeMail process, then there's no real way for the other process to know, even if periodical checking of the db, that there's new mail... unless the database and pounded on every 10 seconds for each user... not a great scenario.

SO I feel like the easiest solution, without modification to the SQL schema, or the installed applications would be to websocket the BungeeMail instances, or to abuse MySQL like LuckPerms does for notifications... and I have no idea how much code that would take.

With that said... I'm redacting my request.

However, I would totally support any movement working towards any of the above solutions, including the RedisBungee. Redis may actually be the best thing for the project, as it would allow for those larger servers who are utilizing Redis to easily utilize BungeeMail for their servers. I'd like to see some method of achieving cross network mail, but I'm not going to install Redis. Too many other things I've got to get done before years' end :)

Anyways, Thank you very much for responding, and good luck with which ever route you take!
I'm going to leave this open, in case you want to progress with it. If you don't, closing it won't hurt my feelings 👍