MESTER

MESTER (Minecraft Extension System for Transporting Engine Resources) is a versioned protocol for transporting resource packs and engine resources over an existing Minecraft connection.

This repository contains the shared protocol library and its Fabric implementation. The AdvancedSlimePaper implementation is maintained as a Git submodule.

Project structure

• protocol-core — platform-independent Kotlin wire models, codecs, validation, capability negotiation, and transfer primitives.
• mester-api — minimal platform-independent API for inspecting negotiated clients and capabilities.
• fabric — combined Minecraft 26.2 Fabric client and server mod.
• server — Minecraft 26.2 AdvancedSlimePaper server implementation, tracked as a separate repository.
• showcase-plugin — example Paper plugin that sends a required resource pack using RoM.
• docs/specs — MESTER V1 design and wire-format specifications.q

Features

The current implementations provide:

• configuration-phase client/server handshakes;
• independently versioned capability negotiation;
• /mester client diagnostics and /mesters server diagnostics;
• a flow-controlled binary transfer layer with SHA-256 integrity verification;
• Resource-over-Minecraft (RoM) for delivering ordinary Minecraft resource-pack ZIPs without an external HTTP server;
• safe, configurable server repositories rooted beneath rom-root;
• optional enforcement of MESTER support and administrator-selected required capabilities;
• a public API for detecting compatible players and reading their exact negotiated capabilities;
• temporary-file streaming and content-addressed client caching;
• integration with Minecraft's normal resource-pack prompt, verification, reload, and status flow.

MESTER V1 also specifies future asset streaming, baked regions, versioned meshes, materials, PNG textures, and streamed-region lifecycle messages. Implementations advertise a capability only when it is usable on that platform.

Requirements

• JDK 25
• Minecraft 26.2
• Git with submodule support when building the AdvancedSlimePaper implementation

Building

Clone the repository and its server submodule:

git clone --recurse-submodules https://github.com/MesterMan03/MESTER.git
cd MESTER

Build and test all first-party Gradle modules from the repository root:

./gradlew build

Useful development tasks:

./gradlew :fabric:runClient
./gradlew :fabric:runServer
./gradlew :protocol-core:test
./gradlew :showcase-plugin:build

The AdvancedSlimePaper submodule is an independent Gradle build. Publish the shared protocol artifact before building it:

./gradlew publishMesterToMavenLocal
cd server
./gradlew -PmesterVersion=0.1.0 applyAllPatches
./gradlew -PmesterVersion=0.1.0 :aspaper-server:classes

On Windows, use gradlew.bat in place of ./gradlew.

Commands

The distinct roots prevent the client-local command from shadowing the connected server's command.

• Client: /mester version, /mester server
• Server: /mesters version, /mesters client <name>

RoM configuration

Both server implementations create config/mester.yml. Its rom-root value is relative to the server root and defaults to:

rom-root: mester/rom
reject-non-mester-clients: false
required-capabilities:
  - mester-core/1

Set reject-non-mester-clients to true to disconnect clients that do not complete the MESTER handshake. Every entry in required-capabilities uses name/version syntax, must be implemented by the server, and must be negotiated by participating MESTER clients. With rejection disabled, ordinary clients may join; a client that attempts MESTER negotiation must still satisfy the configured capability list.

With the default setting, rom://resource-pack/showcase.zip resolves to mester/rom/resource-pack/showcase.zip. Repository paths are normalized and checked against traversal and symbolic-link escapes.

The showcase plugin's resource-pack SHA-1 is an example value and must be updated to match the ZIP being served.

Plugin API and packages

Server plugins can compile against info.mester:mester-api and query a player by UUID:

import info.mester.mester.api.MesterApi
import info.mester.mester.protocol.MesterProtocol

val client = MesterApi.get().client(player.uniqueId)
if (client != null && client.supports(MesterProtocol.ROM_V1)) {
    // The player negotiated RoM v1.
}

val resourcePack = MesterApi.get().romRoot().resolve("resource-pack/my-pack.zip")

romRoot() returns the canonical java.io.File for the server's configured RoM repository, allowing plugins to store generated resources without hard-coding mester/rom.

The API and protocol artifacts are published to Maven Central as:

• info.mester:mester-api:<version>
• info.mester:mester-protocol-core:<version>

Consumers only need mavenCentral(); downloading a release does not require credentials. Use ./gradlew publishMesterToMavenLocal for local development. ./gradlew publishMesterPackages signs, uploads, validates, and releases both artifacts through the Maven Central Portal.

Versioning and automation

The project version has a single source of truth in the root gradle.properties file:

mester_version=0.1.0

The Build workflow compiles and tests the root modules, publishes the shared artifacts to Maven Local for the independent server build, applies the AdvancedSlimePaper patch stack, and compiles the server implementation.

When mester_version changes on main, the Maven Central publishing workflow builds the project and publishes mester-api and mester-protocol-core. It can also be started manually from GitHub Actions; a manual run publishes the current version even when the property did not change in that commit.

The workflow expects the repository secrets MAVEN_CENTRAL_USERNAME, MAVEN_CENTRAL_PASSWORD, SIGNING_KEY, and SIGNING_PASSWORD. The first two are Central Portal user-token credentials; SIGNING_KEY is the ASCII-armored private GPG key.

License

MESTER is available under the MIT License.