Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moderation tools #425

Open
TheDevMinerTV opened this issue May 13, 2024 · 7 comments
Open

Moderation tools #425

TheDevMinerTV opened this issue May 13, 2024 · 7 comments
Labels
help wanted 🫂 Extra attention is needed

Comments

@TheDevMinerTV
Copy link

TheDevMinerTV commented May 13, 2024

Be it IP bans or user bans, these will be useful during the event.

[edited by Andrew]

@andrewgazelka
Copy link
Collaborator

yea definitely want this 👍

@andrewgazelka andrewgazelka added the help wanted 🫂 Extra attention is needed label Nov 3, 2024
@andrewgazelka
Copy link
Collaborator

andrewgazelka commented Nov 3, 2024

want potentially use LMDB for this

https://github.com/andrewgazelka/hyperion/blob/7540e89e92b4ce38ff4249f7fe4b9ea5d87e1319/crates/hyperion/src/storage/db.rs#L14-L17

see

https://github.com/andrewgazelka/hyperion/blob/7540e89e92b4ce38ff4249f7fe4b9ea5d87e1319/crates/hyperion-permission/src/storage.rs#L8-L52

can also use rkyv potentially

could also use something like

https://github.com/nats-io/nats.rs

with jetstream? cause we might want people to be able to ban people even if cannot execute commands 🤷


in general worth talking about

@Kumpelinus
Copy link
Collaborator

I would want to implement this one next. While we already do have a permission storage via heed already I'd prefer not handling "Banned" as a permission. Doing that could make it harder to implement punishments for people that quit before they got their punishment and are thus offline. Also, would muted be it's own group then? That would disable users of hyperion to give muted people any kind of permissions.

@andrewgazelka
Copy link
Collaborator

I would want to implement this one next. While we already do have a permission storage via heed already I'd prefer not handling "Banned" as a permission. Doing that could make it harder to implement punishments for people that quit before they got their punishment and are thus offline. Also, would muted be it's own group then? That would disable users of hyperion to give muted people any kind of permissions.

could always handle them as

const MUTED: u8 = 0b1
const PLAYER: u8 =  0b10

so

const MUTED_AND_PLAYER = MUTED | PLAYER

Doing that could make it harder to implement punishments for people that quit before they got their punishment and are thus offline.

really good catch... I suppose it could just modify the database if the player is not currently on the server. Probably want to cache all Name -> UUID somewhere too so don't have to make an API call.

@Kumpelinus
Copy link
Collaborator

I do have a few additional questions:

  • IP Bans: How should IP bans be handled? Would we store the connection Player -> IP, or would IP bans only apply to currently online players?
  • Data Persistence: How long would this data (e.g., Player -> IP or Player -> UUID) be stored? Would it be in memory and cleared on restart, as I’d assume, or something more persistent?
  • Banning/Muting Players Who Never Joined: Should it be possible to ban/mute players who’ve never joined the server? If yes, we'd still need Mojang API calls to resolve their UUID. While caching could help minimize these calls, it wouldn't get rid of those API calls entirely.
  • Layer of Enforcement: Where should bans and IP bans be enforced — on the proxy or the game server? I’d assume the game server. While handling bans at the proxy level might reduce server load, doing so would require additional logic to sync data. And does the proxy even have built-in data persistence?

@andrewgazelka
Copy link
Collaborator

Would we store the connection Player -> IP, or would IP bans only apply to currently online players?

kinda confused what you mean here

How long would this data (e.g., Player -> IP or Player -> UUID) be stored?

indefinitely just like how permissions are stored. should persist in case the server crashes

Banning/Muting Players Who Never Joined: Should it be possible to ban/mute players who’ve never joined the server? I

yes
also see https://github.com/andrewgazelka/hyperion/blob/4bd6b4c4fef4f019e07cde288bc40dfc8ac08639/crates/hyperion/src/common/util/mojang.rs#L64-L68

Layer of Enforcement

game server for now; it is easier....

.....

also just a thought

will likely be using velocity on top of main proxy so we can have viaversion. might be able to just use a velocity plugin (perhaps there is a velocity redis ban plugin?) 🤷

@Kumpelinus
Copy link
Collaborator

Would we store the connection Player -> IP, or would IP bans only apply to currently online players?

kinda confused what you mean here

I meant that if you were to issue the Command /ip-ban FooUser, it has to find out that user's IP-address (to properly block it). Should that command work for offline users as well? If so, we would need to store the user's last IP address, no?

How long would this data (e.g., Player -> IP or Player -> UUID) be stored?

indefinitely just like how permissions are stored. should persist in case the server crashes

I was only mentioning this part because of the User -> IP address mapping. Because I doubt it would be a great idea to store every user's last IP address forever. Maybe we could hash their IP and then store it across restarts?

also just a thought

will likely be using velocity on top of main proxy so we can have viaversion. might be able to just use a velocity plugin (perhaps there is a velocity redis ban plugin?) 🤷

Sounds good. I know only a few that support mysql / mariadb / postgresql. Might want to look into that again though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted 🫂 Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants