Server Consent API

[xpple]

Dear FabricMC 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. Since this system is meant to be universal, I also opened an issue over at Paper for the (server-side) system. The text there is roughly the same, with a few server provider specific exceptions, and of course not including the client-sided aspect specifically for Fabric. Thanks for reading!

Server Consent API

Perhaps a different name would be better.

Summary

This API adds 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
mods 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 server-side implementation as shown by the mod 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. The same applies to the client-side implementation.

Description

This system uses the custom payload channel noconsent:flags to send
the list of mods/features to the client (namespace should be discussed).
The list is a net.minecraft.util.Identifier list with the following design:

• <mod id>:<feature> requests the feature <feature> of the mod with
  mod id <mod id> to be disabled;
• c:<feature> requests the feature <feature> of all mods to be disabled;
• <mod id>:all requests the all the features of the mod with mod id
  <mod id> to be disabled.

The common namespace c is defined by the field
Flags#COMMON_NAMESPACE. The wildcard feature all is defined by
the field Flags#WILDCARD_FEATURE. To aid standardisation, the Flags
class also includes common flags for mod developers to use.

If the server has enabled this system, the server will send the configured
list of mods/features to the client. For now, this list is configured using
JSON. The default config (located at .minecraft/config/fabric/consents.json
is as follows.

{
  "enabled": false,
  "illegalFlags": []
}

An example config might look like this.

{
  "enabled": true,
  "illegalFlags": [
    "c:markers",
    "seedmapper:all"
  ]
}

With this configuration, the server would ask all mods to disable their
markers, and to disable the mod with mod id seedmapper entirely. This
list is parsed by making a simple TypeAdapter<Identifier> provided by
GSON.

When the client receives the list of illegal mods/features, an event will
be triggered by this API to which client mod developers can listen. The
events is ClientFabricServerConsentFlagsCallback.FLAGS_SENT. They can
then check if their mod is included in any way in the list by using the
ClientFabricServerConsent#isIllegal method:

/**
 * Checks for a given flag and mod id whether the flag is illegal.
 *
 * @param flag the flag to check against
 * @return {@code true} if the flag is illegal, {@code false} otherwise
 */
public static boolean isIllegal(Identifier flag) {
	for (Identifier illegalFlag : ClientFabricServerConsentImpl.illegalFlags) {
		if (illegalFlag.getNamespace().equals(Flags.COMMON_NAMESPACE)) {
			if (illegalFlag.getPath().equals(flag.getPath())) {
				return true;
			}
		}

		if (illegalFlag.getNamespace().equals(flag.getNamespace())) {
			if (illegalFlag.getPath().equals(Flags.WILDCARD_FEATURE)) {
				return true;
			}

			if (illegalFlag.getPath().equals(flag.getPath())) {
				return true;
			}
		}
	}

	return false;
}

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 mod (in the
  case of a Fabric server) could be used by server owners. However,
  there is very little chance a third party mod 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.

[xpple]

It has become clear that the client sending a list of their mods to the server is a bad idea. I will rewrite the code and PR description accordingly later.

[modmuss50]

This is going to need a lot of work before its ready, I have left a very high level review based on discussion.

[AnOpenSauceDev]

I like the idea of this, but I doubt that this will have a major effect in the end, at least on the side of hacked clients where someone could easily just maintain a fork that ignores the API. After all, most major hacked clients don't even bother to check if the server is anarchy or not. In my opinion it's just too much work for something that probably wont be used often or can easily be bypassed.

[xpple]

I like the idea of this, but I doubt that this will have a major effect in the end, at least on the side of hacked clients where someone could easily just maintain a fork that ignores the API. After all, most major hacked clients don't even bother to check if the server is anarchy or not. In my opinion it's just too much work for something that probably wont be used often or can easily be bypassed.

It's up to the developer to adopt this system or not. And yes, it can be easily bypassed. It's an explicit Non-Goal to provide some robust anti-cheat system. This is for client mod developers that want their mod to be used more responsibly.

[gudenau]

This would be trivial to bypass as the stated goal is to disabled cheats on servers any "client" could just disable this check. Even mods that use this could have the checks disabled.

[AnOpenSauceDev]

This would be trivial to bypass as the stated goal is to disabled cheats on servers any "client" could just disable this check. Even mods that use this could have the checks disabled.

I will say, it would totally be possible for someone to make a mod* that consists of a few mixins, that bypasses the check for all mods, which would mean that compliant mod devs would still have their mods misused. It kind of sucks that there isn't a good way to do with without a) being some level of invasive or b) obfuscating code.

*modrinth does not allow these forms of mods, but GitHub and Curseforge could possibly distribute this.