SModerations

Moderation should be more than /ban

Most moderation systems stop at commands.

SModerations is designed around the entire moderation workflow.

A report comes in. A staff member reviews the player. Their history, activity, notes and related accounts are available from the same interface. The report can become a case. Evidence can be attached. A punishment can be issued using predefined reasons and automatic escalation. Everything important remains auditable afterwards.

You can still use traditional commands whenever you want — the GUI is there to make moderation faster, clearer and more consistent, not to replace flexibility.




A real moderation dashboard

Open /sm and access the moderation system from a single interface.

Browse online players, search for offline players, inspect moderation profiles, issue punishments, review reports, manage investigations, inspect staff activity, access the watchlist and open diagnostics without memorizing dozens of workflows.

Every submenu follows a consistent navigation design, while controls automatically respect staff permissions.


Everything you need to investigate a player

A player profile is more than a punishment count.

SModerations brings together first join, last seen, total playtime, moderation statistics, punishment history, active punishments, staff notes, reports, related accounts and other investigation tools.

Instead of jumping between plugins and commands, staff can build context before making a decision.



Fast, consistent punishments

SModerations supports permanent and temporary bans, IP bans, permanent and temporary mutes, warnings and kicks.

Punishments can be global or server-scoped, silent or public, linked to investigation cases and later reviewed from their detailed history.

Staff can use configurable reason presets, custom reasons, duration presets or custom durations.

But predefined reasons can do much more than save typing.


Smart escalation

Configured offences can automatically escalate based on previous violations.

A first offence may result in a temporary punishment. Repeated offences can increase the duration or eventually become permanent according to your configuration.

Staff see the resulting punishment before confirmation, keeping the workflow predictable while helping your team apply rules consistently.


Reports that actually lead somewhere

Player reports are stored as moderation tickets instead of disappearing into chat.

Reports contain the reporter, target, reason, priority and status. Staff can claim reports, inspect the reported player, resolve or dismiss them, or turn them into a deeper investigation.

Archived reports remain available for later review.


Cases & evidence

Complex situations deserve more than a single punishment entry.

Cases act as investigation files. A case can be created independently or from a report and can contain multiple linked reports, evidence and punishments.

Evidence URLs are validated and stored with the investigation while the server never fetches those URLs itself.

Once a case is closed, it becomes a read-only archive. Old GUI sessions cannot be used to silently modify a closed investigation because sensitive actions are validated again by the backend.



Staff notes & watchlist

Keep useful context attached to players without immediately punishing them.

Staff notes can be classified as information, warning, suspicion or important. Players can also be placed on the watchlist so staff can be alerted when someone requiring attention joins the server.

This gives your moderation team memory that survives restarts and staff changes.


Related-account investigation

SModerations can correlate known player addresses to help staff investigate related accounts.

Raw IP handling is treated as sensitive information. Stored addresses can be protected using AES-GCM encryption while separate HMAC-derived data is used for correlation.

IP display can be masked and access to raw addresses can be placed behind separate permissions.

The goal is simple: give trusted staff the tools they need without treating sensitive player information casually.


Staff Mode

Moderators can enter a dedicated staff mode with tools designed for active moderation.

Inspect players, access reports, freeze players, toggle vanish and quickly open moderation interfaces from an isolated staff inventory.

Staff inventory state is protected with recovery mechanisms so an unexpected disconnect or restart does not have to mean losing the player's original inventory.


Freeze, Vanish & Staff Chat

Essential staff utilities are included directly in SModerations.

Freeze suspicious players during investigations, vanish while observing gameplay and communicate privately through staff chat without requiring separate moderation utility plugins.


Built for staff teams

SModerations can discover staff through LuckPerms and provide a dedicated staff directory.

Moderation statistics include daily, weekly and monthly active moderation playtime together with moderator Ban, Mute, Warn and Kick history, handled reports and created cases.

This makes it easier to understand staff activity without reducing moderation performance to a single meaningless number.



Security is part of the architecture

