[DISCUSSION] Server Consent for Clients

[xpple]

Dear PaperMC development team,

I hereby propose a server consent system for clients. As this is just a proposal, I invite you to share your thoughts on this so that we can come up with something better. Following the discussion I had with some of you, I decided to follow your advice and make a proof of concept plugin first. You can find it here. An example client-side implementation I proposed for Fabric mods can be found here. There you will also find an example client-sided mod using this system. For ease of accessibility I added the "PEP" (Paper Enhancement Proposal) for this feature below. Thanks for reading!

Server Consent for Clients

Perhaps a different name would be better.

Summary

This plugin is a proof of concept for a universal server consent system for mods and features of mods a client connecting to the server uses. The server configures a list of illegal mods/features and, if enabled, will send the client these lists when the client connects to the server. Mod developers can then process this information and if needed disable certain/all functionality. This system is meant to be standardised across different server software implementations, so that clients know what to implement.

Goals

• Standardise a system for client mod developers wanting their mod to be used responsibly. This is the main goal!
• Provide server owners with a system that can ask the client to disable some of its mods or some of its mods' functionalities.

Non-Goals

It is absolutely not a goal to provide server owners with a robust anti-cheat system. This system should not be used in place of anti-cheat plugins and other unfair gameplay preventing plugins/mods. This is not the intention of this system.

Success Metrics

The amount of client-sided mods that will adopt this system. Though, it should be noted that this system will not have failed if some mods don't use this; for servers this system does not have any downsides and any mod using this is therefore a success.

Motivation

Client mod developers are often powerless to prevent their mods from being used on servers which do not allow them/do not allow certain of their functionalities. For instance, many cheat mod developers wouldn't want their mods to be used outside of anarchy servers, but they have no way of preventing it. Others might completely dismiss certain features in fear that they will be used irresponsibly. With this system, client mod developers are no longer limited in this regard, as they can now disable their mod/illegal features on servers that want them to.

The implementation as shown by the plugin is very minimal, and server owners only need to change a config to enable this system. This is beneficial for server owners as it barely requires any effort to configure.

Description

This system uses the following two plugin channels (namespace should be discussed).

• noconsent:mods
• noconsent:features

If the client registers these channels, and the server has enabled this system, the server will send the configured list of mods/features in the corresponding channel to the client. As this is a proof of concept, this plugin uses the config.yml file for the configurations. The implementation in any server software will of course be different. By default, the configuration file is the following (YAML was used as example for clarity).

enabled: false
illegalMods: []
illegalFeatures: []

When the client receives the list of illegal mods/features, an event will be triggered by the mod loader/api to which client mod developers can listen. They can then check if their mod is included in the illegal mods list, or if a feature they provide is included in the illegal features list. It is up to the mod developer to decide what to do with this information.

Alternatives

• The system is standardised by server software providers, but not implemented into them directly. This means that different server software providers would agree on a namespace for the list of illegal mods/features, but let the configuration and implementation be up to server owners to implement. One way this could be achieved is by having server software providers document the system clearly, with example code for server owners. There are two downsides of this approach, though.

  1. The documentation will likely not reach the same audience as direct implementation would. That means fewer server owners will implement use system, which weakens the system as whole.
  2. It is at the expense of standardisation. Direct implementation simply has more of a standardising effect than individual standardisation has.

• This system is not standardised at all. In that case a plugin (in the case of a Paper server) like this one could be used by server owners. However, there is very little chance a third party plugin will be widely adopted by servers. Importantly, standardisation is the main goal of this system. Without it, disagreement and inconsistency would arise, and the system would flop. Only if established server software providers choose to adopt this system will this work.

Considering these two alternatives, only the first could actually work. Third party implementations just don't have the necessary reach to establish something widespread across the Minecraft developer community.

[melluh]

I feel like an approach where the client sends a list of enabled mods/features to the server might be cleaner, because it gives the server knowledge of what the client is using instead of just telling the client 'in case you have this, don't use it!'

This would allow more server-defined behaviour, e.g. deciding between kicking the player, instructing the client to forcibily disable the feature, or just sending them a warning message etc

Additionally, while I agree integrating this into Paper would aid in standardisation, I'm not sure it really fits within the project. Paper has a history of pushing these things more towards plugins, and only integrating them within the server when they have proven useful and well-adopted (e.g. the ongoing integration of spark into the server). Though that's up to the maintainers to decide of course!

