Chatto is now open source
hmans.dev
hmans.dev
Kudos for this. Per the docs: https://docs.chatto.run/,
> Chatto ships in a compact, self-contained binary
> it uses NATS, a compact message broker that also ships with a built-in stream persistence engine [...] NATS is just as easy to provision as Chatto, and most of our examples will show you how.
> you can also configure an external S3-compatible object storage for Chatto to store your files in, and we strongly recommend doing so...
> The actual calls are powered by LiveKit (Apache-2.0), which you need to deploy alongside Chatto. As with NATS, the deployment examples show the required wiring.
> ...
And kudos for backing it up with real guidance. Great project.
Chatto so far fully commits to providing a great PWA experience. The screenshot you're seeing is of the PWA.
I'm aware that a lot of people want desktop and mobile apps. These will be coming at some point, at least as wrappers around the PWA.
Did NATS eventually worked well?
I have a stupid question - as I understand NATS works very well as a “message” pipe/bus. Anyway to get Redis type cache functionality as well ? Is it something possible ?
someone did some benchmarks in 2025:
nats bench kv put --size="128" --msgs 1000000 --storage file
1m3s → Pub stats: 15,656 msgs/sec ~ 1.91 MB/sec
nats bench kv get --size="128" --msgs 1000000
59s → Sub stats: 16,720 msgs/sec ~ 2.04 MB/sec
I also maintain these sites for npm related attacks (since there have been so many since past 1.5 years):
1. Techniques exploited: https://npm-supply-chain-attack-techniques.pagey.site/
2. Documented attacks: https://npm-supply-chain-attacks-25-26.pagey.site/
Disclosure: I’m a founder.
NATS and its built-in Jetstream stream persistence engine are a miracle. I love them both so much. And if your app is itself written in Go, you can just embed them for simple deployment scenarios (like Chatto does.)
You'll need soft delete, work messages belong to the employer and not the user.
For some you need legal holds on employee messages and in other cases you will want to un-delete messages for investigations etc.
For just random online communities, which is the niche discord is in, I agree it does sound nice.
Here's to more boring software! :)
For portuguese/spanish, there is always a high chance of being a slang that is NSFW
Log of
All
Communication &
Knowledge
https://github.com/orgs/chattocorp/projects/1?pane=issue&ite...
I am aware though that a lot of people would prefer an app that they can install, so this will be coming at some point -- just not a huge priority at the current point in the project's timeline.
That would really make it easy to send a friend a link, "hey come chat with me", without having to worry about a response such as, "I'm already on discord, I don't want to set up all that stuff".
Now are the chats end-to-end-encrypted? It only says calls are, so that remains ambiguous. I believe that would be a major sell for current Discord users.
Overall looks like a great app to try out.
Discord users want end-to-end encryption to prevent Discord employees and outsiders from reading their chats. This doesn't have that risk, because the in-group runs the server.
Why not keep it all AGPL?
A frontend, permitting customizability, white-labeling, and so on, makes more sense to be more permissive.
Grafana is a solid example to illustrate why.
Moved from Apache to AGPLv3 in 2021 specifically so cloud providers couldn't host modified versions without contributing back, while keeping plugins Apache-licensed.
Sure, the docs tell you exactly what to do to start a server, but not how to sign in to it. Or how to sign up (email is disabled).
There's an `operator` command which is supposed to let you create users, but it can't find the operator API.
You were that close to a perfect onboarding experience...
I do also still like irc, but haven't used it much in recent years because most of the people I talk to are using discord now.
I'll give Chatto a shot, but one of the things I'd love to have is interop with Slack and Discord. Is that on the roadmap or no? I saw that there's a Slack -> Chatto migration tool, but the unfortunate reality is that Slack is used by customers, so even if we internally use Chatto, compatibility with Slack is a must.
Why did it fail?
Additionally we’ve been missing video calls, so that’s nice that Chatto has it :)
The Tauri wrapper was originally just for desktop convenience and the Android target was more of a proof of concept initially.
Matrix is the obvious exception but the UX has always been terrible for me. I don't need e2ee for group messages and it brings too much complexity with it.
Another alternative that does have it would be https://fluxer.app.
But tbf, both face the same issue: those communities that you want to switch between need to exist. :/ (But of course not an issue if you're the one creating them and you have users who are down to join them.)
E2EE is not mandatory and public rooms don't usually use it.
You want the actual names so that you rank when those names are searched, no?
How does this compare to fluxer.gg though?
The part that I really liked about chatto is that it seems to be made very easily to self host which is something that I really appreciate actually.
[1]: https://fluxer.app/blog/mobile-clients-and-fluxer-v2
But I have a question, and maybe it is answered somewhere and I just couldn't find it, but is there currently a way to move a created community from e.g. the official hosting to self-hosted? I saw the mention about possible federation in the future, which would solve that (kind of), but currently it's not possible, I guess?
I would say the primary difference is that Chatto doesn't squarely aim for being a _Discord_ alternative. There are no plans for providing a Discord-compatible API (which I think Fluxer does.)
The other main difference is that Chatto is designed, on purpose, to serve individual communities from tiny deployments, instead of large mega-instances that power many communities. Chatto deliberately avoids content federation to remain compatible with business use cases, and also to stay simple enough so it can run from a single binary.
btw, I'm very happy to see that the Chatter backend is implemented in Go. Go is very good at these.
> Chatto is just like those.
from TFA. Seems yes.
I also maintain a Chatto bot framework and a Tauri client, need to update those now :)
Wait, what? There are open-source chat apps that you have to pay to host yourself? How does that work? Or did I misunderstand?
IIRC if you build it yourself it's pretty much all AGPL, with few limitations.
The reason most companies are reluctant to switch from slack is because they have external third parties i.e. their partners connected with external channels within slack. Changing their internal DM/IM system will remove their ability to communicate with their partners in the same system.
Perhaps a plugin where slack messages can be forwarded to Chatto and eventually bi-directional i.e. Chatto messages can be forwarded to Slack.
I mean, people have been asking for alternatives lately, so it's not like there isn't a market for it. There are even entire communities[0] for discovering them.
But considering there are already several dozen alternatives: what makes this one special? What sets it apart from Gamevox, Cinny, Element, Schildi, Echon, Neremity, Fluxer, Faction, Stoat, Guilded, Root, Loqa, Venta, Osmium, and so on and so on? Heck, a handful of vibecoded new ones spring up every week!
If you're going to release Yet Another Clone, you have to make it immediately obvious 1) how it compares feature-wise, and 2) what unique thing makes yours special enough to overcome the extremely powerful network effects of the incumbents. Reading this page Chatto looks neat I guess, but there's nothing convincing me to invest several hours into discovering whether this is truly a Discord killer, or Yet Another Clone. Same with the official website and docs: some techy mumbo-jumbo, but that's about it.
No matter how impressive it is technically and no matter how free and open it may be, without significantly better marketing material it'll have a chance at becoming relevant.
The marketing practically writes itself.
I tried the HQ community, the UI is indeed very snappy!
anyone tried to join lke 50+ communities with heavy updates?
Slack integrations are overrated. Just give me webhooks.
Doing it costs money, and it's not a cost you can simply shift to the end user (because only the original app developer has the required Apple certificates, and you don't want every server owner to sign up for the Apple Developer program)
* Mobile calls are another form of push notification, Apple/iOS requires setting up APNS and Google/Android requires FCM, there is no self-hosted option for that at all and, for battery life reasons, no independent replacement is supported. Genuine ownership / independence from the main project requires, iirc, basically compiling from source to register different IDs against APNS/FCM.
* Trying to get into telephony, integrating with SIP is a huge pain. Nobody wants to deal with this.
* Nobody supports high availability for the underlying calls. None of the cloud L7 load balancers support media protocols - you're dropping down to L3 UDP load balancing. All of the available solutions (including LiveKit) depend on stateful services that, at best, place ceilings on call lifetimes (e.g. 5 hours) to allow for graceful draining, but "calls" in Discord-style settings where people connect to a room and stay connected will easily outlast those ceilings. Not supporting high-availability, IMO, is a huge ask for self-hosters - the price isn't in the maintenance window itself, but in deferring updates until the maintenance window, which can leave you vulnerable, particularly if you decide to leave the firewall open to ingress from 0.0.0.0/0 for ease of use. And of course, as a self-hoster, you rarely have a full follow-the-sun ops team, so either you schedule maintenance when everybody else is off (and you should be off too) or when everybody is on (and it's disruptive).
If you do some kind of rolling upgrade, where each server has E.G. a lifetime of two weeks, with a 5 hour window where it doesn't accept new connections, I think you'll be fine.
Chatto so far commits to a fully fleshed out PWA experience. Push Notifications are delivered through Web Push (and Apple's Declarative Web Push additions). Web Push uses the browser vendors' own push gateways.
There are some missing bits currently in Chatto's multi-server story; when you add another server within the UI, its push notifications won't work because the other server can't make its service worker known to your device. One of the next versions of Chatto will improve this significantly, eg. with Chatto servers being able to act as push relays for others.
Eventually there's going to be mobile apps operated and provided by ChattoCorp, who will also set up and pay for the required push services.
(They do have end-to-end encryption for video.)
(You can scale Chatto horizontally across as many processes and servers as you need, so communities with tens of thousands of CCU should be perfectly feasible. But as you can imagine, there's precious little real-world proof for this yet :b)
It's Astro and Astro Starlight. I feel it looks very similar to other contemporary docs website generators.
this way it might be a bit easier to self host
Love that the way you said the rhymes part 'rhymes with “knack”, or the one that rhymes with “beams”, or the one that rhymes with “this gourd”'.
I hope it's as good as it sounds. Thanks for open sourcing <3
Easier said than done, but changing peoples chat app from under them in an org is a stressful thought. If they could run side by side in sync until a critical mass has moved over, then sunset the old one, or not.
for the 12 people that own a macbook, perhaps.
You can download the binaries from the GitHub release pages.
- what kind of system design components are needed
- how is networking handled at scale? do you start the project thinking about 100 users or 10000 users or more?
- how are the components derived UMLwise
- is there a website you are aware of that does the requirements breakdown of projects like these?
Looking at adding it to the malmo.network store for self-hosters
Lol I like this
Essentially, i just want something like IRC, but without the netsplit and a modern stack. It would be so much nicer for company chat and brighten up my work days.
Compared to that, Chatto is just easy, nice, and FAST. It's a chat that I actually do like to use - I don't think the landing page is over promising there :)
It's a very crowded, relatively low barrier to entry, high barrier to switch space.
You can choose to switch your company away, maybe, but what do you do when vendors want to connect over Slack?
Imagine if email was owned by a company?
Edit:
W̶e̶ ̶r̶e̶a̶l̶l̶y̶ ̶n̶e̶e̶d̶ ̶a̶n̶ ̶o̶p̶e̶n̶ ̶p̶r̶o̶t̶o̶c̶o̶l̶ ̶t̶o̶ ̶b̶u̶i̶l̶d̶ ̶o̶n̶.̶
We really need an open protocol to win here.
This Chatto thing unfortunately uses a Protobuf custom API and is explicitly anti-compatibility with other systems. The lack of interoperability may end up killing it, unless the experience is much better than everything else.
Or, perhaps the asynch chat thing is a distraction and we need something asynchronous that's well proven. Like... email?
Slack should never have been a thing IMHO. I remember first using it at a startup I was CTO of at the behest of the CEO ("everyone is using it"), back in around 2013. Instantly hated it. Just wish we could go back to good old email, TBH.
Real-time chat is, in fact, useful, and a separate product from email. The fact that you don't want to use it does not change the fact that others do.
I use Zulip and Signal extensively, and I use email occasionally, and none of them fully replace the use cases of the others.
I’d bet making a slack-compatible client or bridge isn’t hard, we all just instinctively know whoever develops it is going to get sued or taken down.
It feels like we quietly gave up on adversarial interoperability awhile ago, and act like we need a whole separate “open walled garden” when what we actually need are legal protections that prevent companies from suing/banning people who call their APIs. Slack, Facebook, etc, are walled gardens only because they can ban/sue people who compete with their client experience.
I figure that will probably never happen in the US (maybe if someone rich starts it), but eventually someone outside of it will make such an adversarial integration and host it from some region that doesn’t care about US laws. Then, when they get away with it, we’ll all praise them as a genius and wonder how Slack could exist at all. The US has many international agreements keeping this illusion alive, but my guess is that even formerly stable markets like Europe could spawn such work if they decide to stop caring about ~1990s-2010s era contempt-of-business-model US laws.
There are things that Slack cannot easily offer.
Email worked out pretty well, while IRC failed for reasons that are probably correctable.
But this software is not for expanding the audience, it's for limiting it, and their exposure. Much like Tailscale is not for extending your network with more nodes that can freely join, but for limiting it to a private subset you trust.
The Tailscale analogy isn't quite right because there are no real network effects involved. Most of Tailscale's utility exists even if no one else uses it.
Slack is only useful if your friends, coworkers, or partners use it. Same with Discord, and even open source alternatives for the most part.
Discord is winning because it's a dozen different communities in one single convenient client. Want your new chat platform to win? Convince all those communities to switch.
Just need a client app to make it look like something else.
Like slack did.
Self hosted voice/video/chatroom server with RBAC, federation capabilities and encryption.
Different topic, who uses federated slack?
I have a small group of close friends. We are on discord just about every day, but we really don't bother with anyone outside our group, other than the very occasional invitation to another friend/coworker to join for some games.
We don't care about network effect, social media features, engagement, etc. We just want a well made application for private text, voice, and video that we never have to actually think about.
And no, matrix is not that.
So not like Discord or Slack?
> This is what it looks like:
Discord and Slack?
I mean, OK, it has EU hosting and that is good. But I see nothing obvious here that solves the noise and irritation of Discord and Slack.
All these systems end up with far too much furniture on screen, and this appears no exception.
I will test it, of course. But the promotional material argues against itself.
Though it does seem to (so far) be easier to host and less complicated than Mattermost, which is not nothing.
With chat control that may not be so great…