A moderation plugin controls some of the most powerful actions on your server. SModerations is therefore designed around defense in depth rather than trusting the GUI or a single permission check.

Sensitive actions are revalidated by backend services when they are executed.

Permission checks, hierarchy protection, operator protection, punishment duration limits, per-action rate limits, mass-punishment protection, fail-closed storage behavior, prepared SQL statements, audit records and bounded temporary-duration parsing are built into the moderation flow.

Player-controlled formatting values are escaped before MiniMessage parsing. Evidence URLs are parsed without being fetched by the server. Discord webhook destinations are restricted. Sensitive local files receive additional permission hardening where the operating system supports it.

SModerations does not include a custom self-updater, arbitrary remote JAR loader or executable download mechanism. Large runtime database libraries are declared through the server's standard library loader and may be resolved from Maven Central when the plugin is first started.

No moderation system can promise that vulnerabilities will never exist. SModerations instead aims to reduce attack surface and fail safely when critical infrastructure becomes unavailable.


Hierarchy protection

When LuckPerms is available, group weights can be used to prevent staff from moderating players at or above their authority level.

Permissions are still handled through Bukkit, so LuckPerms remains an optional integration rather than a hard requirement.


Fail-closed storage

Critical moderation actions should not silently split your server state when a database fails.

If an explicitly configured external database cannot initialize, SModerations does not quietly create a separate SQLite moderation database and continue as though nothing happened.

Database-backed moderation remains unavailable until the problem is fixed.


SQLite, MySQL & MariaDB

A single server can start immediately with SQLite and requires no external database server.

Larger setups can use MySQL or MariaDB.

Multiple Bukkit, Spigot or Paper servers can share moderation state through the same external database while using distinct server IDs, allowing global and server-specific punishments across the network.

SQLite installations also support rotating scheduled backups.



Chat moderation included

SModerations can enforce active mutes while also providing configurable protection against spam, repeated messages, excessive caps, IPv4 advertising and domain advertising.

A configurable domain allowlist is available, and muted players can be prevented from using selected commands.

Mute feedback can be displayed through chat, action bars, titles or boss bars depending on your server design.


Discord integration

Punishment and punishment-revocation events can be sent as structured Discord webhook embeds.

Webhook delivery is HTTPS-only and destination validation is intentionally restrictive rather than allowing arbitrary server-side requests.


PlaceholderAPI

PlaceholderAPI is optional.

SModerations exposes placeholders for player warnings, active warnings, bans, mutes, reports, cases, notes and punishment statistics together with network-wide active punishment/report counters.

External PlaceholderAPI values can also be used inside SModerations messages when enabled.


Fully configurable presentation

Player-facing messages, staff messages, GUI names, GUI lore, punishment screens, prompts, labels and statuses are language-file driven.

GUI materials, structure and slot placement are configurable separately.

The formatting pipeline supports MiniMessage, gradients, hex colors and traditional Minecraft color formats while escaping player-provided replacements before they reach MiniMessage.


Included languages

English — en_US
Hungarian — hu_HU



Commands when you want them. GUI when you don't.

Traditional moderation commands remain available, including /ban, /tempban, /banip, /unban, /unbanip, /mute, /tempmute, /unmute, /warn, /unwarn, /kick, /history, /checkban, /checkmute, /report, /case, /note, /freeze, /staff, /mod and /sc.

Standalone moderation commands can also be accessed through the /sm command tree while using the same backend authorization checks.


Designed for modern Minecraft servers

Minecraft: 1.21.x
Java: 21
Server software: Bukkit / Spigot / Paper
Default storage: SQLite
External storage: MySQL / MariaDB
Optional integrations: LuckPerms / PlaceholderAPI / Discord webhook


Installation

Place the SModerations JAR inside your server's plugins directory and restart the server.

On first startup, the server may download the declared runtime database libraries from Maven Central through its standard library loader. Make sure the server has internet access during this initial dependency resolution.

SQLite works out of the box for a single-server installation.

For a shared network setup, configure MySQL or MariaDB and give each server a distinct server ID.

Review permissions and configuration before giving the plugin to production staff.