The self-hosted communication workspace you program.

A communication workspace you program, and where it is heading

RIM is not a Slack, Discord or Matrix replacement. It is for people who want what those do not offer: a chat workspace they can shape with commands, keybinds, macros and plugins, running on a box they control. The closest relatives are VS Code, Raycast and Obsidian, applied to team communication.

Six things no chat platform offers together

The design, in four layers

Everything a person or a plugin does is a command in one registry. Keybinds, macros, pipelines and the AI agent are all callers of that registry, so adding a plugin command gives every caller a new verb at once.

One binary, two roles

A single server is its own relay and host. A public relay holds accounts and queues; workspaces live on hosts you or your team run.

The desktop app, for the machine you work on

Linux and Windows installers, with signed checksums and signed in-app updates; on macOS you build it from source for now. Point it at your own server or at a relay. The web client needs no download: your server serves it on the same domain.

No release exists yet. The install guide has the downloads and how to verify them, and the steps to build from source on each platform.

Up in ten minutes with Docker Compose

PostgreSQL, the server, the web client and Caddy with TLS on one domain. Backup, restore and a restore drill are scripts in the same folder.

# one server for a team
cp deploy/.env.example deploy/.env   # POSTGRES_PASSWORD, RIM_DOMAIN
docker compose -f deploy/compose.yml up -d --build
docker compose -f deploy/compose.yml exec rim \
  /app/rim-server invite create     # first signup link

# a public relay instead
docker compose -f deploy/compose.yml \
  -f deploy/compose.relay.yml up -d --build

# switch modules off for this instance
RIM_FEATURES_DISABLED=attachments,email

Every server setting on one page

The server is configured by environment variables, all prefixed RIM_, grouped the way an operator thinks: where it listens, how people sign up, what it stores, what it talks to, what it switches off and how much it allows. Each entry: name, default, what it does, what else it needs.

Generated from the server's config module and the Dockerfile's variable block, so a new variable cannot ship undocumented.

Guides for the four people who run RIM

One GraphQL endpoint, and the HTTP around it

Everything a client does goes through POST /api; subscriptions arrive over /api/ws. The schema is published at /api/sdl with a description on every type and field, and the reference on this site is generated from it, so it cannot drift from the server.

Build a client or a server from the published specs

• Plugin protocolv1
• Web pluginsv1
• Workspace plugin registryv1
• Key identity: logs, devices, profile cards, login proofsv1
• Device linkingv1
• End-to-end encryption with MLSv1
• Server-to-server: descriptors, RFC 9421 signatures, relays and hostsv1
• History archive and the backup endpointv1

What we claim, and what we don't yet

Pull requests say what they change and why

Use whatever tools you like to write the code, including AI assistants. What we read is the pull request: it has to describe what it implements and the reason for it, in your words. A diff without that is sent back unread.

How the server code is laid out, and why we keep it that way

The server is three layers with a contract between each pair. A layer talks only to the one below it, and only through a trait. That is what lets us replace one piece, a repository on a different store, a service with different rules, a transport other than GraphQL, without touching the rest, and what lets every layer be tested against a mock of the one beneath. Pull requests that cut across the layers are sent back, however good the feature.

Pre-release, honest about it