> 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.
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.
But I read here every day that agents can't code. And that "real developers" spend more time fixing AI bugs than producing code, and it slows them down.
You mean to tell me smart people can leverage these tools to do things at a scale they couldn't before? Blasphemy!
Who says this? "Beautiful" vibecoded apps are a dime a dozen. Getting support or continued feature development for those beautiful apps after the developer's AIDHD moves on to their next half-baked idea is usually the differentiator between a good vibecoded app and a bad one.
Are you sure you read that here? I came back yesterday after a hiatus and I’ve been dismayed how many posts are just “yeah, I just run Claude all day” without a hint of embarrassment or shame.
I run Claude all day, and produced some good shit, but I'll admit to being thoroughly embarrassed that I haven't looked at it all, won't make it public, won't put my name on it, won't pick a license. I'm depressed about the whole thing and might take it up with a therapist.
My eyes are still rolling from GP's comment:
> he single-handedly developed it by leveraging agentic coding
I agree with this sentiment so much but before I could figure I turned into it. I'm feeling torn - it's helping me write and ship good code as I couldn't before, but it feels like I don't understand the real price of using it non-stop.
> But I read here every day that agents can't code. And that "real developers" spend more time fixing AI bugs than producing code, and it slows them down.
This is all correct, though. I haven't tried this, but I can guarantee it's a buggy, incoherent mess, same as every other vibe coded app I've ever tried, no exceptions.
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)
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.
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'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 :)
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.
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!
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.
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.
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.
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.
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.
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.
You can choose to switch your company away, maybe, but what do you do when vendors want to connect over Slack?
We really need an open protocol to build on.
You mean to tell me smart people can leverage these tools to do things at a scale they couldn't before? Blasphemy!
The slop we're seeing from people using AI is because they pump it out in a month or two and then call it a day.
A lot of garbage is also being produced and a lot of people have to clean it up, right? Hopefully that’s not too controversial of statement?
My eyes are still rolling from GP's comment:
> he single-handedly developed it by leveraging agentic coding
so, unmaintained in a year because the sole developer got bored/didn't make money from it/burned out ?
Great, I'll run my entire company on it!
This is all correct, though. I haven't tried this, but I can guarantee it's a buggy, incoherent mess, same as every other vibe coded app I've ever tried, no exceptions.
https://github.com/orgs/chattocorp/projects/1?pane=issue&ite...
Here's to more boring software! :)
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.
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.
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”'.
Slack integrations are overrated. Just give me webhooks.
I also maintain a Chatto bot framework and a Tauri client, need to update those now :)
> Chatto is just like those.
from TFA. Seems yes.
(They do have end-to-end encryption for video.)
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
[2]: https://docs.fluxer.app/operator/get-started/
[3]: https://github.com/fluxerapp/fluxer
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.
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.