A tool for running self-hosted bridges with the Beeper Matrix server.
The primary use case is running custom/3rd-party bridges with Beeper. You can connect any† spec-compliant Matrix application service to your Beeper account without having to self-host a whole Matrix homeserver. Note that if you run 3rd party bridges that don't support end-to-bridge encryption, message contents will be visible to Beeper servers.
†caveat: hungryserv does not implement the entire Matrix client-server API, so it's possible some bridges won't work - you can report such cases in the self-hosting support room linked below or in GitHub issues here
You can also self-host the official bridges for maximum security using this tool (so that message re-encryption happens on a machine you control rather than on Beeper servers).
[!NOTE] Self-hosted bridges are not entitled to the usual level of customer support on Beeper. If you need help with self-hosting bridges using this tool, please join #self-hosting:beeper.com instead of asking in your support room.
./build.sh
. Building requires Go 1.22 or higher.bbctl login
.Then continue with one of the sections below, depending on whether you want to run an official Beeper bridge or a 3rd party bridge.
For Python bridges, you must install Python 3 with the venv
module with your
OS package manager. For example, sudo apt install python3 python3-venv
on
Debian-based distros. The Python version built into macOS may be new enough, or
you can get the latest version via brew. The minimum Python version varies by
bridge, but if you use the latest Debian or Ubuntu LTS, it should be new enough.
Some bridges require ffmpeg for converting media (e.g. when sending gifs), so
you should also install that with your OS package manager (sudo apt install ffmpeg
on Debian or brew install ffmpeg
on macOS).
After installing relevant dependencies:
bbctl run <name>
to run the bridge.
<name>
should start with sh-
and consist of a-z, 0-9 and -.<name>
contains the bridge type, it will be automatically detected.
Otherwise pass the type with --type <type>
.~/.local/share/bbctl
. You can change the
directory in the config file at ~/.config/bbctl.json
.@<name>bot:beeper.local
). Configuring self-hosted bridges through the
chat networks dialog will be available in the future. Spaces and starting
chats are also not yet available, although you can start chats using the
pm
command with the bridge bot.There is currently a bug in Beeper Desktop that causes it to create encrypted DMs even if the recipient doesn't support it. This means that for non-e2ee- capable bridges like Heisenbridge, you'll have to create the DM with the bridge bot in another Matrix client, or using the create group chat button in Beeper Desktop.
Currently the bridge will run in foreground, so you'll have to keep bbctl run
active somewhere (tmux is a good option). In the future, a service mode will be
added where the bridge is registered as a systemd or launchd service to be
started automatically by the OS.
When using bbctl run
or bbctl config
and the provided <name>
contains one
of the identifiers (second column) listed below, bbctl will automatically guess
that type. A substring match is sufficient, e.g. sh-mywhatsappbridge
will
match whatsapp
. The first listed identifier is the "primary" one that can be
used with the --type
flag.
Bridge | Identifier |
---|---|
mautrix-telegram | telegram |
mautrix-whatsapp | |
mautrix-signal | signal |
mautrix-discord | discord |
mautrix-slack | slack |
mautrix-gmessages | gmessages, googlemessages, rcs, sms |
mautrix-gvoice | gvoice, googlevoice |
mautrix-meta | meta, instagram, facebook |
mautrix-googlechat | googlechat, gchat |
mautrix-twitter | |
mautrix-imessage | imessage |
beeper-imessage | imessagego |
linkedin-matrix | |
heisenbridge | heisenbridge, irc |
bbctl register <name>
to generate an appservice registration file.
<name>
is a short name for the bridge (a-z, 0-9, -). The name should
start with sh-
. The bridge user ID namespace will be @<name>_.+:beeper.local
and the bridge bot will be @<name>bot:beeper.local
.url: http://localhost:8080
), then run bbctl proxy -r registration.yaml
to start the proxy.
Note that the homeserver URL is not guaranteed to be stable forever, it has changed in the past, and it may change again in the future.
You can use --json
with register
to get the whole response as JSON instead
of registration YAML and pretty-printed extra details. This may be useful if
you want to automate fetching the homeserver URL.
If you don't want a self-hosted bridge anymore, you can delete it using
bbctl delete <name>
. Deleting a bridge will permanently erase all traces of
it from the Beeper servers (e.g. any rooms and ghost users it created).
For official bridges, it will also delete the local data directory with the
bridge config, database and python virtualenv (if applicable).