hendrikmans

Sir, this is a W-- a thread about Discord moving from Electron to Rust/GPUI. Why are you reframing the discussion like this?

Are you claiming that browsers, their renderers, V8 etc. are slow and unoptimized?

You are comparing Discord to calc.exe. This is not a serious argument.

But that's not what I wrote at all?

I don't understand this question. GPUI's unstable to non-existing a11y, IME, RTL etc. support is well documented.

Give me some examples, including their cross-platform story (including mobile).

> Why do I need to play videos in the chat application?

You know exactly that the moment that Discord launches a new version that no longer plays videos, people will whine about it.

> All of this can be done at the platform level. Win32 did this three decades ago.

Yeah, but they're porting to Rust and GPUI and not that.

Source?

Electron being bad is a bit of a junior- to mid-level engineer tell in my eyes, the sort of thing you'd say if you've just learned that some apps use more RAM than others, maybe built a small Rust TUI and are now wondering why not everything is using Rust. Something you'd believe just before you learn what engineering trade-offs are.

So, yeah, enjoy rebuilding complete browsers, I guess? I'm sure they'll run more efficiently than the rendering engines that have been refined and tweaked over the course of now multiple decades.

Well, unless you leave out the annoying stuff, like a11y, IME, RTL, but who needs those things anyway, am I right.

Then you find out that iterating on a fully Rust-based app is sloooow, so you add a scripting layer, maybe integrate a little Lua VM or something that lets you execute JavaScript?

Congratulations. You've built a browser, just with fewer features, more bugs, and probably higher RAM usage. Good job.

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.

Chatto does have full SSO support (OIDC and some selected providers like Google, GitHub, and, ironically, Discord, with more coming in the next releases.)

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.

Where we're going, we don't need search engine rankings!

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

Sadly I don't even think 50 communities exist at this point! :-P

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

You can self-host Chatto with zero limitations without having to pay me.

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.

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.

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.