I don't get how people consider Stoat an alternative to Matrix/XMPP/etc when:- It does not support E2EE at all.- It does not support Federation at all.- It does not support video calls (but it's in dev tbf)

and just to be clear: I think Stoat is a neat opensource selfhosted chat server. It reminds me of RocketChat about a decade ago. We definitely need systems like this for the niche gap they fill.

But I don't think it's fair to call it a competitor of things like Matrix/XMPP/etc as long as it doesn't have federation, E2EE, video calls, doesn't scale past 100 servers, and isn't really battle tested at all (does it handle hundreds of large group calls?).

I hope they keep developing it, though!

@anthropy Because they’re not looking for federation or privacy, really

They just want Discord without it being Discord, but it doesn’t have people on it, so really they just want Discord

I’d personally see video calls and presence features in Forum-like software - but I’ve already been told in no uncertain terms that people just really don’t wanna use forums anymore.

What problem are we actually trying to solve, here?

@bunch_of_dergs I'm personally looking for something to be a private, secure, fully featured messaging platform, that actually scales, that doesn't have the inherent issues that centralized platforms have (like being impossible to fund and/or keep from becoming terrible/commercial/enshittified in the long term). I personally think something like Matrix is the best fit there, but I get that people just looking for the superficial Discord-like experience are easily distracted by simpler systems.

@anthropy I must admit I just don't really know Matrix well enough to properly critique it.

Solution: use Matrix more.

It's also worth mentioning there are a ton of projects like Stoat, with more features than Stoat, for example:
- Fluxer (actually has video calls, is working on federation according to their roadmap)
- Spacebar (API-compatible with Discord)
- Sharkord (similar to Fluxer, no plans for federation though)
- Mattermost (very mature 'selfhosted Slack' type of platform, channels can be synced with XMPP or Matrix rooms)
- RocketChat (Supports Matrix federation, don't let the "pro" marketing scare you)

@anthropy Like... it really seems Matrix is "the one" in terms of the momentum it has behind it.

I cannot currently think of any federated messaging system that has as much momentum behind it as Matrix - except maybe XMPP and SMTP at the moment.

@anthropy The big, big critique I keep hearing about Matrix is that its protocol is just so complex, stemming mainly from its data model being an eventually-consistent event-sourced sequence of message synced across the home servers of all participants... That correct?

(That and all the custom crypto that such a set-up involves.)

@bunch_of_dergs It seems to be "the one" to me, and XMPP doesn't have features like hosted history at all to begin with, so if you switch devices you lose all old messages (which a lot of people used to discord/telegram/etc will hate).

It has its share of issues, but I do think they're fixable, or have workarounds. For now the most obvious parts I could think of is to not use the matrix.org server as it's often overloaded, and if you want more features, try other clients like Schildichat (Next)

@anthropy I guess my question is... Are the issues that it has inherent to fundamental decisions in the protocol?

Or are they, like, fixable? And we need to just suck it up and put in the work?

@anthropy Hosted history is an essential core feature to me.

XMPP has that... to an extent... But it's janky, and it seems every modern feature is stuck in XEP hell

@bunch_of_dergs If by inherent you mean that XMPP doesn't have any history related problems due to not having this feature at all, and Matrix does, then sure that's hard to "fix".

Personally the main issues I see is that they aren't on top of important issues like Element vs Element X, semi 'deprecated' systems and libraries, security issues not always being addressed timely, etc. These are fixable, but it'll take more than just good faith, like funding and core team cultural changes. We'll see

@bunch_of_dergs In that sense, XMPP's XEPs and Matrix's MSCs are similar, though the MSCs are optional addons whereas XEPs are appear to sometimes be core changes I guess? But in both cases you end up with an ecosystem with some features being split out. I do think Matrix having a lot of features already part of its core (E2EE, history, etc etc) puts it at an advantage compared to XMPP though.

@anthropy There's XEPs for message carbons and message archiving - those are a thing. If there's no hosted history, I as a user hadn't noticed yet. It's just... always an endless list of janky XEPs for every feature.

It'd be a fundamental advantage, I think, if there's an effort to pull as much functionality as possible in larger core feature sets as opposed to being stuck in hundreds of tiny modules that sometimes compete.

Funding will probably happen now that there's even some government services and companies adopting Matrix for internal communication (haha... ha... makes it more likely, at least.)

Governance... I guess you could semi-realistically maintain a fork? You'd be building off of a solid foundation instead of a blank slate, and could have some good cross-talk between the fork and the official one for compatibility? Maybe pulling features from one into the other?

I find it funny that the issues you cite are very much not the ones I've heard about

@bunch_of_dergs The problems you've heard about are likely the result of some of the issues I've mentioned.

For instance, if you hear "unable to decrypt message", the underlying reason is often overloaded servers and issues in the libraries and clients, like I mentioned.

And well, funding is one part of the equation, but it's going to take focused work from willing developers to properly flesh out these new core systems, rather than chase exciting visible features like yet another client UI.

@anthropy My first experience with Matrix was Element very strongly pushing you to "verify" your connection.

The client fundamentally did not explain that that had to be done out-of-band. I did not, at the time, understand the very concept of verifying an e2ee connection.

And like... how does an overloaded server prevent a message from being decrypted? If it can't serve up the keys immediately that's fine, I can wait, but like... There's no guarantee in the protocol that it'll happen eventually?

@bunch_of_dergs it will happen eventually if server being overloaded is the reason for it. There are also other reasons for it, like the client not properly fetching older keys for encryption. New messages will load fine in that case. But it just goes to show building a client can be counterintuitive for security reasons.

Security in general is tough, and while there could be a lot done to improve the UI/UX around it in Matrix and associated clients, the user will always be the weakest link tbh

@anthropy An "reattempt to fetch keys" button would work, then?

So how does that work? There's an encrypted store on the server that stores the receiving keys for e2ee messages? And the clients sync the keys through there? What the client is missing is it not trying to sync older keys when it should?

As for security UX, I mean... It could've just said: "If you have another way to reach this user, you may send them this string (of emojis, even?) and ask them to check if it's the same on their side. This way you know you are speaking to the same person. This is most secure if done in-person."

There. That'd have solved my issue at the time, instead of pushing me to do some mystery thing that doesn't work

@bunch_of_dergs I don't know the exact details, but I do know that Matrix rotates the keys both for private and group E2EE chats once in a while, and if you miss a key then you won't be able to decrypt those obviously. Every client implements this differently; Element and derivatives (like Schildichat) seem to handle it fairly well.

And yea again, I think Element and many other clients could improve their UI/UX by a lot in many ways also beyond this. It won't fix everything, but it will help.

@anthropy I'd have been such a simple fix UI-wise even... Or just ignore e2ee verification entirely for users who won't understand the need or purpose for such a feature. Just go for blind trust and have verification be optional - the chance they actually got MITMd is kinda low anyway.

So... key syncing is a client-specific thing? There's no main protocol for it? I'll admit, the notion of sending something like decryption keys over the network is a very spicy notion, but I'm also getting the impression it may be unavoidable.