[Malfrador]

I fail to see the point of this. This seems like something that should be done as a plugin for server owners who find it useful, but I don't think that something like this should be in Paper. This isn't Purpur.

I also see several issues with this that make it nearly useless, similar to how the client brand is useless.

Cheat mods will simply ignore this system. This is probably obvious.

Mods that can be used for cheating but also for legit uses (minimap entity radars for example) might adopt this system but a player could simply install an additional bypass mod if they want to cheat. If such a system is adopted, a mod for this will exists. Players don't cheat because they accidentally stumbled upon a feature in the mod menu, they cheat because they intent to and installing an additional mod is done quickly.

Mods that can not be used to gain advantage might adopt this system. But as a server owner, I do not care about these mods at all.

This leaves servers that have an additional optional client mod (think Wynncraft with Wynntils, though that unofficial) and want to know if it is installed. For those very niche purposes, a plugin can be used.

I do understand that mod developers might want to ask servers for consent for certain features, but without a way to actually enforce it a system like this is as good as no consent and as such completely useless and just additional maintenance effort for Paper.

Also considering very popular mods like Optifine to this day don't even send the correct client brand, I have major doubts about meaningful adoption for this.

[RacoonDog]

I feel like an approach where the client sends a list of enabled mods/features to the server might be cleaner, because it gives the server knowledge of what the client is using instead of just telling the client 'in case you have this, don't use it!'

There's multiple reasons why I think this approach is flawed.

Firstly, it could create a "client brand" situation where a server has a zero-tolerance policy against modded clients, even disallowing the ones that are required for some people such as sodium, leading to the widespread of bypasses. This would, in the long run, fragilize the system. As someone already stated previously in this thread, even Optifine doesn't send the correct client brand.

Secondly, there's a very real potential for harassment in a case where a player unknowingly gives away information about their usage of mods such as switchy and/or wildfire's female gender mod to a misguided server owner with a toxic community.

This would allow more server-defined behaviour, e.g. deciding between kicking the player, instructing the client to forcibily disable the feature, or just sending them a warning message etc

That's also possible with client side handling, the server just has to send their preferred punishment.

[Mari023]

The point of this is to keep honest people honest

but a player could simply install an additional bypass mod if they want to cheat.

That still raises the bar quite a bit, especially since such a mod wouldn't be allowed on modrinth, and probably also not on curseforge

This would allow more server-defined behaviour, e.g. deciding between kicking the player, instructing the client to forcibily disable the feature, or just sending them a warning message etc

I don't really see the use for this, a feature is either allowed by the server or not, and there is only one reasonable action to do in that case: disabling the feature

[xpple]

I feel like an approach where the client sends a list of enabled mods/features to the server might be cleaner, because it gives the server knowledge of what the client is using instead of just telling the client 'in case you have this, don't use it!'

This would allow more server-defined behaviour, e.g. deciding between kicking the player, instructing the client to forcibily disable the feature, or just sending them a warning message etc

I actually proposed this initially over at Fabric. But the client sending the mod list to the server is just not a good idea I think. I also think many players wouldn't want this to happen. It is kind of privacy concern, after all. Furthermore, the moderation aspect would definitely also be out of scope for Paper.

For the record, I don't think this has to be included in Paper. But a system like this just needs standardisation. Without it, it is completely useless. One way standardisation could also be achieved is by properly documenting it, and then having server owners implement this themselves. This would also work, but it'd probably be less effective than including it in Paper.

Mods that can be used for cheating but also for legit uses (minimap entity radars for example) might adopt this system but a player could simply install an additional bypass mod if they want to cheat. If such a system is adopted, a mod for this will exists. Players don't cheat because they accidentally stumbled upon a feature in the mod menu, they cheat because they intent to and installing an additional mod is done quickly.

Yes, bypass mods will probably exist. Cheaters will cheat, no matter what. This isn't meant to stop that. Thing is, players who want to play fairly, could still unknowingly break the rules. This would also prevent those kind of situations.

[Owen1212055]

As stated before, this is honestly better of to be implemented as an independent project (such as a plugin) rather than Paper.

Plugin messages allow for powerful communication suited just for this, and in general, there isn't much difficulty required to get a plugin to implement this.

In the case that this does become more widespread and mainstream, there's surely a possibility for us to implement this. But for the time being, it's best to leave this to a plugin.

Thank you regardless 😁