hendrikmans

What people here don't seem to understand is that with this new technology - and in fact any new technology - for unplanned catastrophe, it doesn't need this new technology to be super competent, but just the involved humans to be incompetent.

The question is not "will AI ever be so intelligent that it will murder us?", but "when will some moron be asleep at the console while the agent swarm discovered that pinging the Pentagon on port 666 launches all nukes"

Hi, I'm the Chatto maintainer. What issues did you find with the source code?

I think (but do not have the data to confirm) that

- there's not as much of that happening as it _should_ yet - where it does happen, you don't typically notice it (because typically you notice when something is bad, or broken, or slow, or buggy, and not when it is none of these things.)

The former is to the most extent a function of companies still not being confident (or smart) enough in making the right decisions on where to re-invest the productivity dividends that agentic engineering yields. It's obvious that the focus so far has been on "shipping things faster", and that there needs to be a shift towards "shipping things better".

What would make Rust better for this type of app compared to Node?

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.)

That still makes it the fastest way. ;-)

You can download the binaries from the GitHub release pages.

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.

Both are planned, but ETA is uncertain unfortunately.

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)

Thank you!

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.