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.