> 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.
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.
Well that’s just snarky and not very nice. The guy has 30 years experience as a dev according to a sibling comment so it’s not as though it’s some vibe coded junk. Why do you believe a good dev can’t use AI to assist in writing great code?
I'm not interested supporting in anyone who is willing to build on stolen property just so that we can accelerate enshittification and damage the environment. When the AI companies pay artists for their training material, stop building gas pipelines directly to data centers, and work on putting UBI in place before they try to replace all white collar labour, it may be worth revisiting.
There's a reason that believing AI is bringing a better world is a more fringe position than believing in telekinesis. The AI companies are strip-mining the commons, and leaving the world worse off for it.
The big question is: how do we tell the difference?
If 99.9% of LLM-smelling projects is vibecoded garbage, why should anyone assume that your LLM-smelling project is the 0.1%? If I spend all day digging through dogshit to find the one diamond, I'll just end up going home empty-handed smelling of dogshit.
AI tells are a giant red flag indicating to potential users not to waste time on it. Want people to take your new pet project seriously? Don't use AI! And yes, that does include even the genius 100x engineers who can use LLMs responsibly.
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
"why would you need features on the thing on which the vast majority of your company's interactions and unofficial note keeping and knowledge building is happening" is a fun question to ask, when the project in question doesn't have bot actions or webhooks.
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.
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.
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)
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.
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
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.
Prohibiting a user of your software from modifying it and using it to run their business goes against both freedoms 0 and 1.
This “users are obligated ‘give back’ the moment they make money with the gift they were given” is nonsense and anyone paying attention knows it. A business making money using free software doesn’t take anything away from the releasing organization.
The anti-commerce bent of a subset of the free software zealots hate business so much that they tried to smuggle a EULA into the free software community. It’s nonsensical. Furthermore, the AGPL has never once been tested in court.
You receive permission to use and modify a piece of software under conditions set by the creator. It is a license, not a gift. If you don’t like the conditions, use something else or create your own thing.
I will never understand these complaints. Not only do you want stuff for free, you also want to impose your preferred usage conditions on the creator. Where does this entitlement come from?
> Prohibiting a user of your software from modifying it and using it to run their business goes against both freedoms 0 and 1.
It does not prohibit modifications - it just demands that those who exercise the freedoms share their modifications under the same license, and most businesses balk at that.
> The anti-commerce bent of a subset of the free software zealots hate business so much...
The root of the problem is actually the anti-free-software bent that business zealots have, because they want to be able take code for free and make money off of it without giving any of their changes back under the same terms; open-source contributors are not suckers to be exploited. Things would be so much better if the moochers weren't trying to capture all of the value downstream of other people's work, but just some or even most of it.
> Prohibiting a user of your software from modifying it and using it to run their business goes against both freedoms 0 and 1.
Then it's good that it allows both modification and using it to run a business?
> This “users are obligated ‘give back’ the moment they make money with the gift they were given” is nonsense
But they are under no such obligation! They can make all the money they want and give nothing back. They can even modify the software to better serve their business. The only restriction is that if they do so, they have to make their modifications available. Which means they're way ahead of where they were before being given the initial software; why do you feel a software developer who decides to give the world a gift should be restricted in what gift they're giving? "Thanks for the chocolate, but the bar was too small so I didn't have enough left over for my kid to try some. Why do you hate my kid?"
> A business making money using free software doesn’t take anything away from the releasing organization.
First, that is false. They could damage the market for the original software. (And if they don't modify the software, then there's no problem in the first place.)
Second, why are you so hung up on the "making money" part, when that is explicitly allowed by the AGPL? It's just kind of bizarre -- it's a license that says over and over that you can charge for everything related to it, and you're complaining about it being hostile to people who want to charge money for things.
Thinking about it, I'm wondering if this is genuine confusion and you don't know what the AGPL is? If so, maybe start by searching for "charge" in https://www.gnu.org/licenses/agpl-3.0.en.html . It has nothing against "using it to run [a] business". There is no "moment they make money with the gift" that changes anything: you are explicitly allowed to charge for anything you like -- distribution, usage of the service, support, whatever.
That’s simply not true, and you know it. Violating my privacy with a EULA is the issue there. It’s ok to put a EULA on software, but to pretend it’s still free software is the dishonest part.
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.
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.
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”.
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.
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 :)
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.
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.
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.
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.
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 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.
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 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.
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!)
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.
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.
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
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'll need soft delete, work messages belong to the employer and not the user.
There's a reason that believing AI is bringing a better world is a more fringe position than believing in telekinesis. The AI companies are strip-mining the commons, and leaving the world worse off for it.
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?
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.
If 99.9% of LLM-smelling projects is vibecoded garbage, why should anyone assume that your LLM-smelling project is the 0.1%? If I spend all day digging through dogshit to find the one diamond, I'll just end up going home empty-handed smelling of dogshit.
AI tells are a giant red flag indicating to potential users not to waste time on it. Want people to take your new pet project seriously? Don't use AI! And yes, that does include even the genius 100x engineers who can use LLMs responsibly.
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! :)
For portuguese/spanish, there is always a high chance of being a slang that is NSFW
https://en.wikipedia.org/wiki/Hyundai_Kona
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.
This “users are obligated ‘give back’ the moment they make money with the gift they were given” is nonsense and anyone paying attention knows it. A business making money using free software doesn’t take anything away from the releasing organization.
The anti-commerce bent of a subset of the free software zealots hate business so much that they tried to smuggle a EULA into the free software community. It’s nonsensical. Furthermore, the AGPL has never once been tested in court.
I will never understand these complaints. Not only do you want stuff for free, you also want to impose your preferred usage conditions on the creator. Where does this entitlement come from?
It does not prohibit modifications - it just demands that those who exercise the freedoms share their modifications under the same license, and most businesses balk at that.
> The anti-commerce bent of a subset of the free software zealots hate business so much...
The root of the problem is actually the anti-free-software bent that business zealots have, because they want to be able take code for free and make money off of it without giving any of their changes back under the same terms; open-source contributors are not suckers to be exploited. Things would be so much better if the moochers weren't trying to capture all of the value downstream of other people's work, but just some or even most of it.
Then it's good that it allows both modification and using it to run a business?
> This “users are obligated ‘give back’ the moment they make money with the gift they were given” is nonsense
But they are under no such obligation! They can make all the money they want and give nothing back. They can even modify the software to better serve their business. The only restriction is that if they do so, they have to make their modifications available. Which means they're way ahead of where they were before being given the initial software; why do you feel a software developer who decides to give the world a gift should be restricted in what gift they're giving? "Thanks for the chocolate, but the bar was too small so I didn't have enough left over for my kid to try some. Why do you hate my kid?"
> A business making money using free software doesn’t take anything away from the releasing organization.
First, that is false. They could damage the market for the original software. (And if they don't modify the software, then there's no problem in the first place.)
Second, why are you so hung up on the "making money" part, when that is explicitly allowed by the AGPL? It's just kind of bizarre -- it's a license that says over and over that you can charge for everything related to it, and you're complaining about it being hostile to people who want to charge money for things.
Thinking about it, I'm wondering if this is genuine confusion and you don't know what the AGPL is? If so, maybe start by searching for "charge" in https://www.gnu.org/licenses/agpl-3.0.en.html . It has nothing against "using it to run [a] business". There is no "moment they make money with the gift" that changes anything: you are explicitly allowed to charge for anything you like -- distribution, usage of the service, support, whatever.
I don't think it does that, it prohibits them from modifying it and then using that mod to fork users away from the original software, aka https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
The trigger happens when someone interacts with your code over a network, such as in the context of a SaaS product.
The line is when you try to profit off of someone else's work that it becomes "not free".
Also, not free simply means it needs to be in public.
This is so that any additive features that you construct can be taken back by the original maintainers. Thus, you have no competitive advantage.
If you wanted to, through marketing or similar, compete with them, you are more than welcome, but it would be with feature parity.
I'm not so sure this very fair compromise warrants your rhetoric.
You want the actual names so that you rank when those names are searched, no?
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.
Lol I like this
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.
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.
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.
There are things that Slack cannot easily offer.
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.
Email worked out pretty well, while IRC failed for reasons that are probably correctable.
Self hosted voice/video/chatroom server with RBAC, federation capabilities and encryption.
Different topic, who uses federated slack?
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.
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.
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 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/
Slack integrations are overrated. Just give me webhooks.
(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.
for the 12 people that own a macbook, perhaps.
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.
With chat control that may not be so great…