What it connects to
The things it talks to, and the things it does not
Three integrations exist and are in use. Each one below says what it does, and then the thing you would otherwise discover in week two — because an integrations page that only lists the good half is how somebody ends up rebuilding their community around an assumption.
Everything here is configured on your own deployment, against services you already run or already have an account with. Nothing routes through us; there is no us to route through.
Discord
A bot for the server your community is already sitting in, doing three separate jobs.
Slash commands
Commands registered with your guild that answer from your site — so the thing somebody wants to look up is available where the conversation is happening, rather than one tab away.
Notifications into channels
News and Team activity bridged into the channels you choose, with a per-Team override so one group can route its own notifications somewhere else. Delivery is best-effort and one-shot: a Discord outage never backs anything up on your site.
A voice channel per Team
A Team can be granted its own voice channel, with membership maintained by the bot rather than by whoever is online. The bot creates the category, and the panel reports how many roles your guild has left before Discord’s own limit.
Worth knowing first
Voice access is granted with a Discord role, and roles are visible on a member’s profile — so a Team with a voice channel is a Team anyone in your guild can see the membership of. That was a deliberate trade for a limit that counts per guild rather than per channel, and it is the right one for most communities, but it is not private.
Mobile and push
A native Android app against the same documented API the website uses, with push through a server you run.
The same API, not a second one
The app is a client of the API your deployment already publishes, authenticated with short-lived tokens and rotated, revocable refresh tokens. There is no mobile-only backend to keep in step.
Push through your own ntfy
Notifications are delivered by a self-hosted ntfy server rather than a vendor in the middle. Each person chooses which streams reach them; push arrives by default and can be switched off entirely.
Trusted devices and two-factor
The app shares the site’s account model, including time-based two-factor codes, recovery codes, and devices you can mark as trusted and revoke later.
Worth knowing first
The app points at no server of ours: the person installing it types the address of the deployment they belong to. That is what makes one app work for every community running this software, and it means the app is useless until somebody gives them a URL — which is a thing worth putting in your welcome message.
Single sign-on
OAuth2 and OIDC, against Google, Discord, or any provider you already run.
Any OIDC provider
Google and Discord are configured by name; anything else that speaks OIDC is configured generically. Client secrets are encrypted at rest and never returned to any client.
It signs people in, not up
An external identity has to be linked to an account that already exists on your site. Signing in with a provider never creates a user — which means the way someone joins your community stays a decision you make, not one Google makes.
It respects the rest of the login rules
Two-factor, trusted devices and bans all still apply. An identity provider proves who someone is; it does not decide whether they may come in.
Worth knowing first
Link-only is a policy, not a limitation to be worked around. If you were expecting to open registration by turning on Google sign-in, this will not do that, and it is not configurable.
Email, deliberately quiet
Your deployment can send email — Team notifications and newsletters, through an account you connect — and it only ever sends to someone who asked for it. Email is the one channel that is opt-in rather than opt-out, because an unwanted push notification is an annoyance and an unwanted email is a complaint to somebody’s provider.
This website is a separate matter: runicgateway.com sends no email at all, has no mailbox behind it and no account to make. The address in the footer is a human being.
Not built
Integrations that do not exist
Every one of these is a decision rather than a backlog item, so each says why. Where the reasoning was written down in the open, it is linked.
Matrix
Researched properly and then declined. Matrix has no channel-with-overwrites, no role object, no voice channel of its own — voice is an RTC session needing a media server the homeserver does not ship — and no way to register a slash command. Of the five things a shared chat interface would have to name, an honest Matrix implementation could provide two. What came out of that work was a capability contract rather than an integration.
What would change itNothing planned. If the protocol grows the missing four, the contract is already the shape a second platform would plug into.
More than one game module at a time
One active module per deployment. The database columns that would scope data to a module exist and are populated, so the door is not nailed shut, but nothing exercises them and no interface offers it. A community running two games runs two deployments.
What would change itSomeone needing it. The schema was shaped to keep it possible, which is a different thing from planning it.
A second game module
There is exactly one, and it is Ultima Online. A paper dry-run for a Rust module exists and is deliberately unimplemented — it was written to test whether the module contract generalises, not to ship. Until a second one exists, "any game" is an argument about a shape rather than a demonstration.
What would change itThe first module built for a game that is not Ultima Online.
A finished Integration Kit
The kit that teaches you to put a different game on this platform describes itself as a draft, and it is right to. It has four chapters, a working template and a CI job that builds that template against a pinned core — but nobody outside this project has yet followed it to a working module, which is the only test of a set of instructions that counts.
What would change itSomeone outside this project building a working module for a new game by following it alone. That is the kit's own stated condition, not one invented here.
If you need another one
The API is the integration point
The whole backend is described by an OpenAPI 3.0 specification that ships with the server, and an installed module merges its own routes into it — so whatever you build against is documented by the thing that is actually running, at Module API 1.10.0. The bridge to a game server is a documented wire protocol on the same principle, currently protocol 7.