mesa
supermurs
𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍I can use IRC
The fact that many Discord and IRC channels (servers?) block Matrix connections has drastically reduced its usefulness for me. When I was running my own Matrix server, I could have gotten around it by using a puppet, but Synapse is such a hog I had to shut it down, and most of the IRC rooms I want to use don’t allow Matrix proxies.
poVoqrunning your own server is super lightweight.
Not IME. Are you running Synapse? Gigabytes of disk usage and memory leaks requiring restarts.
psycotica0They’re taking about switching to Jabber/XMPP, which is what those two bridges are for, and they’re saying XMPP servers are lightweight.
It’s a bit confusing in context, I’ll admit.
Yup! Someone else pointed that out to me; I thought you were talking about the puppets and missed that you were talking about Jabber.
My bad!
I’ve been running the same matrix instance since ubuntu 18.04lts, just upgraded the virtual machine along the ride, so that has to be +6 years it’s been running 24/7.
I have not once rebooted my server due to performance reasons (like a mem leak). And like last 4 years I’ve ran the instance virtualized on a hp thin client, lately on a hp t640.
While I understand the criticism towards synapse being a complex and slow, and element being slow-ish, I don’t feel justified saying synapse would need any restarts in general. At least I have never restarted it in 6+ years and my instance has been working without those required restarts.
Yeah, I miss the irc, too. I still use it via my matrix instance.
I’ve never had to reboot the server; I had to restart Synapse because if Memory leaks.
Are you using any bridges?
Anyway, it got too expensive to run my own, so I went back to Matrix.org. Now I’m mostly back on IRC except for a couple of rooms. IRC stinks, but Matrix has been nothing but a decade of pain.
katy ✨
anon5621
paraphrandBut locked in a way where nice third party clients could still interact with them. I never used official clients after a time.
That seems to have gone away.
NegativeNull
caseyweedermanI do 1:1 videocalls on XMPP. Quite some clients implement that now. But there were no videoconferences until very recently. That’s changing, though. See Movim right now, for example.
Main 2 issues with XMPP are inconsistent clients (in terms of GUI but also features wise) and the incredibly, astonishingly, ridiculously sloooooooooooooooow evolution of the protocol through the XSF. Nothing can get in there until it’s “perfect”. Clients devs are reluctant to implement things until the extension is stable. And the best part is this approach hardly work: the best way to figure if something works is to deploy it in larger and larger scales and improve it on the way as you identify corner cases you didn’t think about. Not to review the description for months/year until it qualifies as literature…
edentI agree with all this. The thing which caused me to uninstall was suddenly being pushed lots of abusive message with disturbing contents.
When I complained about it, Matrix told me that my public complaints were hurting the ecosystem and I should be quiet.
When I complained about it, Matrix told me that my public complaints were hurting the ecosystem and I should be quiet.
Weird. I think they did some improvement to prevent those abusive messages but it took a while and it was embarrassing. Maybe it's hard to prevent them with a federated network but still, the abusive messages where basically a copy paste.
AbnormalHumanBeing
muusemuuse
swelter_spark
VeganCheesecakeYeah. I an hosting a homeserver for my ttrpg groups, but it doesn’t have any federation enwbled at all, and sign ups are invite-only.
The amount of work needed to moderate a public instance, especially with the lacking tools available, seems crazy. Also, I don’t love it that New Vector has an implementation for an admin console, that seems to be available exclusively for paying subscribers to the enterprise version of their element server suite.
I just want a self-hostable open-source alternative to the shitty closed-source IM systems I’m forced to use
I’m sticking with Matrix for now, hopefully some of the issues I’ve had will get ironed out
Snikket is the rebranded-dockerized XMPP environment (uses prosody for server, Conversations clone for Android, and Monal clone for iOS).
Worked pretty well for me in the past.
yessikgThat is what the author said they switch to, but TBH XMPP also has issues with MFA and messages frequently not being decrypted (using OMEMO) and ‘unencrypted metadata’.
I wouldn’t say that it works better than Matrix, it just has some different strengths and weaknesses.
TrihilisThe thing is… What alternatives are there? Signal can’t be trusted (on the very same website there is an article about it). I’m not using closed source alternatives, Simplex is kinda shady too tbh and I’m not even sure I could get anyone to use it.
I don’t like Matrix/Element either but sadly its the best open source chat solution we have.
PirateFrogXMPP is significantly less decentralized, allowing them to “”“cut corners”“” compared to Matrix protocol implementation, and scale significantly better. (In heavy quotes, as XMPP isn’t really cutting corners, but true decentralization requires more work to achieve seemingly “the same result”)
An XMPP or IRC channel with a few thousand users is no problem, wheras Matrix can have problems with that. On the other hand, any one Matrix homeserver going down does not impact users that aren’t specifically on that homeserver, whereas XMPP is centralized enough that it can take down a whole channel.
Meanwhile IRC is a 90s protocol that doesn’t make any sense in the modern world of mainly mobile devices.
XMPP also doesn’t change much, the last proper addition to the protocol (from what I can tell, on the website) was 2024-08-30 xmpp.org/extensions/xep-0004.html
setVeryLoud(true);XMPP doesn’t change very very often, but there’s actually tons of XEPs that are in common use and are considered functionally essential for a modern client, and with much higher numbers than XEP-0004
The good news, though, is that mostly you as the user don’t need to care about those! Most of the modern clients agree on the core set and thus interoperate fine for most normal things. And most XEPs have a fallback in case the receiver doesn’t support the same XEPs.
I’m general XMPP as a protocol is a lightweight core that supports an interesting soup of modules (in the form of XEPs) to make it a real messenger in the modern sense. And I think that’s neat! But you can’t really judge the core to say how often things change.
Most of the modern clients agree on the core set and thus interoperate fine for most normal things.
So you think it is a sane solution to mark essential features as optional extensions and then have a wink-wink, nudge-nudge agreement of which of these “optional” extensions are actually mandatory? Instead of having essential features be part of the core protocol?
But more importantly, XMPP sucks because it does not have one back-end implementation like Vodozemac for Matrix. So let alone being unable to have security audits, you are forcing client developers to roll their own implementation of the e2ee, with likely little to no experience with cyber-security.
Honestly, I struggle with this myself. On the one hand I like the diversity of clients; it feels like a sign of strength of the community and protocol that there are many options that have different values. But the cost of this diversity is that it makes things more complicated to coordinate, and different people with different values have different opinions on what a chat client should even want for features.
Something like Slack or Discord can roll out a server feature and client feature to all their clients all at the same time and have a unified experience. But the whole benefit of FLOSS is that anyone can fork the client to make changes, and the whole point of an open protocol is that multiple independent clients can interoperate, and so there’s a kind of irony in me wanting those things, but those things producing a fractured output.
So I think XMPP, as a protocol, does the best compromise. These differences between clients and servers aren’t just random changes in behaviour or undocumented features, they’re named, numbered, alterations that live somewhere and are advertised in the built-in “discovery” protocols. The protocol format itself is extensible, so unexpected content can be passed alongside known content in a message or a server response and the clients all know to ignore anything they don’t understand, and virtually all of the XEPs are designed with some kind of backwards compatibility in mind for how this feature might degrade when sent to a non-supported client.
It isn’t perfect, but I think perfection is impossible here. A single server and client that everyone uses and keeps up to date religiously with forced upgrades is best for cohesiveness, but worst for “freedom”, and a free-for-all where people just make random individual changes and everything is always broken isn’t really a community, and XMPP sits in the middle and has a menu of documented deviations for clients to advertise and choose.
As for security, that can be mostly solved with libraries, independent of the rest of the client or server implementation. Like, most clients used libsignal for their crypto, so that could in theory be audited and bug-fixed and all clients would benefit. Again, not perfect, there’s always room at the interface between the client code and the library code that’s unique, but it’s not as bad as rolling your own crypto.
I am yet to see a universal tool that is good at everything. Trying to cram all use-cases into one network results in mediocre results at best and usually even worse.
There is no reason to combine a person to person messenger like signal and community based one like discord into one network. That is why I like the Matrix approach of 1 backend and many frontends so you can have your pick of clients without messing up the protocol.