The problem I’ve observed with XMPP as an outsider is the lack of a standard. Each server or client has its own supported features and I’m not sure which one to choose.

That’s a valid concern, but I wouldn’t call it a problem. There are practically 2 types of clients/servers: the ones which are maintained, and which work absolutely fine and well together, and the rest, the unmaintained/abandoned part of the ecosystem.

And with the protocol being so stable and backwards/forwards compatible in large parts, those unmaintained clients will just work, just not with the latest and greatest features (XMPP has the machinery to let clients and servers advertise about their supported features so the experience is at least cohesive).

Which client would you recommend?

Depends on which platform you are on and the type of usage. You should be able to pick one as advertised on https://joinjabber.org , that should keep you away from the fringe/unmaintained stuff. Personally I use gajim and monocles.

They both qualify as “open, federated messaging protocols”, with XMPP being the oldest (about 25 years old) and an internet standard (IETF) but at this point we can consider Matrix to be quite old, too (10 years old). On the paper they are quite interchangeable, they both focus on bridging with established protocols, etc.

Where things differ, though, is that Matrix is practically a single vendor implementation: the same organization (Element/New Vector/ however it’s called these days) develops both the reference client and the reference server. Which incidentally is super complex, not well documented (the code is the documentation), and practically not compatible with the other (semi-official) implementations. This is a red herring because it also happens that this organization was built on venture capital money with no financial stability in sight. XMPP is a much more diverse and accessible ecosystem: there are multiple independent teams and corporations implementing servers and clients, the protocol itself is very stable, versatile and extensible. This is how you can find XMPP today running the backbone of the modern internet, dispatching notifications to all Android devices, being the signaling system behind millions of IoT devices, providing messaging to billion of users (WhatsApp is, by the way, based on XMPP)

Another significant difference is that, despite 10 years of existence and millions invested into it, Matrix still has not reached stability (and probably never will): the organization recently announced Matrix 2 as the (yet another) definitive answer to the protocol’s shortcomings, without changing anything to what makes the protocol so painful to work with, and the requirements (compute, memory, bandwidth) to run Matrix at even a small scale are still orders of magnitude higher than XMPP. This discouraged many organizations (even serious ones, like Mozilla, KDE, …) from running Matrix themselves and further contributes to the de-facto centralization and single point of control federated protocols are meant to prevent.

public Matrix server

Let’s see how long before it bankrupts you

Would be nice to be able to run WG on the NAS directly and not need a server, wouldn’t it? I believe there are a few go/rust userspace WG servers out there but I don’t know if anyone’s using them for anything like that.

What is “old arse” to you might be blazing fast and great for someone else (potentially in a less fortunate area of this world), and besides that, no matter your or my sensobilities, if it works, it works and should be kept that way as long as it has a purpose and the hardware permits it.

Except for a marginal fraction of the top YouTubers, aren’t most of them getting paid to inject sponsored links and from donations/patronage these days? It seems that the deal you are referring to has been off the table for a majority of YouTubers for a very long time now, and I don’t see why other platforms wouldn’t be as good, or even healthier than YouTube to provide them that kind of revenue.

I can’t pretend to know the future, but if you read between the lines and the justifications provided, this isn’t really about AGPL per se, but about Element brokering AGPL exceptions. Practically we can expect all kinds of forks with opencore options that might enshittify the user experience in different ways, and further solidification of Element’s single-handed control over Matrix (which had been a prime concern for many years). Matrix is by the day closer to the closed-source centralized silos it was first pretending to oppose.

Matrix problems become unmanageable at scale, but the effects of the underlying complexity can be felt long before: https://telegra.ph/why-not-matrix-08-07

If you read between the lines, Matrix 2 is practically about handing the client state over to the server (what they refer to as “sliding sync”). Realistically, this is an admission that the protocol is too complex to be handled efficiently on the user’s devices. I’m not saying there are not clear benefits (and new trade-offs) to the approach, just that in the grand scheme of things the complexity is shifted elsewhere (and admins foot a larger bill).

Yup, like pretty much everyone else :) https://nlnet.nl/project/XMPP-MLS/

Please, don’t recommend pidgin, it’s a security hellhole, and a pretty terrible XMPP client at that. If you want something with a similar vibe, check-out https://dino.im/ or https://gajim.org/ if you are more on the “power-user” side of things :)

I assessed XMPP vs Matrix about 8 years ago, and strikingly, the basis on which it didn’t make the cut still applies today. Here’s what I responded to a sibling post: https://programming.dev/comment/5408356

In short, Matrix dug themselves into a complexity pit with an inadequate protocol, survived for a while on venture capital money (upscaling servers and marketing at all cost), all of it dried up, and now they are in financial trouble. Matrix won’t disappear overnight, but is definitely losing the means to run the managed instances and the client/server ecosystem.

