We do not need federated messaging at the consumer app level, we need a replacement that's available at the cellular network level (just like SMS). RCS (https://en.wikipedia.org/wiki/Rich_Communication_Services) is trying to do this, but it might be too little too late.
In practice RCS is entirely run by Google outside China, the path to federation was killed around 2019 when Google decided every MNO should eventually move to Jibe if they wanted access to a global interconnected RCS, same on the client side.
I don't think it's too late as iOS finally supports RCS. But so far Google hasn't shown willingness to let unsanctioned clients connect to Jibe.
And even within the Google ecosystem, RCS access can be iffy. It was working fine on my Pixel for months, then switched its status to "Setting up..." and hasn't worked for months since then, despite me trying All The Things suggested on various fora short of factory resetting my phone.
Jibe is the only RCS backend in 180+ countries. The few MNOs that had deployed third party solutions (mostly from Mavenir and WIT) eventually killed them off once Google made clear they weren't interested in a federated network anymore.
The US was actually the only market where a federated RCS was tried at scale for a few years (the CCMI) but all carriers eventually gave in as the UX was poor and unreliable.
To my knowledge there are only two other non-Jibe RCS "islands": China (that runs RCS solutions from national providers like ZTE) and +Message in Japan. +Message is on its way out, as carriers are now pushing subscribers to Google Messages and Jibe, anticipating the iOS support.
And Apple is in on it: MNOs don't have a choice here, they now need formal agreements with Google (Jibe is paid through RBM revenue share) and IMS configuration and (de)provisioning workflows that are sanctioned by Apple and de facto tested only against Jibe.
Apple's communication around E2EE in UP 3.0 is also directly following Google's work on replacing their ad-hoc Signal implementation by MLS.
Except RCS doesn't work on anything except phones, while XMPP works perfectly fine everywhere. IM was vastly better on computers back when you could use applications like pidgin or kopete.
The time when XMPP was supported by google (and Facebook IIRC?). Running jabber for small groups was pretty simple, and you had Adium and pidgin, both were simple to use and just neat software
The problem is mobile, and specifically the need for push notifications to have reasonable battery life. The traditional model that desktop IM clients use, where they have a permanent connection to the server, is not viable on mobile. But push notifications require you to design your protocol around them and lock you into the corresponding provider (i.e. Google or Apple, depending on the platform).
I'm not familiar with real world home firewall behavior, but shouldn't you be able to leave a TCP connection open/idle with no keepalive for minutes if not hours? I'm skeptical of the battery life argument around notification lockin, particularly when I see how much Android devices light up a pihole.
I don't claim to understand the specifics, but I was a heavy user of custom XMPP clients on early Android phones, and they did require a persistent notification to keep the app (and thus the connection) alive, which did translate to measurable battery impact. My understanding is that the built-in notification manager helps with this by multiplexing and batching everything.
