Permissions
Every permission Conduit checks in-game — what it gates and who should hold it. These are
LuckPerms nodes like any other; grant them to groups on the panel's /permissions page.
Wildcards work (conduit.*), but the point of this list is that you don't have to use them.
Who may edit them from the panel, and how the page works across joined clusters, is at the
end.
Operator / staff#
| Permission | Gates | Give to |
|---|---|---|
conduit.admin | /conduit ops subcommands (restart, scale, broadcast — the panel action queue from in-game) and the admin surfaces of connector commands | owners, senior admins |
conduit.serverstatus | Seeing the ⌞SD⌝ chat line when any server goes offline or comes back — the old live network's status feed, now driven by the uptime monitor | staff |
conduit.networkswitch.info | Seeing network join/leave announcements (⌞SD⌝ ᐅ <player> has joined the network) | staff, or everyone if you like the noise |
conduit.msg.spy | Reading other players' private messages (social spy) | moderators and up |
conduit.kick | The connector's kick command | moderators and up |
conduit.vanish.see | Seeing vanished staff in tab and in the world | staff |
conduit.maintenance.bypass | Joining through group maintenance mode. The per-group form conduit.maintenance.bypass.<group> scopes it to one group | staff |
conduit.gui | Opening connector-managed GUIs' administrative views | staff |
Builders / creators#
| Permission | Gates | Give to |
|---|---|---|
conduit.wand | The in-game region wand — drawing panel regions (portals, zones) by clicking corners instead of reading F3 | builders, admins |
conduit.map | Map Studio: /conduit map create/add/set/scan/bounds/upload — authoring game maps in-game | map builders |
Players (grant broadly where wanted)#
| Permission | Gates | Give to |
|---|---|---|
conduit.color | Legacy & color codes in chat | ranks that may color chat |
conduit.color.hex | Hex colors (<#RRGGBB>) in chat | higher ranks |
conduit.queue.priority | Skipping ahead in full-server join queues | supporters/premium |
conduit.full.bypass | Joining a full server outright | staff, top supporters |
conduit.game | Entering game servers through the connector's routing where a gate is configured | everyone, unless a game is restricted |
Sharding (the Elastic World)#
The owning-strip gate denies block changes outside the strip a server owns; the bypass for staff
work across strip borders rides conduit.admin. Regular players never need a node for sharding —
crossing the seam is not permission-gated.
Notes#
- Announcement visibility permissions (
conduit.serverstatus,conduit.networkswitch.info) gate seeing a message, not sending anything. An empty permission on a message template means everyone sees it — these two are deliberately not empty. - The panel's own roles (admin / operator / developer / viewer) are separate from these in-game nodes; they live in the panel's user management and gate the web UI and API, not chat or commands.
Editing permissions from the panel#
The capability. Reading /api/luckperms/* needs players.view; writing needs
players.permissions (lib/route-permissions.ts). The one exception is POST /api/luckperms/install, which installs the plugin on every Paper and Velocity server and restarts
each one: that is a rollout of the platform's own stack, so it asks for platform.install.
Only an unscoped account may write. LuckPerms groups, tracks and player nodes are one set for
the whole network: a node added to default applies on every server, and a scope of "the
minigames group" has no meaning against it. The capability gate and the per-server scope gate both
let a scoped account through, so every LuckPerms write route runs unscopedGate
(lib/rbac.ts) first. An account scoped to particular groups or servers is refused with 403 permissions are network-wide; an account scoped to particular servers cannot edit them. Reads are
not gated this way. The machine token passes, as it does everywhere.
One page, every cluster. LuckPerms' tables live in each cluster's own PostgreSQL, which only
that cluster's panel can reach, and every write is followed by lp networksync on one of that
cluster's servers. So /permissions has a cluster switch: this cluster, then each joined
cluster by name. Choosing one sends every request with ?estate=<cluster id> and the route
forwards it to that cluster's panel through the relay (relayIfEstate), which runs it there as
the person who asked. This side refuses a scoped account and the machine token before anything
is sent; the far panel re-checks players.permissions against its own roles and audits the write
under the person's name with the asking cluster in the detail. Switching cluster empties the
selection and the roster, because they were the other cluster's. Two things are not relayed: the
installer (a restart of every server there is that cluster's decision) and
/api/luckperms/effective, which is the connector's own lookup. The live server list for a
foreign cluster is polled through its panel, so a cluster whose panel does not answer shows as not
reachable rather than as a stale roster.
Panel roles#
The web roles are capability sets (security.md). One rule matters
when you edit them: you cannot grant what you do not hold. A role editor may only put into a
role capabilities their own role, extras and denies expand to, checked on what a grant expands to
rather than on its name, so servers.* is refused for an editor holding only servers.view. The
refusal names the capabilities: cannot grant what you do not hold: servers.jvm. An admin holds
* and is never limited; denies are not checked, since taking a capability away needs no
standing to hold it. A role is edited on the cluster that keeps it, and a role in use on any
joined cluster cannot be deleted.