Neither XMPP nor Matrix will ever become “the next WhatsApp”: the current internet has seen too much consolidation for the tech majors to permit it (and open and federated protocols can’t compete, do not have the marketing budget nor the platforms to promote their software, but I salute the EU’s Market Act attempt to shake-up the status quo).

But that doesn’t really matter IMO. What (I believe) is important in the grand scheme of things is that such protocols remain alive, maintained and secure, so that:

• small-scale instances can flourish and contribute to a more resilient/efficient internet (think of family-/district-level providers ; this is the kind of service I personally offer: family members and friends at large appreciate that the messages and data that we exchange aren’t shared over some cloud or facebook server for no good reason)

• IM identities can persist over time: if you are a business or an individual, you may want to look into having a stable/lasting contact address, that will survive the inevitable collapse of facebook/whatsapp/instagram/… If you are old enough, your current email address probably existed before facebook. Why not your IM address?

And yes, I hear you, this is rather niche, but what got me there (and on XMPP in particular) is having been long-enough on the internet to become tired of the never-ending cycle of migrations from service to service. More and more people will have a similar experience as time goes, so this niche will only grow :)

Edit: Sorry, I responded to the wrong parent.

I don’t believe Matrix is better positioned than XMPP to succeed. On a technical aspect, Matrix hasn’t managed to stabilize its protocol, and they’ve been a decade into it. This has resulted in only a single organization being in charge of the protocol, the client and the server implementations. This isn’t sound, this isn’t sustainable. And now, unsurprisingly, this organization is in a financial crisis, has lost important customers, has no budget secured to maintain its staff in the next years, and recently underwent a major licensing change that we can only interpret as a shift towards an opencore model at the detriment of the regular user.

Yup, that’s a big reason why centralized protocols aren’t sustainable. XMPP is 25 years old (which is older than almost anything else on the contemporary internet) and thriving. Unfortunately, judging by the cycle of messengers coming and dying, and people still being eagerly part of that, this isn’t something that people value very much.

If you are curious, you should give XMPP a shot, it’s equivalent to Signal in terms of encryption, but anyone can host their own. Signal is ideologically opposed to anyone but themselves being in control of your account, and because of that I don’t want to trust them.

Yeah sure. I’m not the only complaining as you can read on this post

I’m not saying that you are the only one complaining, but from what I can tell, most people in your situation are deploying their instance from “cookie-cutter” docker images. In practice, it often means that the same machine end-up hosting multiple web servers, database servers, application servers, etc etc. And those servers are developed around heavily-optimized event loops that assume direct access to the full server resources. So if you want predictable and good performance, there’s no way around tweaking some knobs and be very mindful of how each and every service is deployed alongside the next one. And of course, you can’t trust someone else to know better than yourself what’s running in your box (not even the nextcloud developers) and which service should get preference over what under heavy load.

Nextcloud has that against itself that it uses advanced php features and large objects that need to be cached at different layers. That makes it a slightly more complex app than your go-to php CRM, but it’s not unheard of either (you’d be at the same spot hosting a large mediawiki or wordpress).

Does that make it garbage? Well, you are entitled to your own opinion, of course.

Also your comment tells me that you’re full of shit, because you’re implying that both a generic Docker setup and mines are all shit. You can’t have it both ways. What are you suggesting? That the NC guys made a bad job out in their Docker images?

Do I deserve the insult? I answered the docker part, though. In general, I’d say that you are better-off not using docker in PROD , unless you have the time and energy to spend rebuilding images to make them fit your pre-existing deployment (what nobody does), and then invest the time in fine-tuning through multiple containers (which very much goes against the “fire and forget” mindset of most docker users).

How many users? How much data?

About a dozen, 2TB, upwards 700k files

Btw do you use the webmail at all or are you about to tell me that these screenshots are hallucinations?

I’m definitely not using the webmail. If you have performance issues, you should rather start with just the “core” (i.e. files) and add on incrementally.

And again, I’m not saying that nextcloud doesn’t deserve being optimized, or somehow be made more foolprof. I too went through a phase of “that can’t be real, this cannot be that slow” and walked my way out of it.

That might tell us more about how badly your php process manager and/or db connection handler is set up, seriously. I run nextcloud “natively” (no docker, no nonsense) on hardware that was modest 15y ago (Intel Atom/2GB RAM), and it’s pretty good.

Couldn’t you just install nextcloud and none of the apps you don’t need? I mean, it’s pretty modular…

Yup, and I remember clearly a whole army of plausibly state sponsored shills downplaying/voting the story