Bridges #

A bridge is a program that sits between your Matrix server and an external chat network (Telegram, Slack, Discord, etc.) and translates messages in both directions. From inside your Matrix client it looks like everyone you talk to is "on Matrix"; from inside Telegram/Slack/Discord it looks like you're just another user on that platform.

The result: one inbox for all your chats. Stop context-switching between six apps.

Why use bridges? #

Unified client. Use Element (or whichever Matrix client you like) as your single chat UI, even when your colleagues are on Telegram and your customers are on WhatsApp.
Own your history. Messages that flow through a bridge land in your Matrix server's database — you control retention, export and deletion.
Encryption end-to-end on your side. The room between Matrix users stays E2EE. Messages that cross over to the foreign network are decrypted at the bridge, then re-encrypted according to the foreign network's rules (most bridges support "double-puppeting" so encrypted rooms stay encrypted on both ends).
Leave anytime. Bridges are opt-in per network and disable cleanly from the dashboard.

How a bridge works, conceptually #

A bridge is implemented as a Matrix appservice — the protocol Matrix uses to let non-user programs register namespaces of virtual users and rooms. In practice:

You enable the bridge from your Meldry dashboard → Server → Bridges.
Meldry starts the bridge process (e.g., mautrix-telegram) alongside your homeserver, with its configuration pointing at your server.
The bridge registers a bot user on your server, typically @telegrambot:your-name.meldry.com (or similar).
You DM that bot from any Matrix client and send login.
The bot walks you through linking your foreign account — usually either an OAuth flow, a QR code scan, or pasting a session token from the foreign app.
Once linked, the bridge spawns "puppet" Matrix users and rooms that mirror your contacts and chats on the foreign network.

Messages you send in a puppeted Matrix room are pushed to the foreign network by the bridge; messages from the foreign network are pushed back as Matrix events.

Available bridges on Meldry #

Bridge	Network	Plan required	Notes
mautrix-telegram	Telegram	Pro	Full coverage — 1:1, groups, channels, media
mautrix-slack	Slack	Pro	Workspaces → spaces, channels → rooms, threads
mautrix-discord	Discord	Pro	Servers → spaces, channels, voice excluded
mautrix-whatsapp	WhatsApp	Business	Requires scanning QR from phone
mautrix-signal	Signal	Business	Requires linking from Signal Desktop
dingtalk	DingTalk	Business	China-region, webhook-based
feishu	Feishu (Lark)	Business	Requires Feishu app credentials

Additional bridges (IRC via Heisenbridge, WeChat, Google Chat, etc.) are available on request — open a ticket.

Plan limits #

Free — no bridges.
Starter — 2 bridges.
Pro — 5 bridges, federation enabled.
Business — unlimited bridges, priority support.

See Billing for the full plan comparison.

Puppeting vs relay mode #

Most bridges support two operating modes:

Puppeting (recommended). You link your own account on the foreign network. Messages you send from Matrix appear on the foreign side as if you sent them natively. Encrypted rooms can stay encrypted end-to-end on both sides.
Relay mode. A single bot account represents everyone from Matrix on the foreign side. Users on the foreign network see messages like [Alice] Hello from Matrix. Setup is easier (no per-user login) but breaks DMs and reactions, and foreign-network E2EE is lost.

Puppeting requires every user who wants the bridge to link their own account. Relay mode is useful for big public rooms where many Matrix users want to participate without each signing up for the foreign network.

Common setup flow #

Every bridge guide in this section follows the same pattern:

Enable the bridge from Dashboard → Server → Bridges.
Start a DM with the bridge bot (@telegrambot:…, @slackbot:…, etc.).
Link your account with the login command — each bridge has a slightly different flow (QR code, OAuth, token, etc.).
Bridge specific rooms with !bridge <room-id> (or the bridge's equivalent).

See the individual guides for details:

Troubleshooting #

Bridge doesn't start. Check your plan limit (Free has 0, Starter has 2, Pro has 5, Business unlimited). Open Dashboard → Notifications for the bridge startup logs.

Can't DM the bridge bot. The bot user only exists after the bridge has successfully booted. Wait ~10 seconds after enabling, then refresh your Matrix client's contacts.

Messages don't sync. Run status in the DM with the bridge bot. It will report the link status of your foreign account. If it shows "logged out", re-run login.

Foreign-network rate limit hit. Telegram, WhatsApp and Signal enforce strict rate limits. If you spam a bridged room, the bridge may be temporarily throttled. Wait a few minutes.

Encryption errors. If you can't read messages in a bridged encrypted room, the puppet user may not have your device keys. In the room → People → Verify this session, or restart the bridge from the dashboard.

Security considerations #

Bridges operate with full access to your messages on both sides. Audit the bridge image you enable.
Meldry uses the upstream mautrix images for most networks. The DingTalk and Feishu bridges are built in-house.
Foreign-network credentials (Telegram session, Signal link, Slack tokens) are stored encrypted at rest in your workspace's private storage. They're never shared across workspaces.
Deleting a bridge from your dashboard deletes the credentials and closes all puppeted rooms. Messages already delivered to your Matrix rooms remain; messages sitting on the foreign side do not come back.

What's next #

Pick the network you want to connect:

Telegram — probably the easiest bridge to set up
Slack — requires being a Slack workspace admin
Discord — Discord servers → Matrix spaces
WhatsApp — QR-code linking from your phone
Signal — link from Signal Desktop
DingTalk — for China-based teams
Feishu (Lark) — for ByteDance workplace