HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
42wim
matterbridge
Go2016–2024
42wim / matterbridge

matterbridge

bridge between mattermost, IRC, gitter, xmpp, slack, discord, telegram, rocketchat, twitch, ssh-chat, zulip, whatsapp, keybase, matrix, microsoft teams, nextcloud, mumble, vk and more with REST API (mattermost not required!)

Self-hostedGames & EmulationWeb DevelopmentNetworkingCommunication & Social
Explore on GitHubRead Hacker News discussions
29Distinct people
50Mentions
0Explicit recommenders
7.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

bridge between mattermost, IRC, gitter, xmpp, slack, discord, telegram, rocketchat, twitch, ssh-chat, zulip, whatsapp, keybase, matrix, microsoft teams, nextcloud, mumble, vk and more with REST API (mattermost not required!)

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year50 dated mentions

Observed mentions: 2016-03-16 22:00:31 UTC to 2024-10-01 15:40:42 UTC.

0369122016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 11 mentions; 0 submissions, 11 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC404
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC11011
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC606
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC716
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC909
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC303
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC312
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC404

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
matterbridge A simple chat bridge Letting people be where they want to be. Bridges between a growing number of protocols. Click below to demo or join the development chat. Discord | Gitter | IRC | Keybase | Matrix | Mattermost | MSTeams | Rocket.Chat | Slack | Telegram | Twitch | WhatsApp | XMPP | Zulip | And more... Note: Mattermost isn't required to run matterbridge. Table of Contents matterbridge Table of Contents Features Natively supported 3rd party via matterbridge api API Chat with us Screenshots Installing / upgrading Binaries Packages Building Building with whatsapp (beta) multidevice support Configuration Basic configuration Settings Advanced configuration Examples Bridge mattermost (off-topic) - irc (#testing) Bridge slack (#general) - discord (general) Running Docker Systemd Changelog FAQ Related projects Articles / Tutorials Thanks Features Support bridging between any protocols Support multiple gateways(bridges) for your protocols Message edits and deletes Preserves threading when possible Attachment / files handling Username and avatar spoofing Private groups API Natively supported Discord Gitter Harmony IRC Keybase Matrix Mattermost Microsoft Teams Mumble Nextcloud Talk Rocket.chat Slack Ssh-chat Steam Not supported anymore, see here for more info. Telegram Twitch VK WhatsApp Whatsapp legacy is natively supported Whatsapp multidevice beta is natively supported but you need to build yourself, see here XMPP Zulip 3rd party via matterbridge api Delta Chat Minecraft Minecraft Past 3rd party projects Discourse Facebook messenger Facebook messenger Minecraft Reddit MatterAMXX: Counter-Strike, half-life and more Vintage Story Ultima Online Emulator Teamspeak API The API is basic at the moment. More info and examples on the wiki. Used by the projects below. Feel free to make a PR to add your project to this list. MatterLink (Matterbridge link for Minecraft Forge server chat, archived) MatterCraft (Matterbridge link for Minecraft Forge server chat) MatterBukkit (Matterbridge link for Minecraft Bukkit/Spigot server chat) pyCord (crossplatform chatbot) Mattereddit (Reddit chat support) fbridge-asyncio (Facebook messenger support) fbridge (Facebook messenger support) matterbabble (Discourse support) MatterAMXX (Counter-Strike, half-life and more via AMXX mod) Vintage Story ServUO-matterbridge (A matterbridge connector for ServUO servers) ts-matterbridge (Integrate teamspeak chat with matterbridge) beerchat (Matterbridge link for minetest) Chat with us Questions or want to test on your favorite platform? Join below: Discord Gitter IRC Keybase Matrix Mattermost Rocket.Chat Slack Telegram Twitch XMPP (matterbridge@conference.jabber.de) Zulip Screenshots See https://github.com/42wim/matterbridge/wiki Installing / upgrading Binaries Latest stable release v1.26.0 Development releases (follows master) can be downloaded here selecting the latest green build and then artifacts. To install or upgrade just download the latest binary. On *nix platforms you may need to make the binary executable - you can do this by running chmod a+x on the binary (example: chmod a+x matterbridge-1.24.1-linux-64bit). After downloading (and making the binary executable, if necessary), follow the instructions on the howto for a step by step walkthrough for creating your configuration. Packages Overview snap scoop Building Most people just want to use binaries, you can find those here If you really want to build from source, follow these instructions: Go 1.18+ is required. Make sure you have Go properly installed. Building the binary with all the bridges enabled needs about 3GB RAM to compile. You can reduce this memory requirement to 0,5GB RAM by adding the nomsteams tag if you don't need/use the Microsoft Teams bridge. Matterbridge can be build without gcc/c-compiler: If you're running on windows first run set CGO_ENABLED=0 on other platforms you prepend CGO_ENABLED=0 to the go build command. (eg CGO_ENABLED=0 go install github.com/42wim/matterbridge) To install the latest stable run: go install github.com/42wim/matterbridge To install the latest dev run: go install github.com/42wim/matterbridge@master To install the latest stable run without msteams or zulip bridge: go install -tags nomsteams,nozulip github.com/42wim/matterbridge You should now have matterbridge binary in the ~/go/bin directory: $ ls ~/go/bin/ matterbridge Building with whatsapp (beta) multidevice support Because the library we use for Whatsapp multidevice support includes a GPL3 library we can not provide you binaries. (as this would require the Matterbridge to change it license to GPL) Matterbridge can be build without gcc/c-compiler: If you're running on windows first run set CGO_ENABLED=0 on other platforms you prepend CGO_ENABLED=0 to the go build command. (eg CGO_ENABLED=0 go install github.com/42wim/matterbridge) So this means you have to build it yourself using the instructions below: go install -tags whatsappmulti github.com/42wim/matterbridge@master If you're low on memory and don't need msteams: go install -tags nomsteams,whatsappmulti github.com/42wim/matterbridge@master You should now have matterbridge binary in the ~/go/bin directory: $ ls ~/go/bin/ matterbridge Configuration Basic configuration See howto for a step by step walkthrough for creating your configuration. Settings All possible settings for each bridge. Advanced configuration matterbridge.toml.sample for documentation and an example. Examples Bridge mattermost (off-topic) - irc (#testing) [irc] [irc.libera] Server="irc.libera.chat:6667" Nick="yourbotname" [mattermost] [mattermost.work] Server="yourmattermostserver.tld" Team="yourteam" Login="yourlogin" Password="yourpass" PrefixMessagesWithNick=true RemoteNickFormat="[{PROTOCOL}] <{NICK}> " [[gateway]] name="mygateway" enable=true [[gateway.inout]] account="irc.libera" channel="#testing"
Read the full README on GitHub

What Hacker News says

50 sources
pinusc·Feb 23, 2024
An involved alternative is to access whatsapp through a matrix bridge. It requires either paying for hosting or figuring out how to host a matrix server and the whatsapp bridge [1]; I do the latter and can attest it's not very hard if you have a technical background (and you're on hn, so you probably do), but YMMV. There's a lot of matrix clients, all of which open source; and the whatsapp bridge works really well nowadays, enough that I've been using it almost exclusively for my texting (no whatsapp calls tho). In fact, I recently bought a non-smartphone running KaiOS, and use whatsapp through a matrix client, chooj - which, although in early alpha, works well for my use case of accessing whatsapp while outside the home without having to carry an addictive smartphone with me. KaiOS does have a native whatsapp app, but it does not support
Read the rest
whatsapp web at all, and that is an absolute necessity for me, especially when typing requires (bad) T9. My point is, matrix bridges afford A LOT of freedom with how to access whatsapp (and other closed-source communication apps), if you're willing to deal with some friction. And now they're stable and mature enough that they work pretty darn well - no doubt thanks in part to support from beeper [2], which funds development for several major bridges. Within the android ecosystem, beeper is probably the easiest way to gateway all your communications through matrix, though I have no experience with it. Sounds like paid matrix+bridge hosting, plus a generally much nicer and frictionless experience. [1]: https://github.com/42wim/matterbridge [2]: https://www.beeper.com/
In The Lost Art of Single-Tasking Devices
ParetoOptimal·Jan 11, 2024
> now the brave Emacs user of 2024 is forced to spend lots of time not in Emacs, thus defeating the point of using Emacs. If you can just get your email in Emacs, you can get a lot of integration you need. Luckily, email is still a must-have for many services. For things like slack, teams, etc... it's much much harder. Glancing at my "emacs for everything" roam node, I was last looking at utilizing matterbridge[0] to get access to teams, slack, etc by bridging to IRC. However, more ideal would be bridging to matrix especially if attachments/etc can be bridged over. Taking actions based upon notifications though all the way from beginning to completion, then using elisp to customize the process, is definitely where emacs has the most impact. Coworker pasted some code? You are reading it in an emacs buffer and have a function to open the co
Read the rest
de block at point in a python buffer with a repl split to the right to test it with no effort. 0: https://github.com/42wim/matterbridge
In A CEO's Guide to Emacs (2015)
3np·Mar 26, 2022
> It seems like a puppeted bridge requires me to send the messages to the Matrix server who then has a login to my FB Messenger to read/write messages there. I'm not going to run my own Matrix server so that requires me to trust a Matrix server with access to my Facebook. This is kind of how it's done today but also not exactly. The bridge (which is what has access to your account and messages) is its own process and could in principle be run on a separate host (like your own device for a single-user bridge). However, most (all?) public homeservers access for connecting puppeting bridges (meaning "virtual" Matrix identities for each identity on the bridged network, rather than just having a single "botuser" for all conversations through the bridge) and the API for access is rather coarse. Also, last time I checked most bridges do not imp
Read the rest
lement E2EE and signing properly, which means that the homeserver it connects to both gets read-access to bridged messages and can impersonate. This is mostly a matter of implementation not being prioritized highly in bridge projects. Currently that can be worked around to get E2EE even for cleartext bridges by running a protocol-specific proxy called pantalaimon which sits between the bridge and the homeserver and terminates encryption. There are tradeoffs that can be made, which can be seen in the different alternatives for IRC bridges. For example, matterbridge is more of a typical bot (supporting loads of protocols!) and can be run towards a remote homeserver as a normal user. https://github.com/hifi/heisenbridge#comparison https://github.com/42wim/matterbridge/wiki/Section-Matrix-%2... I am certain we will see better interfaces to allow people to run local personal IM bridges without the requirements and overhead involved today. Thinking out loud here, I could imagine a minimal per-user homeserver baked into a client, that only does bridging for that user and only federates with the homeserver of that users' accounts. That could tick all the boxes even before P2P matrix I think. The benefit of this approach over pidgin or a purely local single-user homeserver (which are viable and it sounds like you kind of want) would be all the conveniences people have gotten used to with centralized platforms... E.g. if you have the bridged rooms on a remote homeserver, seamless retention of histories across all your devices, without needing to be simultaneously online. But you'd also only need to keep credentials local, and message content in cleartext would only ever be acessible on your client(s).
In Pidgin: The Universal Chat Client
southerntofu·Feb 5, 2022
Well the good thing about nyxt is it's super extensible so a PoC doesn't require proper "reception" on their side. Do you maybe have a gateway/bridge to a libre network such as IRC/XMPP/Matrix? I find HTMX pretty interesting but i wouldn't touch discord with a 10-foot pole, if only because my limited computing resources won't allow for such a resource-hungry app to run in the background. It seems like matterbridge supports discord backend but i don't have a discord account to try it with. If you're not willing to host matterbridge, i'm already hosting one and i would just need credentials to try and connect it to Discord. If you're willing to give that a try, feel free to mail me at my username @ thunix.net. https://github.com/42wim/matterbridge
In Tor Browser: a legacy of advancing private browsing innovation
tabbott·May 14, 2021
On the federation front, if your goal is to connect different chat services running different chat protocols, that's been possible for years with tools like Matterbridge (https://github.com/42wim/matterbridge). Zulip also has direct bridge integrations with IRC and a handful of other protocols, e.g. https://zulip.com/integrations/doc/irc. These integrations are a bit ugly and certainly not the ideal design, but they work and help a lot of communities that are 90% on Zulip but still want an IRC presence for whatever reason. (A fun historical note: Zulip's had a really nice puppet-powered bridge with Zephyr since 2012, because that was how we got enough usage during its early development to design the product and its data model with real users). Longer term, we're planning to build a native Zulip federation feature. For us the technical st
Read the rest
rategy has been to first make a Zulip world-class user experience, and do native federation later. Our strategy is motivated by XMPP, which like Matrix is extremely general (E.g. I talked to people who used XMPP as message bus for their backend infrastructure 10 years ago). XMPP is dying as a chat protocol because nobody can build a modern world-class chat application using it as the client/server protocol. E.g. multiple people who'd worked as engineers on now-dead chat products complained that because their mobile apps talked XMPP to their server, it was impossible for them to make the apps start quickly in medium-size organizations, because of all the round-trips required. In contrast, Zulip's client/server protocol both on web and mobile returns all metadata in a single HTTP request: https://zulip.com/api/register-queue, and then after that, another to fetch whatever messages you're going to look at.
In Zulip 4.0: Threaded open source team chat

Showing the 15 most recent of 50 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.