Chatto is now Open Source
19 points by pascalj
19 points by pascalj
I heavily support reducing the scope and difficulty of making a chatting app by excluding federation. I'll give it a go and see whether I like it. Though I am a bit worried about the amount of AI-agent stuff there is in the repo.
A little interesting. At least it's written in. Go! Go. I'm very very the ones written in no.js
Chatto servers never exchange any data; there is no cross-server federation, and there are no plans for it (in fact, we consider it an anti-feature that strongly collides with Chatto’s stated privacy and GDPR compliance goals.)
They cannot be serious with this.
I mean, what would you want out of that feature? One of the key ideas behind Chatto, as I understand it, is that it's so easy to host that you can find someone you trust to host it for your social group, and then you can share in the server whatever you'd be comfortable sharing with that person. But if you add in federation, then you're not just trusting that person, you're trusting all the people that they federate the server with, and the people that they federate with, and so on. What was original a circle of trust is now a web of trust, which is much harder to, well, trust.
Why would federation require trust? Messages encryption should be handled by the clients, so the servers would simply act as message brokers. Federation helps with resilience and allows clients to be lighter. For example, in the event of an outage on one server, the people on other servers can still communicate as if nothing happened. And when you're active in multiple communities, your clients will only ever have to connect to one server, which makes push notifications for mobile devices more battery efficient.
I'm also not sure why they're claiming that federation would reduce privacy. If anything, it slightly helps with privacy, because client metadata such as the client's IP address is only revealed to one server of your choosing, possibly your own.
It's worth keeping in mind that there isn't really a good implementation of full e2ee in the fediverse right now, because doing it properly is hard. You can encrypt message contents, but you can't easily encrypt the metadata needed to route the message to the right server. You also can't easily encrypt group messages and retain any sort of message history. You also run into moderation problems.
There are probably very clever solutions to all these problems, although they'll come with their own new tradeoffs. But you can sidestep all these issues completely if you just don't federate - if you assume that each community will create their own server, and that most users will subscribe to a small number of servers, then you don't really run into the problems you're describing.
All of those problems are either not specific to federated systems or aren't solved by a centralized approach.
You can encrypt message contents, but you can't easily encrypt the metadata needed to route the message to the right server.
What's the centralized solution? Broadcast every event to every client?
You also can't easily encrypt group messages and retain any sort of message history.
This is purely about key management, no? A central server would not help with this in any way.
You also run into moderation problems.
The only one I know of is that communities must do all moderation work themselves because there is no central authority. This doesn't change here, because you are the central authority.
The problems aren't solved by centralisation per se, no. But they are solved by getting rid of end-to-end encryption, and the only way to do that safely is to have a centralised server that all participants trust. That's the approach that Chatto takes: you must trust the operator of the server you're using, but in exchange you make a whole bunch of things easier to implement.
If you don't look at it as an open forum or microblog, but as a possibly closed community/chat (like... Slack, Discord, Zulip) it is a neutral choice. Most of these are not federated.