Repository navigation
Policies and Lists
Use commands or the GUI for routine policy edits. They validate and save changes without hand-editing JSON.
In normal mode:
/modseeker modblacklist add <modId>
/modseeker modblacklist show
/modseeker modblacklist remove <modId>
IDs are normalized to lowercase. They must start with a letter and contain only letters, digits, underscores or hyphens, up to 128 characters. A display name, Modrinth slug and internal mod ID can differ. The GUI resolves published mods to their actual IDs; the command expects the ID directly.
The blacklist also covers declared bundled IDs, including a dependency shared by multiple JARs. The console and seek mod display top-level IDs, so a dependency named in a kick may not appear in that shorter display. Inspect the enclosing mod's metadata or ask its maintainer rather than removing random dependencies.
In advanced mode:
/modseeker modallowlist add <modrinth-link> <mcVersion>
Use a project link such as https://modrinth.com/mod/<project> and the client's Minecraft version. The command resolves hashes for compatible Fabric releases; it can add several versions at once. For a narrower choice, use Versions in the Web GUI, or import only the JARs you intend to approve through the bucket.
Removing with the same project link and Minecraft version removes matching hashes currently resolved for that query. For removal by name, a cached player name takes precedence and removes that player's nonessential hashes. Otherwise the command uses the stored entry label: Modrinth imports use the project slug, while bucket and player imports use the reported mod ID. Those names can differ. Check the resulting list after either action.
- Copy the intended JARs directly into
plugins/ModSeeker/bucket/. - Run the operation for your selected mode:
/modseeker modblacklist add bucket
/modseeker modallowlist add bucket
The blacklist operation reads mod IDs; the allowlist operation computes SHA-512 file hashes. They are alternatives, not two commands you need to run together.
To remove entries represented by those files:
/modseeker modblacklist remove bucket
/modseeker modallowlist remove bucket
The bucket scans regular .jar files in that directory only. It does not recurse into subfolders or follow symlinks. A batch allows up to 256 JARs and 1 GiB total; the inspector also limits individual files to 256 MiB. Read the summary and any per-file errors: some entries can be skipped. Only one bucket operation runs at a time.
Bucket JARs are inputs, not server plugins. ModSeeker does not delete them after import. Remove them from the bucket yourself when the task is finished.
Use a known, reviewed client in advanced mode. It must connect far enough to submit a valid report; a policy rejection can still leave a usable cache.
/modseeker modallowlist add <player>
Inspect every listed ID and hash. If they are the files you intend to allow, repeat the printed command with its review key:
/modseeker modallowlist add <player> <reviewKey>
A new report changes that key. The cache proves which report was received, not that every file in it deserves approval. Do not import an unknown player's whole report just to clear a rejection.
The import can use a valid cached report after the player disconnects. The separate seek mod command requires the player online.
The advanced-mode refresh manages Hidder and Fabric API hashes for the server's Minecraft version. Entries marked essential are protected from ordinary removals. A fetch failure is logged and does not authorize new files automatically.
For a client patch different from the server's, a custom Hidder build, or an unpublished local file, check the exact hashes you need instead of assuming the essential refresh covered them. A reviewed bucket or player-report import can add those files.
Use Commands and Permissions for the add, remove and show commands. Entries are UUID-bound and skip both launcher and mod checks. This list does not replace Minecraft's own server whitelist.
Behind a proxy, use the identity the backend actually receives after proper authentication and forwarding. A name-only lookup on an offline-mode backend can otherwise resolve an offline UUID rather than the intended forwarded player.
Paths below are relative to plugins/ModSeeker/:
| Path | Contents |
|---|---|
config.yml |
Verification, display, messages, GUI and integration settings. |
client-list.yml |
Launcher IDs, display names and allowed flags. |
data/modblacklist.json |
Blocked IDs. |
data/modallowlist.json |
Approved hashes and their labels. |
data/whitelist.json |
UUID-bound verification bypasses. |
data/seek_cache.json |
Recent player reports used by seek and imports. |
data/gui_modid_cache.json |
Cached Modrinth-to-mod-ID metadata. |
bucket/ |
Local JAR inputs for bulk operations. |
keys/server_private.key, keys/server_public.key
|
The server's encryption key pair. |
Back up the complete directory privately while Paper is stopped. If you must repair JSON manually, stop Paper first, retain the damaged copy, restore a known-good file and restart. A failed policy load can deny verification even if a last-good list remains in memory.
The GUI link is printed to the console. Current versions do not create gui-link.txt for it.
ModSeeker
Start Here
Server Administration
- Configuration Reference
- Commands and Permissions
- Verification Modes
- Policies and Lists
- Launcher Verification
- Web GUI
- Floodgate and Bedrock
- Discord Alerts
- Security Overview
Help