> 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.
This is super cool. More options is always good. Something that is confusing about the docs though... is there a desktop application? The screenshot implies there is but I couldn't find the docs to download THAT.
There is a Tauri wrapper that I built early on because I wanted the desktop convenience (autostart, separate app, etc) that Firefox+PWA couldn't offer, I use the desktop version as my daily Chatto driver. The mobile build is more of a proof of concept for now. Check it out: https://github.com/teal-bauer/chatto-tauri
It's a really cool project and clearly you put a lot of effort behind it. I like that it's self-hosted and may try it out on my homelab. Thanks for making it!
Wow, it's using NATS! I used NATS extensively 10+ years ago, and I'm happy to hear it's still around. Our infrastructure had hiccups across our fleet of machines, but one part that always remained up and running without complaining on some dinky machine was NATS. Well, that and Redis. No complaints ever.
We are building something B2B expected to have good enough scale ... we had to choose between kafka, nats, redpanda and rabbitMQ .... We went ahead with NATS .... don't know why, but, when we went through all the docs, including setup and operational, NATS just felt right.
Excellent. We already tested at okayish scale of 5 million messages per minute, with each message being less than 1KiB. Do note that NATS can easily handle 100x this scale. It's just what we had tested during initial days.
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 ?
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.)
One of the reasons why legacy apps continue to live on (despite outliving their usefulness ) is third party tie-ins.
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’ve known Hendrik for years, and he is one of the most talented developers I’ve ever met. I’m confident this project will become successful very quickly. Beyond the project itself, what fascinates me most is how he single-handedly developed it by leveraging agentic coding.
I second that. I've personally known him for almost 30 years by now, and he's still one of the smartest, most experienced, and most curious devs I've ever met. All around good guy, would work with him again any day of the week.
There is a difference between vibe coding (asking an agent to generate an app from specifications) and leveraging agents to go faster on your vision. You can still decide to control the technical architecture and decisions and just let agents type on your behalf.
I wouldn't know. With the post mentioning teams and slack I just got the feeling it was on the cards, so I thought it was worth posting that in case it hadn't occurred to them.
I would guess that in these cases you would just not allow users to self-delete their accounts? But for most users and providers of Chatto I think automatic right-to-deletion compliance sounds nice :)
Different users (operators of Chatto servers) will have different requirements for this, so it's pretty much "configurable" in the sense that eg. a business that's hosting a Chatto server for their employees can disable shredding account deletion and just deactivate accounts instead, leaving their data intact.
What does implementing soft-delete have to do with data storage though? If you just set up an S3-compatible backend like the docs offer you then have data persistence out of the box, no?
Can also mean annoying. As a general recommnedation, before naming a project or company something, always search whether it means something bad in the top 10 most spoken languages.
For portuguese/spanish, there is always a high chance of being a slang that is NSFW
This is awesome! Some feedback - I can't tell anywhere from the website if there is mobile support (which is a must-have if I want to consider moving my company or friends over to this)
It is indeed planned, but in the meantime it does also have first-class PWA support, so you can easily install the webapp as a mobile app on mobile devices. Works great on Android.
Note that to send notifications to an iOS app, the app publisher has to send them. This means that they need to run an event forwarding proxy service (this is how Mattermost and Element/Matrix and presumably some/all of the ActivityPub clients do it), or selfhosting your server means you must also selfpublish your client app via the App Store and Apple’s developer program tax.
For Mastodon, each mobile app developer needs to have a "webpush relay server" to receive Mastodon's webpush notifications and transmit them to the platform's push service. For Android, Mastodon recently added support for the latest webpush standard which allows the app developer to directly register Google's webpush endpoint with Mastodon, removing the need for a relay.
In all cases, push notifications are encrypted by the Mastodon server, and decrypted by the Mastodon client, so any intermediaries (relay server, push notification service) can not read their content.
Chatto currently commits to providing a strong PWA experience that also works great on mobile (including full support for voice and video calls, push notifications, the works.)
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.
What would be really awesome is some sort of feature where, once self hosted, I can generate a package or link that will download + install + pre-configure the login. Basically a bespoke installer/setup script. that can be linked to a particular person. The goal being to make onboarding as frictionless as possible. This could have some security implications maybe (the link is shared by mistake), but for a small self-hosted instance, that seems like something that could be mitigated fairly easily. Maybe only works with local accounts or something.
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".
What would you expect that to do beyond a "here's a link to the instance, sign up there"? You can combine it with Discord-like roles and gate channel visibility and rights on that, so even if someone else would sign up you just wouldn't give them the "in-group" role for example. Are you thinking of an "invitation" type link with a one time token or something?
I’m wondering too, the closest thing I can think of is maybe Zoom? It goes from link to opening your meeting *relatively* smoothly when the client needs to be installed.
Right, I'm thinking along the same lines as what Zoom offers. Except with the additional feature that the link is custom tailored to a known, pre-configured user. So you also skip the "log in as guest or create an account" step.
So the UI is a Discord clone, I think that's worth mentioning. It's not a bad thing, quite the opposite: Discord nailed it in that regard.
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.
What's the point of end-to-end encryption on a group chat where the entire group can decrypt it?
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.
The documentation looks very pleasing. But it doesn't seem to be free, too. Does anybody know with what framework it's made? WhatCMS says "Astro", but I guess this is too generic and there more involved.
Backend under AGPL prevents someone hosting it as a service. AGPL specifies that hosting _is_ distribution. Therefore, anyone hosting it must do so with public code. This provides a soft form of exclusivity to run their own Cloud.
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.
Wow! I've tried (and failed) to implement a chat application which parries slack and it sounds like the direction you're going in with Chatto is precisely what I was envisioning.
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.
Very good. I was wondering about this a while ago - lots of companies want something to aggregate notifications and perform simple bot actions, but don't necessarily want to lock into a chat provider. Having this as the frontend to a load of integrations (or even just internal chat) would be really interesting.
Yeah, Chatto should be relatively straight forward to use in "headless mode". I've seen a few users working on integrating it into their own applications as a chat backend.
I will keep an eye on this! We’re currently using Mattermost, but their pricing is a bit all over the place and targeted for enterprise so we’re still running on the, now gimped, open source version.
Additionally we’ve been missing video calls, so that’s nice that Chatto has it :)
The killer feature of Discord for me is being able to jump between communities without logging in to each of them. Open source alternatives never provide that. Does this one?
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.
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.)
felt the same way so I've built one for myself that I've been using with friends and family - not (yet) open source but self-hostable https://github.com/bogpad/meepachat
Each Chatto server by design is entirely isolated, including user accounts. But I'm aware that having to email-signup on every server you want to hang out in would eventually be too annoying. I'm exploring some lightweight identity federation ideas that I hope to ship with 0.5 where you can use your Chatto account on one server to log into another server (if it's configured to allow this.)
Very cool. I don't usually get excited for new chat apps, but I like the idea of having one frontend for multiple servers instead of pushing hard on p2p or federation.
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.
One front-end for multiple servers is how you end up reimplementing XMPP (bar federation) before you know it: servers are not guaranteed to run identical/compatible versions -> you bake versioning at capability level in the protocol -> you make clients and servers degrade predictably when that happens -> you write a standard to document it formally -> you invite around the table those authors of alternative client and server implementers and boom, you've got the X in XMPP, and the XEP standardisation process and the XSF to support it.
I bet this does a kind of "iframe" thing, where you're really just pulling in full web UIs, and they can be whatever they want. That's the impression I get from the comment about phone clients wrapping the web UI because there's no guarantee about what they will actually be.
I joined the chat as well, but if Hendrik is here - we'd love to have you on the channel (https://youtube.com/@WithMultiplesAI). This will make for one hell of an episode, I think.
Yeah, there are definitely valid contexts for hosting chat like this. E2EE has the benefit of not needing to trust the host, which I personally like but I can see this being fine or even wanted for lots of cases.
Yes, Chatto's core system does not use e2ee. This is by design; if there ever are e2ee features -- and chances are good they will, in some shape -- the encryption will be layered on top of that (encrypted message payloads and such.)
I've been testing/using chatto since early on and I'd say it's both and neither. It feels much nicer to use than Slack, but as of now it's missing some of the more "Enterprise" features. I would probably say it's a Slack-like Discord? But from the architecture it would be capable of playing as a full Slack replacement.
I also maintain a Chatto bot framework and a Tauri client, need to update those now :)
For me, primarily the performance tbh. Chatto just flies and Slack feels incredibly sluggish. And from the "vibes" it just feels better designed, I like the overall user experience, it feels technologically solid but also looks nice and works how I feel it should. Hard to put my finger on it exactly.
In terms of inspiration and also the market that I want to go after with Chatto Cloud, this is definitely aiming to be an alternative to Slack, Teams, Mattermost et al. I've tried to make it friendly and casual enough to _also_ work as a Discord alternative, though.
I've been trying to find a Slack replacement since Salesfarce started ruining it and I must have tried out maybe 50 potential replacements, paid and free. This is the first self-hostable, open source one I've seen that doesn't look like design is the very last item on an amorphous future roadmap. In fact, there's some really nice design and UX touches in Chatto. Congrats on the launch, I'm absolutely certain we'll move off Slack to this when the dedicated apps arrive, maybe even before.
We just installed it on our vps. All super smooth. We also enabled push on the serverside and now I get iOS notifications via the PWA. Generally super fast and snappy!
I wonder how they'll handle APNS, which will have to happen eventually.
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)
Yeah, I'm working on a communications platform as a side-project, architecturally providing reliable communications is exceedingly difficult to self-host.
* 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).
I'm assuming you're talking about Apple Push Notification Service.
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.
single executable with its own frontend is the way; I followed the pattern with https://worb.cloud . Nice for users but also extremely easy to have a short debugging feedback loop
I didn't really check the code, but I'd be interested to know if it uses quic and if the connections are eliminated based on registered encryption keys.
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.
There are plans for making individual rooms public, allowing unauthenticated users to access them (or allowing crawlers to index the content), but so far those plans do not include any sort of write access.
Still figuring out the numbers, so very hard to answer at the moment. Chatto is quite lightweight though; a fresh instance will run at tens of MB of RAM usage. RAM usage then scales with activity and CCU; on the Chatto HQ server, I'm currently seeing around 10 MB per additional connected user. I want this to be less, there's probably lots of room for optimization.
(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)
I’m wondering about privacy tradeoffs. Looks like they’re similar to Discord where the chats won’t show up in web searches and you can’t read anything without joining. But if anyone can join, it’s not like Signal either and end-to-end encryption wouldn’t make sense.
it would be interesting if instead of making migration tools - one shot - you could do a migration then sync.
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.
Curious. Most places needing SSO also have legal retention requirements, making E2E a hard nonstarter. And most E2E users wouldn't want to rely on a SSO that could likely revoke their keys. What's your environment?
Chatto does have full SSO support (OIDC and some selected providers like Google, GitHub, and, ironically, Discord, with more coming in the next releases.)
Chatto going open source means we can finally have an AI that reads our messages and judges us silently, but at least now we can read the source code to confirm it is judging us
I'm the developer behind Fluxer – self-hosting is ready to use already [1][2][3], people are using it actively currently, and I'm currently working to make account switching across instances in the desktop app a reality. This, with a big voice update around the corner, will let us move much faster moving forward!
Great work! Imo the most promising Discord alternative so far.
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?
Thanks! And you're right, the future federation work is what will make it possible to implement support for transferring communities across instances natively.
I love Fluxer! Hampus is cool and what he's built is super impressive.
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.
Ah mobile app is not ready yet. I am looking for some alternative to matrix because running it with bots is a bit convoluted, i.e. you have to have limit of edits of message for model streaming or you will kill entire room. Or I never seen robots in matrix sending encrypted messages. Why bother than? Anyway if mobile will be a thing this seems like perfect thing to have for your family and friends.
I created a Tauri based app but IMO it's not ready for prime time on mobile. On desktop, it's my daily driver for Chatto. If anybody wants to contribute, the foundation (desktop & mobile) is at https://github.com/teal-bauer/chatto-tauri
Interesting but could you put few screenshots there? Of both desktop and mobile? It is really hard to invest time into installing something that you cant see anywhere prior, and it will be really easy to do for someone that is using it daily. Sorry for complaining. Seems like nice project.
For now it's just a Tauri wrapper, so it looks more or less like the mobile web / PWA except it might be easier to handle notifications and share intents etc. compared to a pure PWA play. Now that the API is settled, it might make sense to go pure native.
The Tauri wrapper was originally just for desktop convenience and the Android target was more of a proof of concept initially.
Sure I understand though, I have honestly no idea what tauri is really. Sure there is a link and it looks like some kind of web framework. Looks nice but it is hard to picture how chat application written with that would look like. I am not trying to force you to do want I want. I just think it is in a good taste to put some screenshots or even a gif. But I understand your reluctance.
Chatto aims to be the group chat application that you actually enjoy using. You’re probably familiar with the one that rhymes with “knack”, or the one that rhymes with “beams”, or the one that rhymes with “this gourd”.
Mattermost's licensing is a little confusing, but from what I understand, you're only really super-restricted if you use the prebuilt binaries (which have a different license than the source code).
IIRC if you build it yourself it's pretty much all AGPL, with few limitations.
Many otherwise open-source chat apps are "open-core," they tie certain features to a subscription. Can be things like chat history, voice calls, video calls, but a very popular one is SSO and AD/LDAP integration.
I don't want graphics in my chat. I don't want formatting in my chat. I don't want to see my co-workers pictures in my chat. I don't want this "modern-individual-but-non-the-less-same-y-looking" html and css driven "custom" UI that every of these apps has. I don't want emoji in my chat. I don't want all this other enshitification crap.
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.
I've been trying to use Matrix for years and I still hate it at least half the time, it feels clunky, slow, cumbersome to use, the clients are hit and miss quality, and people (including myself) keep losing keys or identities for random silly reasons.
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 :)
Does this federate with anything, like Matrix or XMPP? If it is locked into a single software, I fear nobody will ever switch to it (I have too many chat apps already!)
I've been running Mattermost for a couple of years now and I'm content with it. It does feel a little bit clunky sometimes, but it's been stable and performant so I can't really complain. It can also feel a bit much sometimes. A bit too complex. A bit too feature-rich. But if I just ignore most of it, then it's good. I will say that Chatto looks nicer, appears to be simpler to setup and also has simpler licensing. Can it auto-update itself? That's something that's bad with Mattermost.
Matrix seems like a decent enough open protocol for a Slack replacement, with XMPP/IRC/IRCv3 being more useful for bare-bones chat transport.
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.
I think time will tell, but one of the main things I like about Chatto is just how fast everything feels, and the protocol design is a good part of that I think. Data on the wire is just very small and optimized (last I checked, I didn't look at the latest protocol iteration yet). It was already very fast with the older GraphQL based API but now it's even quicker. With Slack and Discord, every channel switch and scrolls take visible time.
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.
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.
But the point here is that you don't want the network effects. You want a chat server for people you know and explicitly invite, for a specific purpose, under your control. Maybe you want the data to never leave your colocated box and your VPN, and your server to have no public presence at all.
Open protocols are great. The software in question is OSS.
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.
This project looks great and I wish them luck. I'm just lamenting the fact that we still haven't solved the really big problem with Slack-like chat apps.
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.
No, you do want the network effects. Nobody wants to install yet another special snowflake chat client for a single community. Unless they are being forced to (like in a work environment) or are getting significant benefits out of joining that community, most people would just prefer not joining at all over installing an additional client.
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.
I don't think network effects affect the vast majority of Slack usage. Slack and Teams are mostly used as internal company communication and that is dictated from above. If a company wants to switch to Chatto their IT department will just tell all employees to do that, and job done.
There is an audience for this, and it's me and my friends.
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.
There's space for more than one self-hosted chat app in the world. Also very ignorant comment towards a project someone probably spend a lot of time on.
They have some `curl | bash` type installation, which doesn't really fit my set-up. They say "email us if you have any questions", so I've emailed several months ago and I'm still waiting for a response.
> And it’s really good hosting! Chatto Cloud is launching with fully European and European-owned infrastructure, with more regions slated for launch in early 2027
Yes, at least with the 2.0 version (which is the "really bad one"), on-device scanning would be the big issue. But then it also doesn't matter where you're hosted, unless you only allow users with some custom OS that doesn't support it on your server.
> It’s designed to be extremely easy to self-host on your own infrastructure.
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.
Can it be installed on Cloudflare or Vercel or something else that is easy/cheap/free?
I run something similar with livekit, all on hetzner. its exceedingly affordable for a bunch of people at once to use it.
This is super cool. More options is always good. Something that is confusing about the docs though... is there a desktop application? The screenshot implies there is but I couldn't find the docs to download THAT.
It's a first-class PWA currently but no native desktop apps yet.
Sounds like something I could finally build with Kotlin Multiplatform...
There is a Tauri wrapper that I built early on because I wanted the desktop convenience (autostart, separate app, etc) that Firefox+PWA couldn't offer, I use the desktop version as my daily Chatto driver. The mobile build is more of a proof of concept for now. Check it out: https://github.com/teal-bauer/chatto-tauri
Hi, I'm making Chatto!
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.
It's a really cool project and clearly you put a lot of effort behind it. I like that it's self-hosted and may try it out on my homelab. Thanks for making it!
Wow, it's using NATS! I used NATS extensively 10+ years ago, and I'm happy to hear it's still around. Our infrastructure had hiccups across our fleet of machines, but one part that always remained up and running without complaining on some dinky machine was NATS. Well, that and Redis. No complaints ever.
We are building something B2B expected to have good enough scale ... we had to choose between kafka, nats, redpanda and rabbitMQ .... We went ahead with NATS .... don't know why, but, when we went through all the docs, including setup and operational, NATS just felt right.
We are in the same decision making stage and trying to choose between rabitMQ, Kafka, NATS and some solutions built on top of Redis.
Did NATS eventually worked well?
Excellent. We already tested at okayish scale of 5 million messages per minute, with each message being less than 1KiB. Do note that NATS can easily handle 100x this scale. It's just what we had tested during initial days.
Wow!
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 ?
JetStream (not NATS) has a built-in key/value store. Relevant thread (old, from 2023): https://github.com/nats-io/nats.go/discussions/1507
someone did some benchmarks in 2025:
I have personally not used this though.
Hi, Chatto developer here.
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.)
Inspired by Chatto, I also built some prototypes on the NATS (+Go) stack and it's been a dream. Feels like a severely under-hyped technology :D
looks like a great project, want to get AI bots talking to each other
One of the reasons why legacy apps continue to live on (despite outliving their usefulness ) is third party tie-ins.
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’ve known Hendrik for years, and he is one of the most talented developers I’ve ever met. I’m confident this project will become successful very quickly. Beyond the project itself, what fascinates me most is how he single-handedly developed it by leveraging agentic coding.
I second that. I've personally known him for almost 30 years by now, and he's still one of the smartest, most experienced, and most curious devs I've ever met. All around good guy, would work with him again any day of the week.
I've never met Hendrik but the code looks cool :)
Can you share something that you found nice?
Has he made anything else interesting?
20 or so years ago him and czottmann wrote a nice little wiki software that I used, WakkaWiki. Following him/them and their work ever since. Crazy.
Pepperidge Farm remembers!
How is that fascinating? That's what makes up most of the tedious Show HN posts these days.
There is a difference between vibe coding (asking an agent to generate an app from specifications) and leveraging agents to go faster on your vision. You can still decide to control the technical architecture and decisions and just let agents type on your behalf.
A thought if you want to sell to companies, "with per-user keys that get shredded when a user decides to delete their account."
You'll need soft delete, work messages belong to the employer and not the user.
Employers may not be the target audience.
I wouldn't know. With the post mentioning teams and slack I just got the feeling it was on the cards, so I thought it was worth posting that in case it hadn't occurred to them.
Lots of non-work organisations use tools like Slack.
I would guess that in these cases you would just not allow users to self-delete their accounts? But for most users and providers of Chatto I think automatic right-to-deletion compliance sounds nice :)
Yea you probably want that too, but I don't think that's enough.
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.
Different users (operators of Chatto servers) will have different requirements for this, so it's pretty much "configurable" in the sense that eg. a business that's hosting a Chatto server for their employees can disable shredding account deletion and just deactivate accounts instead, leaving their data intact.
What does implementing soft-delete have to do with data storage though? If you just set up an S3-compatible backend like the docs offer you then have data persistence out of the box, no?
Couldn't help but smile because "chato" in portuguese means "boring", and this seems very easy to set up and use.
Here's to more boring software! :)
chudo missed opportunity
Can also mean annoying. As a general recommnedation, before naming a project or company something, always search whether it means something bad in the top 10 most spoken languages.
For portuguese/spanish, there is always a high chance of being a slang that is NSFW
Also annoyed/angry/cross.
There's a Hyundai car whose name literally means "pussy" in Portuguese and Galician x) It's marketed as something else in those territories.
Hyundai Kona :D
https://en.wikipedia.org/wiki/Hyundai_Kona
Don't forget the famous Mitsubishi Pajero (wanker)
And Toyota Venza which sound like "toilet seat" in... Japanese, of all languages...
Honda was originally planning to name a model "fitta" before they discovered what it meant for Swedes/Norwegians (same meaning as in your example)
I’m going to say Nova to that.
Personally I've always found it funny that the widely used work software is called Slack which is very close to slacking (not working hard enough).
That’s where the name comes from, no?
Searchable
Log of
All
Communication &
Knowledge
In Spanish chato mean small, like a small nose (una nariz chata). In some contexts it can mean "dude".
This is awesome! Some feedback - I can't tell anywhere from the website if there is mobile support (which is a must-have if I want to consider moving my company or friends over to this)
Looks like it's planned.
https://github.com/orgs/chattocorp/projects/1?pane=issue&ite...
It is indeed planned, but in the meantime it does also have first-class PWA support, so you can easily install the webapp as a mobile app on mobile devices. Works great on Android.
Note that to send notifications to an iOS app, the app publisher has to send them. This means that they need to run an event forwarding proxy service (this is how Mattermost and Element/Matrix and presumably some/all of the ActivityPub clients do it), or selfhosting your server means you must also selfpublish your client app via the App Store and Apple’s developer program tax.
For Mastodon, each mobile app developer needs to have a "webpush relay server" to receive Mastodon's webpush notifications and transmit them to the platform's push service. For Android, Mastodon recently added support for the latest webpush standard which allows the app developer to directly register Google's webpush endpoint with Mastodon, removing the need for a relay. In all cases, push notifications are encrypted by the Mastodon server, and decrypted by the Mastodon client, so any intermediaries (relay server, push notification service) can not read their content.
Safari finally supports Web Push so maybe you can bypass all that nonsense.
Chatto currently commits to providing a strong PWA experience that also works great on mobile (including full support for voice and video calls, push notifications, the works.)
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.
What would be really awesome is some sort of feature where, once self hosted, I can generate a package or link that will download + install + pre-configure the login. Basically a bespoke installer/setup script. that can be linked to a particular person. The goal being to make onboarding as frictionless as possible. This could have some security implications maybe (the link is shared by mistake), but for a small self-hosted instance, that seems like something that could be mitigated fairly easily. Maybe only works with local accounts or something.
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".
What would you expect that to do beyond a "here's a link to the instance, sign up there"? You can combine it with Discord-like roles and gate channel visibility and rights on that, so even if someone else would sign up you just wouldn't give them the "in-group" role for example. Are you thinking of an "invitation" type link with a one time token or something?
I’m wondering too, the closest thing I can think of is maybe Zoom? It goes from link to opening your meeting *relatively* smoothly when the client needs to be installed.
Right, I'm thinking along the same lines as what Zoom offers. Except with the additional feature that the link is custom tailored to a known, pre-configured user. So you also skip the "log in as guest or create an account" step.
Your getting started docs are extremely confusing.
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...
The onboarding experience for newly created servers isn't ideal at the moment, that is correct. It's early days and I will work on improving this.
So the UI is a Discord clone, I think that's worth mentioning. It's not a bad thing, quite the opposite: Discord nailed it in that regard.
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.
What's the point of end-to-end encryption on a group chat where the entire group can decrypt it?
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.
mass collection? Snowden?
The way they plan to make money is paid hosting.
The documentation looks very pleasing. But it doesn't seem to be free, too. Does anybody know with what framework it's made? WhatCMS says "Astro", but I guess this is too generic and there more involved.
This should be the source: https://github.com/chattocorp/chatto/tree/main/apps/docs-web...
It's Astro and Astro Starlight. I feel it looks very similar to other contemporary docs website generators.
What's the rationale for the dual licensing? It looks like the Go backend is AGPL but the TypeScript frontend is Apache 2.0.
Why not keep it all AGPL?
Backend under AGPL prevents someone hosting it as a service. AGPL specifies that hosting _is_ distribution. Therefore, anyone hosting it must do so with public code. This provides a soft form of exclusivity to run their own Cloud.
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.
AGPL stops others from running a competing cloud service using the Go backend. It does nothing for the frontend except scare off enterprise users.
You can totally run AGPL code as a service. You can run it as a service unmodified or if you modify it, you just need to make the source available.
Wow! I've tried (and failed) to implement a chat application which parries slack and it sounds like the direction you're going in with Chatto is precisely what I was envisioning.
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.
> I've tried (and failed)
Why did it fail?
Very good. I was wondering about this a while ago - lots of companies want something to aggregate notifications and perform simple bot actions, but don't necessarily want to lock into a chat provider. Having this as the frontend to a load of integrations (or even just internal chat) would be really interesting.
Yeah, Chatto should be relatively straight forward to use in "headless mode". I've seen a few users working on integrating it into their own applications as a chat backend.
I will keep an eye on this! We’re currently using Mattermost, but their pricing is a bit all over the place and targeted for enterprise so we’re still running on the, now gimped, open source version.
Additionally we’ve been missing video calls, so that’s nice that Chatto has it :)
The killer feature of Discord for me is being able to jump between communities without logging in to each of them. Open source alternatives never provide that. Does this one?
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.
Looking at the screenshot, it seems to be the case, with servers at the left like on Discord.
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.)
felt the same way so I've built one for myself that I've been using with friends and family - not (yet) open source but self-hostable https://github.com/bogpad/meepachat
Each Chatto server by design is entirely isolated, including user accounts. But I'm aware that having to email-signup on every server you want to hang out in would eventually be too annoying. I'm exploring some lightweight identity federation ideas that I hope to ship with 0.5 where you can use your Chatto account on one server to log into another server (if it's configured to allow this.)
Then wouldn't servers need to trust each other? Otherwise I could use my server to log into any other server.
> I don't need e2ee for group messages and it brings too much complexity with it.
E2EE is not mandatory and public rooms don't usually use it.
You pay for most of the complexity whether you use the feature or not.
Very cool. I don't usually get excited for new chat apps, but I like the idea of having one frontend for multiple servers instead of pushing hard on p2p or federation.
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.
One front-end for multiple servers is how you end up reimplementing XMPP (bar federation) before you know it: servers are not guaranteed to run identical/compatible versions -> you bake versioning at capability level in the protocol -> you make clients and servers degrade predictably when that happens -> you write a standard to document it formally -> you invite around the table those authors of alternative client and server implementers and boom, you've got the X in XMPP, and the XEP standardisation process and the XSF to support it.
I bet this does a kind of "iframe" thing, where you're really just pulling in full web UIs, and they can be whatever they want. That's the impression I get from the comment about phone clients wrapping the web UI because there's no guarantee about what they will actually be.
I joined the chat as well, but if Hendrik is here - we'd love to have you on the channel (https://youtube.com/@WithMultiplesAI). This will make for one hell of an episode, I think.
You asked a number of good questions there on the live call just now! I agree, you having Hendrik on would probably make for quite an ep.
Yep, would be very cool and it was a great live call
I'd like to know compared to Mattermost, what are the advantages and disadvantages of Chatter?
btw, I'm very happy to see that the Chatter backend is implemented in Go. Go is very good at these.
You can self-host Chatto with zero limitations without having to pay me.
Why are the allusions to discord and slack so coy on the Web page?
You want the actual names so that you rank when those names are searched, no?
Whimsy? ^^
Where we're going, we don't need search engine rankings!
I think this is the first sveltte project ive seen, very cool https://app.principal-ade.com/chattocorp/chatto
you would love https://www.windy.com
lol you are correct!
So encrypted at rest but no E2EE, did I read that right?
Seems like it, but since you can self host it, you still get a lot more control over the data than using one of the aforementioned hosted offerings
Yeah, there are definitely valid contexts for hosting chat like this. E2EE has the benefit of not needing to trust the host, which I personally like but I can see this being fine or even wanted for lots of cases.
Yes, Chatto's core system does not use e2ee. This is by design; if there ever are e2ee features -- and chances are good they will, in some shape -- the encryption will be layered on top of that (encrypted message payloads and such.)
Looks great! How does it compare to Zulip? we self host zulip and are quite happy with it
Looks really nice, thank you for open-sourcing. I keep a directory of opensource alternatives. Would you say this is a Discord or Slack alternative?
> You’re probably familiar with the one that rhymes with “knack”, or the one that rhymes with “beams”, or the one that rhymes with “this gourd”.
> Chatto is just like those.
from TFA. Seems yes.
I've been testing/using chatto since early on and I'd say it's both and neither. It feels much nicer to use than Slack, but as of now it's missing some of the more "Enterprise" features. I would probably say it's a Slack-like Discord? But from the architecture it would be capable of playing as a full Slack replacement.
I also maintain a Chatto bot framework and a Tauri client, need to update those now :)
What makes it nicer to use than Slack?
For me, primarily the performance tbh. Chatto just flies and Slack feels incredibly sluggish. And from the "vibes" it just feels better designed, I like the overall user experience, it feels technologically solid but also looks nice and works how I feel it should. Hard to put my finger on it exactly.
In terms of inspiration and also the market that I want to go after with Chatto Cloud, this is definitely aiming to be an alternative to Slack, Teams, Mattermost et al. I've tried to make it friendly and casual enough to _also_ work as a Discord alternative, though.
I've been trying to find a Slack replacement since Salesfarce started ruining it and I must have tried out maybe 50 potential replacements, paid and free. This is the first self-hostable, open source one I've seen that doesn't look like design is the very last item on an amorphous future roadmap. In fact, there's some really nice design and UX touches in Chatto. Congrats on the launch, I'm absolutely certain we'll move off Slack to this when the dedicated apps arrive, maybe even before.
We just installed it on our vps. All super smooth. We also enabled push on the serverside and now I get iOS notifications via the PWA. Generally super fast and snappy!
> snappiest frontend that you’ve ever used in an app like this
I tried the HQ community, the UI is indeed very snappy!
anyone tried to join lke 50+ communities with heavy updates?
Sadly I don't even think 50 communities exist at this point! :-P
I wonder how they'll handle APNS, which will have to happen eventually.
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)
Yeah, I'm working on a communications platform as a side-project, architecturally providing reliable communications is exceedingly difficult to self-host.
* 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).
I'm assuming you're talking about Apple Push Notification Service.
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.
Been waiting for something like this. Love to see the NATS backend.
I hope it's as good as it sounds. Thanks for open sourcing <3
single executable with its own frontend is the way; I followed the pattern with https://worb.cloud . Nice for users but also extremely easy to have a short debugging feedback loop
I didn't really check the code, but I'd be interested to know if it uses quic and if the connections are eliminated based on registered encryption keys.
this way it might be a bit easier to self host
So, an open-source Discord clone?
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.
[0]: https://www.reddit.com/r/DiscordAlternatives/
Saw so many open source chats happen behind (or "in") Discord. Will this allow community members to drop in and chat and Google the contents?
There are plans for making individual rooms public, allowing unauthenticated users to access them (or allowing crawlers to index the content), but so far those plans do not include any sort of write access.
Would English speakers pronounce this as "Chat-to"? To a Japanese person, this clearly sounds like "Cha-tto," which simply means "chat."
as an english speaker, i would pronounce it "chat-oh", but i'm open to correction
I don't know what the "official" pronunciation is, but I would say "Chat-o" is probably right.
At least here in colloquial "rolo" spanish people use to call "chato" (which would sound the same as "chatto") someone with a pug, snub nose
Linguist here. It would likely be pronounced with a flap/tap, i.e., it would rhyme with shadow
Super happy to see someone take on slack. We just want a performant chat with simple features.
Slack integrations are overrated. Just give me webhooks.
Zulip has been open source since 2015.
Looks great - is there any info on what server resources are actually required per feature or user count?
Still figuring out the numbers, so very hard to answer at the moment. Chatto is quite lightweight though; a fresh instance will run at tens of MB of RAM usage. RAM usage then scales with activity and CCU; on the Chatto HQ server, I'm currently seeing around 10 MB per additional connected user. I want this to be less, there's probably lots of room for optimization.
(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)
I’m wondering about privacy tradeoffs. Looks like they’re similar to Discord where the chats won’t show up in web searches and you can’t read anything without joining. But if anyone can join, it’s not like Signal either and end-to-end encryption wouldn’t make sense.
(They do have end-to-end encryption for video.)
I hope they introduce some sort of public read-only view that an admin can enable. Discord has https://www.answeroverflow.com/ and https://www.linen.dev/
This looks really nice. Great job.
Looking at adding it to the malmo.network store for self-hosters
What are the pros and cons versus Rocket.Chat?
it would be interesting if instead of making migration tools - one shot - you could do a migration then sync.
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.
While I do need E2E and SSO making Chatto not suitable, it looks pretty cool. NATS is cool as well. Hope to see it doing well.
Curious. Most places needing SSO also have legal retention requirements, making E2E a hard nonstarter. And most E2E users wouldn't want to rely on a SSO that could likely revoke their keys. What's your environment?
Chatto does have full SSO support (OIDC and some selected providers like Google, GitHub, and, ironically, Discord, with more coming in the next releases.)
- can someone kindly give us a breakdown of what exactly goes into building a chat application?
- 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?
Congratulations. This is really awesome to see. Thank you! :D
Thank you!
Would love to see mobile support, and a way to import/migrate from Slack. If migration is painless, our org would adopt this.
Both are planned, but ETA is uncertain unfortunately.
This is cool. Will try out soon.
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”'.
Needs drop in voice rooms a la Discord or Slack's Huddle
Very cool! You should request being added to https://european-alternatives.eu/
Chatto going open source means we can finally have an AI that reads our messages and judges us silently, but at least now we can read the source code to confirm it is judging us
Congrats for open sourcing it, looks interesting!
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.
I have been patiently waiting for fluxer, but honestly I just want to self host and have it available and fluxer has been sitting on that for a while
I'm the developer behind Fluxer – self-hosting is ready to use already [1][2][3], people are using it actively currently, and I'm currently working to make account switching across instances in the desktop app a reality. This, with a big voice update around the corner, will let us move much faster moving forward!
[1]: https://fluxer.app/blog/mobile-clients-and-fluxer-v2
[2]: https://docs.fluxer.app/operator/get-started/
[3]: https://github.com/fluxerapp/fluxer
Great work! Imo the most promising Discord alternative so far.
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?
Thanks! And you're right, the future federation work is what will make it possible to implement support for transferring communities across instances natively.
I love Fluxer! Hampus is cool and what he's built is super impressive.
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.
Amazing. And with SSO out of the box without weird "Oh, SSO is Enterprise only" BS.
Ah mobile app is not ready yet. I am looking for some alternative to matrix because running it with bots is a bit convoluted, i.e. you have to have limit of edits of message for model streaming or you will kill entire room. Or I never seen robots in matrix sending encrypted messages. Why bother than? Anyway if mobile will be a thing this seems like perfect thing to have for your family and friends.
I created a Tauri based app but IMO it's not ready for prime time on mobile. On desktop, it's my daily driver for Chatto. If anybody wants to contribute, the foundation (desktop & mobile) is at https://github.com/teal-bauer/chatto-tauri
Interesting but could you put few screenshots there? Of both desktop and mobile? It is really hard to invest time into installing something that you cant see anywhere prior, and it will be really easy to do for someone that is using it daily. Sorry for complaining. Seems like nice project.
For now it's just a Tauri wrapper, so it looks more or less like the mobile web / PWA except it might be easier to handle notifications and share intents etc. compared to a pure PWA play. Now that the API is settled, it might make sense to go pure native.
The Tauri wrapper was originally just for desktop convenience and the Android target was more of a proof of concept initially.
Sure I understand though, I have honestly no idea what tauri is really. Sure there is a link and it looks like some kind of web framework. Looks nice but it is hard to picture how chat application written with that would look like. I am not trying to force you to do want I want. I just think it is in a good taste to put some screenshots or even a gif. But I understand your reluctance.
Yeah its unfortunate there's an AI app on the apple store with the same name
Chatto aims to be the group chat application that you actually enjoy using. You’re probably familiar with the one that rhymes with “knack”, or the one that rhymes with “beams”, or the one that rhymes with “this gourd”.
Lol I like this
How does it compare to Mattermost?
From what I can see, the license for this (AGPL) is more restrictive than Zulip (Apache 2). So I would stick with Zulip.
Seems neat
> And you can just self-host it. For free, too! (A weird thing to write, but the OSS chat app space has become very weird in many ways!)
Wait, what? There are open-source chat apps that you have to pay to host yourself? How does that work? Or did I misunderstand?
Yeah a lot of them like Mattermost become surprisingly limited unless you pay. It's very annoying.
Mattermost's licensing is a little confusing, but from what I understand, you're only really super-restricted if you use the prebuilt binaries (which have a different license than the source code).
IIRC if you build it yourself it's pretty much all AGPL, with few limitations.
Many otherwise open-source chat apps are "open-core," they tie certain features to a subscription. Can be things like chat history, voice calls, video calls, but a very popular one is SSO and AD/LDAP integration.
How does this compare to [SOME COMPETING THING I WANT TO PROMOTE]?
Well, if they actually did a semi-decent comparison table, it would be easier.
It's a very crowded, relatively low barrier to entry, high barrier to switch space.
I don't want graphics in my chat. I don't want formatting in my chat. I don't want to see my co-workers pictures in my chat. I don't want this "modern-individual-but-non-the-less-same-y-looking" html and css driven "custom" UI that every of these apps has. I don't want emoji in my chat. I don't want all this other enshitification crap.
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.
How does it differ to Zulip?
Or matrix
I've been trying to use Matrix for years and I still hate it at least half the time, it feels clunky, slow, cumbersome to use, the clients are hit and miss quality, and people (including myself) keep losing keys or identities for random silly reasons.
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 :)
voice chat?
> "The fastest way to give it a try is through Homebrew"
for the 12 people that own a macbook, perhaps.
Homebrew also runs on Linux, it’s a common way to install minor command line utilities on a immutable/atomic distro
That still makes it the fastest way. ;-)
You can download the binaries from the GitHub release pages.
Does this federate with anything, like Matrix or XMPP? If it is locked into a single software, I fear nobody will ever switch to it (I have too many chat apps already!)
I've been running Mattermost for a couple of years now and I'm content with it. It does feel a little bit clunky sometimes, but it's been stable and performant so I can't really complain. It can also feel a bit much sometimes. A bit too complex. A bit too feature-rich. But if I just ignore most of it, then it's good. I will say that Chatto looks nicer, appears to be simpler to setup and also has simpler licensing. Can it auto-update itself? That's something that's bad with Mattermost.
looks super cool.
The fundamental problem with replacing Slack is network effects. Your coworkers and customers already use Slack. It works well enough.
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.
XMPP exists…
Matrix seems like a decent enough open protocol for a Slack replacement, with XMPP/IRC/IRCv3 being more useful for bare-bones chat transport.
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.
I think time will tell, but one of the main things I like about Chatto is just how fast everything feels, and the protocol design is a good part of that I think. Data on the wire is just very small and optimized (last I checked, I didn't look at the latest protocol iteration yet). It was already very fast with the older GraphQL based API but now it's even quicker. With Slack and Discord, every channel switch and scrolls take visible time.
Oh, and the protobuf based realtime endpoint should make it very easy to build bridges, too.
If the mission statement is no compatibility with anything else, they might break backwards compatibility with bridges frequently
Like XMPP?
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.
> Or, perhaps the asynch chat thing is a distraction and we need something asynchronous that's well proven. Like... email?
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.
> We really need an open protocol to build on.
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.
But the point here is that you don't want the network effects. You want a chat server for people you know and explicitly invite, for a specific purpose, under your control. Maybe you want the data to never leave your colocated box and your VPN, and your server to have no public presence at all.
There are things that Slack cannot easily offer.
You want the open protocol to have network effects, not a proprietary company's product.
Email worked out pretty well, while IRC failed for reasons that are probably correctable.
Open protocols are great. The software in question is OSS.
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.
This project looks great and I wish them luck. I'm just lamenting the fact that we still haven't solved the really big problem with Slack-like chat apps.
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.
No, you do want the network effects. Nobody wants to install yet another special snowflake chat client for a single community. Unless they are being forced to (like in a work environment) or are getting significant benefits out of joining that community, most people would just prefer not joining at all over installing an additional client.
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.
Isn't this irc?
Just need a client app to make it look like something else.
Like slack did.
I don't think network effects affect the vast majority of Slack usage. Slack and Teams are mostly used as internal company communication and that is dictated from above. If a company wants to switch to Chatto their IT department will just tell all employees to do that, and job done.
Matrix exists. I wrote this for my own notes: https://docs.zeropolis.net/doku.php/tech:tuwunel
Self hosted voice/video/chatroom server with RBAC, federation capabilities and encryption.
Different topic, who uses federated slack?
There is an audience for this, and it's me and my friends.
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.
I’m
> Chatto aims to be the group chat application that you actually enjoy using.
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.
most complains i see about the others are performance-related, not looks-related. and chatto is trying to be performant.
It is not looks or performance (I have no idea) I am talking about. It is the shape of the functionality — the intent of it.
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.
Then don't use it? I don't get the hate just because it doesn't fit people's use cases.
Not really hate now is it? Just questioning what i am missing in yet another of these things.
Though it does seem to (so far) be easier to host and less complicated than Mattermost, which is not nothing.
soooooo campfire then
There's space for more than one self-hosted chat app in the world. Also very ignorant comment towards a project someone probably spend a lot of time on.
Off the bat, it seems that campfire doesn't support voice/video calls. So no, not at all
They have some `curl | bash` type installation, which doesn't really fit my set-up. They say "email us if you have any questions", so I've emailed several months ago and I'm still waiting for a response.
Not knowing what Chatto is, the headline is giving "zendaya is meechee"
> And it’s really good hosting! Chatto Cloud is launching with fully European and European-owned infrastructure, with more regions slated for launch in early 2027
With chat control that may not be so great…
Is e2e encryption supported?
I thought the point of chat control was to give the eu a back door even in e2e?
Yes, at least with the 2.0 version (which is the "really bad one"), on-device scanning would be the big issue. But then it also doesn't matter where you're hosted, unless you only allow users with some custom OS that doesn't support it on your server.