Build on it
Server plugins
JavaScript that runs inside a Gryt server. It hears about things as they happen, it can kick and ban and delete, and it runs with everything the server has.
That last part is the whole story, so it comes first. Installing a plugin is running somebody else’s code on your machine, with your database. It can read your files, open connections, and do anything the server process can do. The capability list in a manifest is a plugin telling you what it means to do. It is not a wall around it.
{
"id": "presence",
"name": "Presence",
"version": "1.0.0",
"main": "index.mjs",
"author": "you",
"description": "Shows what people are playing",
"capabilities": ["messaging", "members:read"]
}There’s no sandbox and no plan for one that would still be useful. Install plugins you’d trust the author with, and read the code if you can. If that sounds like too much, you probably want a bot instead — it talks to your server over the network like any other client, sees only what you let it into, and can be turned off without touching the server.
Everybody who joins is told which plugins you run and what each one may do. That can’t be turned off. A plugin reading people’s messages is something the people sending them get to know about — and it is how the client half of a pair finds out the server runs the other half.
- Two plugins to copyOne that deletes the same message posted across three channels, and the server half of a pair.
- Writing a server pluginWhat a plugin can hear, what it can do about it, and why installing one is a bigger decision than a theme.
- Server plugin API referenceEvery capability, event and call, generated from the source so it cannot drift.
- Plugin pairsThe pipe between a server plugin and the copy of itself in people's clients.