I’m an XMPP fan because, warts and all, it’s an open standard with multiple implementations and it’s super lightweight. I use Dino on desktop and Monacles on my phone, and I run a prosody server off a VPS. The server has never gone down, ever. It’s a small deployment, though. Bridged to Slack with a few friends. I ran matrix before, but it was a tad slow for my use case.
All the protocol criticisms are mostly accurate. And the majority of clients still lack features I miss. But honestly I’m about to give my Mom (a 70 year old woman) a login to my server, because she and I chat on Slack all day, and I think she’d be able to make the jump, and I want to own those conversations for posterity <3
Many are familiar with the blow that big tech gave XMPP when they stopped federating. I’m sure they had their reasons. But I also have a half-baked sociological theory: after 2010, hatred of XML was on the rise. Especially XML network protocols. Can you imagine anything less sexy?
And I do think XML is a problem for XMPP long term. A couple of months ago I had some idle daydream about working on a CapnProto->XML translation library. https://github.com/capnproto/capnproto/discussions/2137 Not because I think CapnProto should become XMPP 2.0, but because I thought maybe if there were a bunch of canonical protocol translation libraries it would help client implementers write bridges or storage implementations or whatever. I thought about it for an afternoon then went and did other stuff (ADHD, fwiw).
As a lover of half-baked sociological theories, I think that it’s a much simpler story of embrace-extend-extinguish. :-P Once Google Chat got enough of a user base, they didn’t need to federate with anyone anymore, and then once everyone was using GMail anyway, Google Chat didn’t need to exist to draw in new users anymore. Simple as that. Android phones provided a better avenue for a captive audience anyway.
Federation was never a user acquisition strategy for Google. They had most of the users already. It’s just that Google back then believed in sometimes doing the right thing because it was right. Leading the way. But then they moved into their kill every project after 6 months era and it die just like almost every other google service.
Overall it was positive for the network. I don’t think most of my family would be users today if they hadn’t got a taste with Google at the time. Would have been nice if it stuck around, but no ill will from me
For anyone who doubts this: Google integrated Google Talk (XMPP) with GMail. Anyone who had a GMail account automatically had a Google Talk account. Only a small fraction ever used it, but GMail was on well over a hundred million active users and XMPP was on around five million. And GMail was rapidly growing.
And I do think XML is a problem for XMPP long term.
Does this really matter?
Today the web works by passing unbelievable amount of unnecessary data,
yet no one bats an eye.
There are web services that can be replaced by simple strcat(). Is XML
really some kind of a problem, especially when it can be simply
compressed? (a lot of binary formats are really zipped XMLs, for example
MSWord’s documents, Excel spreadsheets, 3d models in various formats,
etc)
Haven’t scrolled down that far, but I’m assuming you’re referring to how it was plainly designed by somebody looking at the XML spec, then at the SAX parser spec, and then saying out loud “I have a cunning plan, sir”.
A more rigid core standard, actively keeping up with new technology may have delivered XMPP’s federated dream. In reality, each sever supported a different feature set, while lacking common features every other chat app offered. As mobile technology transformed, XMPP stayed still. Pidgin worked on Google Talk, before an XEP brought (necessary) OIDC authentification and those 3rd-party clients couldn’t keep up.
One thing I don’t know how to do is edit messages further back from my most recent message. This is with the full understanding that I can’t expect those edits to propagate to all federated clients. However, I’m wondering if there’s support for this, even in principle.
The other concern is more vague and is really about a consistent UX around rich text authoring and rendering. It’s just not as nice to try and format multliple lines, bullet points, or code blocks in the clients I’m using.
I’ve never tried Snikket, fwiw. Also, I’m actually happy with my XMPP experience.
Yes, recent releases of Cheogram Android for example support editing any of your messages as far back as you like.
So you want a rich text UI with eg a formatting toolbar, not just some interpretation of * as bold etc. do you think that makes sense on mobile too or more of a desktop UX in your opinion?
Mattermost might be worth a look then (admittedly another service to run) because it’s basically self-hostable Slack. Has a decent user experience and the (iOS at least) mobile client is pretty good.
I should evaluate XMPP again for my private messaging needs. I’m running a Matrix server right now, but XMPP seems a bit more “settled”, for lack of a better word. I wonder whether there’s a significant difference in security levels.
XMPP servers are designed with considerate defaults to discard after X amount of time and the data that’s sent to the client is offloaded to the client itself. Only downside is if you will be migrating data you will do it for the client and not for the server with the current client implementations. Many people I know are skeptical about hosting Matrix servers because the server will mirror and/or cache a lot of data and you can’t remove it cleanly.
I was around back then, and I assure you XMPP was no gem. :D Imagine an XML document that never ends. It had minor success when google absorbed it and then killed it (as they do to all projects), but the protocol was too heavy to get much traction outside of that. These days you would use something much simpler, like linefeed-terminated JSON or cap’n proto. [edit: I see these are already popular comments]
But I don’t want to yuck anyone’s yum, and I think if there’s a community that’s still maintaining and updating XMPP and having a good time, more power to them. It was the 2nd-weirdest chat protocol I’ve ever had to implement, and that probably makes it like a good classic car.
Imagine if IBM had been more successful with its early push for XMPP for the IoT niche and how many permanently vulnerable XML parsers would be hiding in smart deviced homes across the globe.
I maintained jabberd for the dorms at university when it was trending. Oh the joys of a 5kloc .xml config file and no failing line output on parser error. The plaintext storage of user credentials for the bridges was also not the best of choices. With less moral fibre in the diet one could’ve caused quite the mess with those.
With less moral fibre in the diet one could’ve caused quite the mess with those
On the plus side, at one point I realised that was the only place that my MSN Messenger login credentials were stored, which proved to be quite useful when I wanted to log in with the official client.
End users do not care nor know of the details of the protocol.
It didn’t succeeded because people favor systems where they provide their username and password and get their personal data at their fingertips. Contacts and message history. Message history lives in the clients. So if you would talk with a friend at home, then join at your work computer, context would be lost.
This is the same reason everyone moved to hosted email. And I would wager 99%+ of all email users use webmail. We should not underestimate the power of convenience. Richard Stalman does understand it but rejects it. He says that one should not let convenience deter you from your freedoms. But convenience is freedom too. What I am getting at is that even understanding convenience RMS essentially failed to win over it.
To build open systems that succeed we must not build them open at the expense of convenience. It won’t work. XMPP being just an example among many.
You’re already giving too much credit. IMHO it died because the clients either had major problems on mobile (Android ones sucked your battery dry, iOS.. not even sure and the desktop ones were all not-great). Too lazy to dig it up but I’ve written this story up many times. First I had 20 fellow nerds on jabber and then one by one they switched off their servers. Many migrated back to IRC even.
There was no extinction event (the google thing certainly didn’t help, but most people were too pessimistic about that from the start), it was just a mediocre experience for many years.And I’m talking about the people running their own servers here, not some rando casuals. (No ill will intended, mostly for hyperbole).
TBH back when I used XMPP, Pidgin seemed like the “flagship” desktop client, and it worked very well in my recollection. By the time I got a smartphone, XMPP was already pretty clearly in decline, and I had already fallen back to IRC because I didn’t have anyone left to talk to.
Edit: but now thinking back on it, I only ever used it for plaintext 1:1 conversations. I do have a few vague memories of running into some rough edges trying it for “MUC”; I was left with the distinct impression that multi-user chats were added on as an afterthought.
Pidgin was a popular choice, but it was never a good choice since it is by definition a lowest common denominator client among the various protocols it supports
yeah, maybe I was a little unfair to Pidgin, it kinda worked. So there was a usable client on Linux and Windows (and iirc Adium on mac). But mobile was the kicker. I got my first Android phone in 2009 and I felt more on the early adopter side there (it had the older bad screen. it was cool but not awesome) and the time I’m talking about is probably 2008ish to 2014ish.
I know, I’m not passing judgement, just trying to provide historical anecdata.
I’d really prefer if I’d have xmpp instead of whatsapp but still, Matrix seems to just fill the niche of onboarding non-technical people a lot better than anything I personally tried.
I haven’t made a serious evaluation of Pidgin in this decade and was definitely speaking in the historical context above. But circa “google xmpp was a thing” the purple ecosystem lacked for example ability to target a specific resource (not a thing generally wanted now, but was at the time), ad hoc commands and other sub things needed to interface with xmpp services beyond chat, any of the pep flavoured stuff like user tune and mood, etc. I used Psi at the time to get access to all these features.
I don’t say the above to say that Pidgin didn’t work for what it was. But I definitely had contacts who used it and I would gripe at them about how they were missing out on cool extras.
These days I have been given the impression by customers that Pidgin lack some modern fundamentals like support for server archive sync, but as I say I haven’t evaluated that personally.
Part of this was that the JSF did not build a reference client library. They initially had a reference server (jabberd), then decided to completely rewrite it (jabberd 2, which didn’t support transports and so for a while jabberd 2 users ended up also running a jabberd 1 instance to run each transport), then they moved to eJabberd as the reference implementation. This wasn’t perfect but at least there was one reference implementation of the server and JEP / XEPs that wanted to become standards track needed to be implemented in that server.
On the client side, it was very different. There really needed to be a permissively licensed client library that any client could use and that all new standards-track proposals needed to be implemented in (ideally, in addition to one other client with interoperability between the two). In the absence of this, new features were added in one random client and never got to interoperability. Few things advanced to standards track.
This led to a situation where there were twelve competing XEPs for important features and every client implemented one of them.
XMPP supports messages on multiple machines & history syncing with clients (which are a part of the Conversations compliance suite: https://compliance.conversations.im/tests/)
The only part that hasn’t been convenient is when OMEMO keys expire for other users when trying to join a client that hasn’t been opened in a while. …But this isn’t specific to XMPP, I had it with Matrix + Element (browser) this morning having messages not encrypted for my client. The difference was that XMPP I can get this message immediately instead of blocking the UI for 3 minutes on server syncing to then deliver me errors that messages aren’t encrypted.
Take a look at the date on those. 280 is the older one and is from 2010. I started using XMPP (Jabber, as it then was) in 2001. I started using ICQ in 1997, so there was less time between my first use of any IM protocol to switching to XMPP than there was between my starting to use XMPP and XMPP gaining a standard for message synchronisation (and the implementations came later). Google Talk launched in 2005, so this is five years later.
By 2010, XMPP was well into decline. I think I shut down my Jabber server in 2014, but no one had used it for a few years before that (it had about twenty users when I set it up, they all moved to other things and I stopped using it because I never saw any online contacts).
The extensible protocol got extended (for over a decade) to support features the parent post alluded to being missing. Whether or not older XMPP/Jabber met modern expectations a decade prior to these XEPs isn’t relevant to if it can meet user needs in 2024.
It is, because the user needs evolve over time. It took until 2010 to meet the needs of 2005 users (by then, logging in from multiple devices was common and lack of history was annoying). It’s now 2024 and user needs include:
End-to-end encryption that works with no configuration.
Metadata confidentiality.
Voice and video calling with end-to-end encryption.
And some of these are kind-of supported by the protocol, but not well supported by clients, the middle one can’t be added without a complete redesign.
I will always have a soft spot for XMPP. I was involved in the standardisation effort back before it was called XMPP, wrote two clients, and my involvement with XMPP got me the contract for my first book (stpeter had a contract with Pearson to write a book and didn’t have time so put me in contact with his editor to do it instead. His editor decided not to go ahead with the book, but asked me to write a different book instead). But it was clear by the time these extensions were added that the protocol was not the right design and that it could not be fixed by adding more things, it needed some fundamental changes from the ground up.
But it came to meet the needs like it could adapt again. As mentioned earlier, I have the same E2EE issue with Matrix–which also has metadata leaking issues. I use the voice/video calling with my partner since it is self-hosted & I can trust my own TLS connection even without E2EE, or Mumble when trying to voice chat with multiple folks, but I can’t say I need these as often as text. So is SimpleX the alternative albeit immature?
I’m glad I’ve reached the age where we’ve gone full vinyl records on XMPP. I loved XMPP, spent years using it as a work chat protocol and helping to run the servers. It didn’t die because people were desperate to pay for Slack or because Google removed it from whatever their chat client was that week.
It was just a bad user experience. Multiple active devices wasn’t a problem that ever got solved in a great way. Instead the first online device won and got the messages and the other devices would get the messages filled in (which was the vastly improved version, for years it was first device won and everyone else suck eggs). Obviously in a world where everyone has a smart phone and a laptop that worked about as well as you think.
Honestly the server part was fine, like it scaled from 5 to 200 employees well. The clients were just pure amateur hour. They either didn’t have all the features we needed (which, not their fault, they were almost all add-ons mostly handled by the client) or they were the sole work of one open source developer which is not a sustainable platform to pick. Even in the paid arena it was hard to find something that worked well enough.
I still believe that XMPP could be redone better, and would be much simpler. But I don’t know enough about IM protocols and networks to suggest how. And it wouldn’t directly benefit any actual users, just server and client implementers, and since there’s already good servers and clients for it then the real benefits are pretty tiny.
I worked on XMPP back around the time it started to be called XMPP. There were a bunch of warts in the protocol even then:
The core has three elements. Presence is broadcast with coalescing (if you send two presence stanzas, the recipient may see only the second). Message is unicast (group chats are implemented via relay services), unidirectional, and queued. Info-Query (iq) stanzas are request-response. These are all designed for specific uses, rather than providing primitives that higher layers can build (MQTT or CoAP, for example, go the other way). Eventually, there was a generic publish-subscribe extension and then Personal Eventing over PubSub (PEP), which was a huge spec but provided a generic way of building a bunch of things people wanted. In hindsight, a PEP-like mechanism should have been part of the core protocol and a bunch of things in the original RFC should have been layered on top of PEP.
It uses a bunch of XML features, but only kind of. You didn’t actually need a full XML parser (it explicitly didn’t require support for entities and some of the more fun namespace things), but then people wanted to embed other XML documents in it (which is the main selling point of XML, after all) and these could hit corner cases. This also meant transferring any binary data hard and it usually ended up being base64 encoded.
A bunch of things are hang overs from other IM platforms. For example, messages can be message or chat messages, because ICQ had an email-like UI for longer messages and a chat UI for short ones. Most XMPP clients treat them the same.
In spite of this, a bunch of things that should be core to a modern IM protocol were not included. For example, for a very long time the way of providing an avatar was built on top of a standard called vcard-temp (with the -temp indicating that they knew it should be replaced. It was eventually). This provided an iq interface for fetching an XML-encoded VCard. The VCard could contain a base64-encoded avatar. You’d then also put the base64-encoded hash of the avatar into your presence messages. This, unfortunately, meant that presence messages got quite big. This matters less now, but back then an expensive phone plan had 25 MB/month of data. As an XML-based protocol, embedding any binary data was a bit painful.
File transfer and audio / video calling were also layered on top. There were a bunch of competing standards. There was also a non-standard one that Apple implemented in iChat. Google basically steamrollered over everyone by dropping Jingle, which was a massive family of extensions that supported stream negotiation between peers and then things like audio, video, file transfer, and so on on top of this. Over 50% of XMPP users at the time were on Google Talk, so everyone just implemented Jingle to be compatible.
More generally, while it would be unfair to claim XMPP was not designed with security in mind, it was designed with a late ‘90s threat model. There are now end-to-end encryption standards, but they don’t protect any metadata. These days, end-to-end encryption and a decent amount of metadata protection, and a threat model that assumes server operators are malicious, is table stakes for an IM protocol.
And that’s part of the problem with XMPP: Is it an IM protocol? For some people, the answer is ‘of course’, but a lot of the deployments were nothing to do with IM. They were happy building control and monitoring systems on top of something that provided reliable message delivery and message coalescing for arbitrary XML snippets. To these people, XMPP was a more easily extensible MQTT alternative. It ended up not being a great fit for either use case.
a lot of the deployments were nothing to do with IM. They were happy building control and monitoring systems on top of something that provided reliable message delivery and message coalescing for arbitrary XML snippets. To these people, XMPP was a more easily extensible MQTT alternative.
I find this slightly funny with the knowledge that Facebook Messenger is (or was, I cannot tell) based on MQTT.
These days, end-to-end encryption and a decent amount of metadata protection, and a threat model that assumes server operators are malicious, is table stakes for an IM protocol.
Did you have an IM protocol in mind that meets those qualifications? And what is considered a “decent amount of metadata protection”?
Signal is the gold standard on that axis. The only metadata that they can record is the last time you connected to the network and from what IP. The down side of Signal is that it’s a centralised protocol. Getting the same guarantees and some form of federation is much harder.
Any thoughts on this David? Don’t you think it’s important to get right if you’re going to go around saying it’s “table stakes”?
As far as I can tell, the thing about only recording the last time you connected is a promise, not something enforced in the protocol. It reflects gravely on the project that they allow this misconception to flourish; the president even said Signal protects metadata in this paywalled interview. So I get concerned when I see Signal raised as the “gold standard” and this largely fraudulent metadata protection deployed to discredit alternatives.
There are now end-to-end encryption standards, but they don’t protect any metadata. These days, end-to-end encryption and a decent amount of metadata protection, and a threat model that assumes server operators are malicious, is table stakes for an IM protocol.
You don’t have any comment about what led you to write that and whether you should retract it?
You don’t seem to care about this, but if anyone does here’s the upshot: “Anyone who cares about metadata resistance should look at Cwtch, Ricochet, or any other Tor-based solution. Not a mobile app. Not XMPP. Not Matrix.”
The server is not actively malicious but may be subject to law enforcement requests in unfriendly jurisdictions or may be compromised.
The server is actively malicious and is trying to reconstruct data that the protocol hides.
The first matters more to me than the second (your quote is related more to the second). Let’s compare how Signal and XMPP stack up here (I’m not an expert on Signal, but I have implemented XMPP multiple times and participated in its standardisation).
First, let’s look at how contacts are stored. Signal, I believe, stores them only on the client (which is a bit annoying because they aren’t sync’s when you add a new device, I’d be happy if they stored it encrypted on the server). In contrast, XMPP holds your entire roster in plaintext on the server. For both threat models, this means that XMPP can give an attacker complete info into your node in a communications graph. This is bidirectional. It stores both people you have added and people who have added you, so it gives a lot of information if someone just takes a single snapshot of server state.
In XMPP, this is required for core features of the protocol to work. The entire presence model is built around it. When you update your status, you send a message to the server and the server then sends a copy of it to everyone who has the right setting in your roster. I am not aware of any XEPs to even try to encrypt the payload of these messages. Your online status is entirely plaintext as is any status message. Retrofitting encryption would require key exchange when you add someone and would require every client to agree on the encryption standard. Even with that, the source and destination, and the fact that it’s a presence stanza, are all visible to both servers.
Now let’s consider single point to point messages. In XMPP, these are now (optionally, if everyone does the right thing) encrypted, but they metadata is plain text. The sender and receiver are both visible to both servers as is the size of the message (newer standards add padding to avoid side channels here, older E2E XEPs did not). Any undelivered message is stored in a queue on the sender or receiver’s server and so a snapshot can find all of the messages that people have sent to you that you haven’t received. Again, all of this is required by the protocol and so a server run by a non-malicious administrator is vulnerable to this kind of leakage.
As I understand Signal, each sender-receiver has a separate key pair and the messages are put in a mailbox associated with the receiver’s key and the sender is part of the encrypted metadata. This is where the difference between the two threat models matters. If the server is malicious, it can correlate the message delivery with the recipient’s mailbox and the correlate the mailboxes that the recipient asks for, but it can’t do that post facto. If a message is in a queue before the server is compromised, it can’t retroactively discover who sent it. It would be possible for Signal to improve this by having clients send messages to random mailboxes periodically with invalid encryption keys. These would then be downloaded by random clients, fail cryptographic integrity checks, and be discarded. I’m not sure that this is worth it though for the small gain. Something similar is not possible with XMPP.
Now consider server-side message history. With Signal, this is not stored (which is annoying, and I’d also be happy if it were stored encrypted. Instead, they require client-side backups). It wasn’t with XMPP either until around 2010, but after that it was added. One of the motivating use cases was web clients, which have no local storage. This means that the message store is also unencrypted. If you’re using one of the E2EE XEPs, the payload is encrypted but all of the metadata remains plaintext.
When Signal had had to cooperate with law enforcement, the only thing that they’ve been able to provide is the last connection time and the account creation time. The protocol doesn’t require them to maintain anything else, which is very different from XMPP. In the first threat model, that’s all you care about. In the second threat model, you might care that they could additionally log the mailbox slots that your account uses and therefore build a connection graph, but if they did then this would show up in their responses to search warrants (which they publish as soon as they’re unsealed).
Signal is not perfect. I don’t like the fact that they conflate identifiers and capabilities in stupid ways (XMPP does this too, but it doesn’t claim to be secure and private). I don’t like the fact that they’ve made the client libraries GPLv3, which has prevented alternate implementations (and the fact that they’ve put things like disappearing messages, which rely on client support, in the protocol with no possible mechanism for enforcing it). It remains far better than the alternatives though and, as I said, retrofitting XMPP to give the same baseline security guarantees would require you to replace everything in the core protocol.
Would have responded sooner but Lobsters didn’t notify me. I think I get what you’re saying so here are some counterpoints:
I don’t see a distinction between a compromised server and a malicious server. in practice your distinction is between security compromises that occur at a point in time and those that are ongoing, and it seems naive to think that the latter are so uncommon; see PRISM and room 641A. I would be interested if you could unpack why you care about one type of compromise more than the other. It’s certainly out of step with your earlier statement that “a threat model that assumes server operators are malicious, is table stakes for an IM protocol.” That threat model is generally what people have in mind when discussing metadata protection as well.
I don’t consider contact storage, presence, and message history to be “core features of the protocol,” and it would be trivial to set up XMPP without those things, but I grant that it’s an issue with the most common implementations.
If the server is malicious, it can correlate the message delivery with the recipient’s mailbox and the correlate the mailboxes that the recipient asks for, but it can’t do that post facto. If a message is in a queue before the server is compromised, it can’t retroactively discover who sent it.
It sounds like a malicious server actually can do that post facto if it continues operating maliciously while the two parties exchange additional messages. The conditions under which this actually makes a difference seem rather contrived: A server is compromised after a message is sent but before it is received, then no further messages are sent until the server stops being compromised. Do I have that right? This is the type of protection that you’re saying is table stakes?
When Signal had had to cooperate with law enforcement, the only thing that they’ve been able to provide is the last connection time and the account creation time. The protocol doesn’t require them to maintain anything else, which is very different from XMPP. In the first threat model, that’s all you care about. In the second threat model, you might care that they could additionally log the mailbox slots that your account uses and therefore build a connection graph, but if they did then this would show up in their responses to search warrants (which they publish as soon as they’re unsealed).
I don’t share your confidence that it would show up in their unsealed warrant responses, or that the instances of cooperation that we know about are the only ones that have happened. The public desire for E2EE grew out of the Snowden leaks so this credulity seems out of place to say the least.
It remains far better than the alternatives though and, as I said, retrofitting XMPP to give the same baseline security guarantees would require you to replace everything in the core protocol.
Maybe for your threat model, which still remains obscure to me. One thing XMPP has over Signal is that users can chose a server that is less likely to be compromised by whoever they are worried about; e.g. if they want to hide their metadata from the US government they can pick a server somewhere outside the reach of US agencies. This extremely basic fact bears repeating. XMPP users can hide their metadata from the US government; Signal users can’t.
It’s also worth pointing out that Signal is not an alternative to XMPP for desktop use. Not having a smartphone, I can use XMPP but I can’t use Signal.
The only metadata that they can record is the last time you connected to the network and from what IP.
So the Signal server is not able to know who is talking to whom and when? The only techniques I’m aware of for hiding that are onion routing and continuous transmission of messages between every client as in Dissent. Oh there was also Vuvuzela; I forget how that one worked… How does the server manage to deliver the message if it doesn’t know who it’s going to?
However, Signal’s security policy can sometimes be confusing, and some
of their features seem more like security through obscurity. For
example, the fact that there is only one client available feels like it
walks over the line between usability vs. security. After all, “in a
perfectly secure world, nobody would be able to use anything”.
Also, phone number requirement to improve privacy and security, and it’s
OK to everyone? Sometimes I feel like we’ve lost touch on what is
secure, what is private, and what is public.
Sealed sender definitely doesn’t hide the identity of the recipient, but maybe it’s what @david_chisnall had in mind. It certainly leaks more metadata than the last time you connected to the network and from what IP though.
Sealed sender seems like a perfect example of the confusion around Signal’s security model. As far as I can tell it doesn’t hide the sender in practice because Signal can still see sender’s IP address and can build a near-perfect mapping between users and their last used IP address. In theory maybe you can deliberately share IP addresses between a few accounts with the right VPN setup providing a small anonymity set for the sender, but that’s still largely broken if there’s an ongoing conversation where Signal sees the recipient of every message. Nobody seems willing to argue that this mostly useless security enhancement is worth the complexity. It seems like Signal added it mostly because it’s a fairly novel feature that they can write a blog post about and claim that they’re “raising the bar.” In other words they’re willing to add complexity that provides little practical benefit for marketing purposes, which is awfully concerning for an app that claims to be suitable for security-critical applications.
One nice thing with XMPP is that it has a pretty simple core protocol (RFC 6120) and then extensions on top. While a modular nature and managing backwards compatibility does bring its own complexities with it, it makes it possible to incrementally replace parts of the protocol. XMPP is not the same protocol today as it was 20 years ago, there is slow and uneven but steady improvement and evolution.
And don’t forget the problem domain, human communication is pretty complex in itself.
Yeah it just also means that, like IRC, having a combination of clients and servers that actually correctly jump through all the collective hoops to do table-stakes things like “presence notifications”, “group chats” and “transfer a file” is a multi-day R&D project. Speaking from my experience with it at the time. (Long ago now, ofc.)
Once upon a time, there was a project to add IRC support to Prosody. This made a lot of people very angry and been widely regarded as a bad move. I mostly remember that it was not possible to do based on the IRC RFC alone, popular clients had expectations that weren’t explained there and there was a lot of packet captures involved in taking it to the point where the differences in addressing between IRC and MUC made further development very hard.
No idea what the state of IRC documentation is these days. At least the simple line based nature is easier to get started with, writing bots, until you get your first PING. And how much extra reading does IRCv3 bring? :)
the biggest issue right now is sliding sync. now, it is extremely new but I have a hard time believing every other client is going to pick it up, which means supporting the old style sync forever. also, the vast majority of non-element clients don’t support calls, which means you can’t necessarily hop on a call with someone else. you can’t even call an element user from an elementX user because they have different and incompatible calling APIs. there are also various, incompatible MSCs (Matrix Spec Change, I think. the RFCs of the matrix world) for lots of features people want (like arbitrary reacts like you’d have in discord). These may or may not be implemented in clients, or they might be incompatible. that is how you get balkanization.
Sounds like Matrix and XMPP has a lot in common. Maybe XML vs JSON, XEPs vs MSCs, or message passing vs database replication doesn’t matter as much as the size, resources and priorities of the ecosystem?
Regardless, I much prefer having these kinds of problems instead of problems with a single vendor deciding to mess with my privacy while showing me ads and removing features I enjoy.
Does anyone know of decent public rooms that are active in XMPP? I like the protocol, and I’ve got a good client installed, but I don’t really know where to go next.
I’m an XMPP fan because, warts and all, it’s an open standard with multiple implementations and it’s super lightweight. I use Dino on desktop and Monacles on my phone, and I run a prosody server off a VPS. The server has never gone down, ever. It’s a small deployment, though. Bridged to Slack with a few friends. I ran matrix before, but it was a tad slow for my use case.
All the protocol criticisms are mostly accurate. And the majority of clients still lack features I miss. But honestly I’m about to give my Mom (a 70 year old woman) a login to my server, because she and I chat on Slack all day, and I think she’d be able to make the jump, and I want to own those conversations for posterity <3
Many are familiar with the blow that big tech gave XMPP when they stopped federating. I’m sure they had their reasons. But I also have a half-baked sociological theory: after 2010, hatred of XML was on the rise. Especially XML network protocols. Can you imagine anything less sexy?
And I do think XML is a problem for XMPP long term. A couple of months ago I had some idle daydream about working on a CapnProto->XML translation library. https://github.com/capnproto/capnproto/discussions/2137 Not because I think CapnProto should become XMPP 2.0, but because I thought maybe if there were a bunch of canonical protocol translation libraries it would help client implementers write bridges or storage implementations or whatever. I thought about it for an afternoon then went and did other stuff (ADHD, fwiw).
As a lover of half-baked sociological theories, I think that it’s a much simpler story of embrace-extend-extinguish. :-P Once Google Chat got enough of a user base, they didn’t need to federate with anyone anymore, and then once everyone was using GMail anyway, Google Chat didn’t need to exist to draw in new users anymore. Simple as that. Android phones provided a better avenue for a captive audience anyway.
@icefox’s Tenth Law: Never attribute to anything else what can be explained by embrace-extend-extinguish.
It gets confirmed time and time again.
Federation was never a user acquisition strategy for Google. They had most of the users already. It’s just that Google back then believed in sometimes doing the right thing because it was right. Leading the way. But then they moved into their kill every project after 6 months era and it die just like almost every other google service.
Overall it was positive for the network. I don’t think most of my family would be users today if they hadn’t got a taste with Google at the time. Would have been nice if it stuck around, but no ill will from me
For anyone who doubts this: Google integrated Google Talk (XMPP) with GMail. Anyone who had a GMail account automatically had a Google Talk account. Only a small fraction ever used it, but GMail was on well over a hundred million active users and XMPP was on around five million. And GMail was rapidly growing.
Honestly, extremely good point.
Does this really matter?
Today the web works by passing unbelievable amount of unnecessary data, yet no one bats an eye.
There are web services that can be replaced by simple strcat(). Is XML really some kind of a problem, especially when it can be simply compressed? (a lot of binary formats are really zipped XMLs, for example MSWord’s documents, Excel spreadsheets, 3d models in various formats, etc)
Might just be referring to how XML is a verbose and poorly-specified standard and usually not as portable between parsers as other markup standards.
Maybe — the XML used by XMPP is not exactly completely standard or proper usage itself. See also @david_chisnall’s comment downthread a bit.
Haven’t scrolled down that far, but I’m assuming you’re referring to how it was plainly designed by somebody looking at the XML spec, then at the SAX parser spec, and then saying out loud “I have a cunning plan, sir”.
Different applications also supported different feature sets. Keeping up with ever newer supersets also stretched many players’ resources too much: https://alexalejandre.com/programming/xmpp-open-messaging-standard/
Could you list a few of your highest priority ones for those of us working to improve this situation?
Hey, I actually had to meditate on this a while.
One thing I don’t know how to do is edit messages further back from my most recent message. This is with the full understanding that I can’t expect those edits to propagate to all federated clients. However, I’m wondering if there’s support for this, even in principle.
The other concern is more vague and is really about a consistent UX around rich text authoring and rendering. It’s just not as nice to try and format multliple lines, bullet points, or code blocks in the clients I’m using.
I’ve never tried Snikket, fwiw. Also, I’m actually happy with my XMPP experience.
Yes, recent releases of Cheogram Android for example support editing any of your messages as far back as you like.
So you want a rich text UI with eg a formatting toolbar, not just some interpretation of * as bold etc. do you think that makes sense on mobile too or more of a desktop UX in your opinion?
Mattermost might be worth a look then (admittedly another service to run) because it’s basically self-hostable Slack. Has a decent user experience and the (iOS at least) mobile client is pretty good.
I should evaluate XMPP again for my private messaging needs. I’m running a Matrix server right now, but XMPP seems a bit more “settled”, for lack of a better word. I wonder whether there’s a significant difference in security levels.
Recommend Prosody as a server, ime it’s ideal for a small to medium self-hosted system.
Prosody is great; fast and small. Very well organized, easy to read code. I wrote a plugin to integrate it with a company VoIP phone service, once.
XMPP servers are designed with considerate defaults to discard after X amount of time and the data that’s sent to the client is offloaded to the client itself. Only downside is if you will be migrating data you will do it for the client and not for the server with the current client implementations. Many people I know are skeptical about hosting Matrix servers because the server will mirror and/or cache a lot of data and you can’t remove it cleanly.
I was around back then, and I assure you XMPP was no gem. :D Imagine an XML document that never ends. It had minor success when google absorbed it and then killed it (as they do to all projects), but the protocol was too heavy to get much traction outside of that. These days you would use something much simpler, like linefeed-terminated JSON or cap’n proto. [edit: I see these are already popular comments]
But I don’t want to yuck anyone’s yum, and I think if there’s a community that’s still maintaining and updating XMPP and having a good time, more power to them. It was the 2nd-weirdest chat protocol I’ve ever had to implement, and that probably makes it like a good classic car.
Traumatised.
It’s actually worse than that. It’s two XML documents that never end, which have some ordering between stanzas in them.
Imagine if IBM had been more successful with its early push for XMPP for the IoT niche and how many permanently vulnerable XML parsers would be hiding in smart deviced homes across the globe.
I maintained jabberd for the dorms at university when it was trending. Oh the joys of a 5kloc .xml config file and no failing line output on parser error. The plaintext storage of user credentials for the bridges was also not the best of choices. With less moral fibre in the diet one could’ve caused quite the mess with those.
On the plus side, at one point I realised that was the only place that my MSN Messenger login credentials were stored, which proved to be quite useful when I wanted to log in with the official client.
End users do not care nor know of the details of the protocol. It didn’t succeeded because people favor systems where they provide their username and password and get their personal data at their fingertips. Contacts and message history. Message history lives in the clients. So if you would talk with a friend at home, then join at your work computer, context would be lost. This is the same reason everyone moved to hosted email. And I would wager 99%+ of all email users use webmail. We should not underestimate the power of convenience. Richard Stalman does understand it but rejects it. He says that one should not let convenience deter you from your freedoms. But convenience is freedom too. What I am getting at is that even understanding convenience RMS essentially failed to win over it.
To build open systems that succeed we must not build them open at the expense of convenience. It won’t work. XMPP being just an example among many.
You’re already giving too much credit. IMHO it died because the clients either had major problems on mobile (Android ones sucked your battery dry, iOS.. not even sure and the desktop ones were all not-great). Too lazy to dig it up but I’ve written this story up many times. First I had 20 fellow nerds on jabber and then one by one they switched off their servers. Many migrated back to IRC even.
There was no extinction event (the google thing certainly didn’t help, but most people were too pessimistic about that from the start), it was just a mediocre experience for many years.And I’m talking about the people running their own servers here, not some rando casuals. (No ill will intended, mostly for hyperbole).
TBH back when I used XMPP, Pidgin seemed like the “flagship” desktop client, and it worked very well in my recollection. By the time I got a smartphone, XMPP was already pretty clearly in decline, and I had already fallen back to IRC because I didn’t have anyone left to talk to.
Edit: but now thinking back on it, I only ever used it for plaintext 1:1 conversations. I do have a few vague memories of running into some rough edges trying it for “MUC”; I was left with the distinct impression that multi-user chats were added on as an afterthought.
Oh, don’t be so harsh, IRC isn’t that bad :)
Oh haha, yeah that was unclear, I meant I fell back to using IRC exclusively. I never stopped using IRC and hope to never have to in the future.
Pidgin was a popular choice, but it was never a good choice since it is by definition a lowest common denominator client among the various protocols it supports
yeah, maybe I was a little unfair to Pidgin, it kinda worked. So there was a usable client on Linux and Windows (and iirc Adium on mac). But mobile was the kicker. I got my first Android phone in 2009 and I felt more on the early adopter side there (it had the older bad screen. it was cool but not awesome) and the time I’m talking about is probably 2008ish to 2014ish.
Luckily that has changed since the ’10s. Conversations & its forks, like Cheogram which I use, are pretty much the lightest weight chat clients on Android in terms of battery, RAM, & bandwidth. See: https://decentim.grafana.net/public-dashboards/92602d3a4aa842ce97812d310077691d?orgId=1
I know, I’m not passing judgement, just trying to provide historical anecdata.
I’d really prefer if I’d have xmpp instead of whatsapp but still, Matrix seems to just fill the niche of onboarding non-technical people a lot better than anything I personally tried.
Can you elaborate on this? We are constantly trying to support as many features as we can from every protocol.
I haven’t made a serious evaluation of Pidgin in this decade and was definitely speaking in the historical context above. But circa “google xmpp was a thing” the purple ecosystem lacked for example ability to target a specific resource (not a thing generally wanted now, but was at the time), ad hoc commands and other sub things needed to interface with xmpp services beyond chat, any of the pep flavoured stuff like user tune and mood, etc. I used Psi at the time to get access to all these features.
I don’t say the above to say that Pidgin didn’t work for what it was. But I definitely had contacts who used it and I would gripe at them about how they were missing out on cool extras.
These days I have been given the impression by customers that Pidgin lack some modern fundamentals like support for server archive sync, but as I say I haven’t evaluated that personally.
Thanks for elaborating
Part of this was that the JSF did not build a reference client library. They initially had a reference server (jabberd), then decided to completely rewrite it (jabberd 2, which didn’t support transports and so for a while jabberd 2 users ended up also running a jabberd 1 instance to run each transport), then they moved to eJabberd as the reference implementation. This wasn’t perfect but at least there was one reference implementation of the server and JEP / XEPs that wanted to become standards track needed to be implemented in that server.
On the client side, it was very different. There really needed to be a permissively licensed client library that any client could use and that all new standards-track proposals needed to be implemented in (ideally, in addition to one other client with interoperability between the two). In the absence of this, new features were added in one random client and never got to interoperability. Few things advanced to standards track.
This led to a situation where there were twelve competing XEPs for important features and every client implemented one of them.
XMPP supports messages on multiple machines & history syncing with clients (which are a part of the Conversations compliance suite: https://compliance.conversations.im/tests/)
The only part that hasn’t been convenient is when OMEMO keys expire for other users when trying to join a client that hasn’t been opened in a while. …But this isn’t specific to XMPP, I had it with Matrix + Element (browser) this morning having messages not encrypted for my client. The difference was that XMPP I can get this message immediately instead of blocking the UI for 3 minutes on server syncing to then deliver me errors that messages aren’t encrypted.
Take a look at the date on those. 280 is the older one and is from 2010. I started using XMPP (Jabber, as it then was) in 2001. I started using ICQ in 1997, so there was less time between my first use of any IM protocol to switching to XMPP than there was between my starting to use XMPP and XMPP gaining a standard for message synchronisation (and the implementations came later). Google Talk launched in 2005, so this is five years later.
By 2010, XMPP was well into decline. I think I shut down my Jabber server in 2014, but no one had used it for a few years before that (it had about twenty users when I set it up, they all moved to other things and I stopped using it because I never saw any online contacts).
The extensible protocol got extended (for over a decade) to support features the parent post alluded to being missing. Whether or not older XMPP/Jabber met modern expectations a decade prior to these XEPs isn’t relevant to if it can meet user needs in 2024.
It is, because the user needs evolve over time. It took until 2010 to meet the needs of 2005 users (by then, logging in from multiple devices was common and lack of history was annoying). It’s now 2024 and user needs include:
And some of these are kind-of supported by the protocol, but not well supported by clients, the middle one can’t be added without a complete redesign.
I will always have a soft spot for XMPP. I was involved in the standardisation effort back before it was called XMPP, wrote two clients, and my involvement with XMPP got me the contract for my first book (stpeter had a contract with Pearson to write a book and didn’t have time so put me in contact with his editor to do it instead. His editor decided not to go ahead with the book, but asked me to write a different book instead). But it was clear by the time these extensions were added that the protocol was not the right design and that it could not be fixed by adding more things, it needed some fundamental changes from the ground up.
But it came to meet the needs like it could adapt again. As mentioned earlier, I have the same E2EE issue with Matrix–which also has metadata leaking issues. I use the voice/video calling with my partner since it is self-hosted & I can trust my own TLS connection even without E2EE, or Mumble when trying to voice chat with multiple folks, but I can’t say I need these as often as text. So is SimpleX the alternative albeit immature?
Who would? Has anyone?
I’m glad I’ve reached the age where we’ve gone full vinyl records on XMPP. I loved XMPP, spent years using it as a work chat protocol and helping to run the servers. It didn’t die because people were desperate to pay for Slack or because Google removed it from whatever their chat client was that week.
It was just a bad user experience. Multiple active devices wasn’t a problem that ever got solved in a great way. Instead the first online device won and got the messages and the other devices would get the messages filled in (which was the vastly improved version, for years it was first device won and everyone else suck eggs). Obviously in a world where everyone has a smart phone and a laptop that worked about as well as you think.
Honestly the server part was fine, like it scaled from 5 to 200 employees well. The clients were just pure amateur hour. They either didn’t have all the features we needed (which, not their fault, they were almost all add-ons mostly handled by the client) or they were the sole work of one open source developer which is not a sustainable platform to pick. Even in the paid arena it was hard to find something that worked well enough.
I still believe that XMPP could be redone better, and would be much simpler. But I don’t know enough about IM protocols and networks to suggest how. And it wouldn’t directly benefit any actual users, just server and client implementers, and since there’s already good servers and clients for it then the real benefits are pretty tiny.
I worked on XMPP back around the time it started to be called XMPP. There were a bunch of warts in the protocol even then:
The core has three elements. Presence is broadcast with coalescing (if you send two presence stanzas, the recipient may see only the second). Message is unicast (group chats are implemented via relay services), unidirectional, and queued. Info-Query (iq) stanzas are request-response. These are all designed for specific uses, rather than providing primitives that higher layers can build (MQTT or CoAP, for example, go the other way). Eventually, there was a generic publish-subscribe extension and then Personal Eventing over PubSub (PEP), which was a huge spec but provided a generic way of building a bunch of things people wanted. In hindsight, a PEP-like mechanism should have been part of the core protocol and a bunch of things in the original RFC should have been layered on top of PEP.
It uses a bunch of XML features, but only kind of. You didn’t actually need a full XML parser (it explicitly didn’t require support for entities and some of the more fun namespace things), but then people wanted to embed other XML documents in it (which is the main selling point of XML, after all) and these could hit corner cases. This also meant transferring any binary data hard and it usually ended up being base64 encoded.
A bunch of things are hang overs from other IM platforms. For example, messages can be message or chat messages, because ICQ had an email-like UI for longer messages and a chat UI for short ones. Most XMPP clients treat them the same.
In spite of this, a bunch of things that should be core to a modern IM protocol were not included. For example, for a very long time the way of providing an avatar was built on top of a standard called vcard-temp (with the -temp indicating that they knew it should be replaced. It was eventually). This provided an iq interface for fetching an XML-encoded VCard. The VCard could contain a base64-encoded avatar. You’d then also put the base64-encoded hash of the avatar into your presence messages. This, unfortunately, meant that presence messages got quite big. This matters less now, but back then an expensive phone plan had 25 MB/month of data. As an XML-based protocol, embedding any binary data was a bit painful.
File transfer and audio / video calling were also layered on top. There were a bunch of competing standards. There was also a non-standard one that Apple implemented in iChat. Google basically steamrollered over everyone by dropping Jingle, which was a massive family of extensions that supported stream negotiation between peers and then things like audio, video, file transfer, and so on on top of this. Over 50% of XMPP users at the time were on Google Talk, so everyone just implemented Jingle to be compatible.
More generally, while it would be unfair to claim XMPP was not designed with security in mind, it was designed with a late ‘90s threat model. There are now end-to-end encryption standards, but they don’t protect any metadata. These days, end-to-end encryption and a decent amount of metadata protection, and a threat model that assumes server operators are malicious, is table stakes for an IM protocol.
And that’s part of the problem with XMPP: Is it an IM protocol? For some people, the answer is ‘of course’, but a lot of the deployments were nothing to do with IM. They were happy building control and monitoring systems on top of something that provided reliable message delivery and message coalescing for arbitrary XML snippets. To these people, XMPP was a more easily extensible MQTT alternative. It ended up not being a great fit for either use case.
I’m both horrified and fascinated.
You’ll be horrified and fascinated to know that Google Cloud Print was (is?) built exactly this way on top of XMPP.
was
For myself, I’m neither shocked nor awed by this revelation, because I already knew about https://www.ejabberd.im/ and its many customers
It’s an interesting thought. With all these “modern” MQ protocols available, maybe one of them would be a better basis for a “modern” IM protocol.
I find this slightly funny with the knowledge that Facebook Messenger is (or was, I cannot tell) based on MQTT.
Did you have an IM protocol in mind that meets those qualifications? And what is considered a “decent amount of metadata protection”?
Signal is the gold standard on that axis. The only metadata that they can record is the last time you connected to the network and from what IP. The down side of Signal is that it’s a centralised protocol. Getting the same guarantees and some form of federation is much harder.
Any thoughts on this David? Don’t you think it’s important to get right if you’re going to go around saying it’s “table stakes”?
As far as I can tell, the thing about only recording the last time you connected is a promise, not something enforced in the protocol. It reflects gravely on the project that they allow this misconception to flourish; the president even said Signal protects metadata in this paywalled interview. So I get concerned when I see Signal raised as the “gold standard” and this largely fraudulent metadata protection deployed to discredit alternatives.
I am not a cryptographer, I’d recommend reading Soatok’s posts for a good analysis of the state of various IM protocols’ security.
And yet you wrote:
You don’t have any comment about what led you to write that and whether you should retract it?
You don’t seem to care about this, but if anyone does here’s the upshot: “Anyone who cares about metadata resistance should look at Cwtch, Ricochet, or any other Tor-based solution. Not a mobile app. Not XMPP. Not Matrix.”
https://soatok.blog/2024/08/04/against-xmppomemo/#comment-5518
One might ask themselves why the misconception about Signal protecting metadata has been allowed to proliferate, and who benefits.
Let’s consider two threat models:
The first matters more to me than the second (your quote is related more to the second). Let’s compare how Signal and XMPP stack up here (I’m not an expert on Signal, but I have implemented XMPP multiple times and participated in its standardisation).
First, let’s look at how contacts are stored. Signal, I believe, stores them only on the client (which is a bit annoying because they aren’t sync’s when you add a new device, I’d be happy if they stored it encrypted on the server). In contrast, XMPP holds your entire roster in plaintext on the server. For both threat models, this means that XMPP can give an attacker complete info into your node in a communications graph. This is bidirectional. It stores both people you have added and people who have added you, so it gives a lot of information if someone just takes a single snapshot of server state.
In XMPP, this is required for core features of the protocol to work. The entire presence model is built around it. When you update your status, you send a message to the server and the server then sends a copy of it to everyone who has the right setting in your roster. I am not aware of any XEPs to even try to encrypt the payload of these messages. Your online status is entirely plaintext as is any status message. Retrofitting encryption would require key exchange when you add someone and would require every client to agree on the encryption standard. Even with that, the source and destination, and the fact that it’s a presence stanza, are all visible to both servers.
Now let’s consider single point to point messages. In XMPP, these are now (optionally, if everyone does the right thing) encrypted, but they metadata is plain text. The sender and receiver are both visible to both servers as is the size of the message (newer standards add padding to avoid side channels here, older E2E XEPs did not). Any undelivered message is stored in a queue on the sender or receiver’s server and so a snapshot can find all of the messages that people have sent to you that you haven’t received. Again, all of this is required by the protocol and so a server run by a non-malicious administrator is vulnerable to this kind of leakage.
As I understand Signal, each sender-receiver has a separate key pair and the messages are put in a mailbox associated with the receiver’s key and the sender is part of the encrypted metadata. This is where the difference between the two threat models matters. If the server is malicious, it can correlate the message delivery with the recipient’s mailbox and the correlate the mailboxes that the recipient asks for, but it can’t do that post facto. If a message is in a queue before the server is compromised, it can’t retroactively discover who sent it. It would be possible for Signal to improve this by having clients send messages to random mailboxes periodically with invalid encryption keys. These would then be downloaded by random clients, fail cryptographic integrity checks, and be discarded. I’m not sure that this is worth it though for the small gain. Something similar is not possible with XMPP.
Now consider server-side message history. With Signal, this is not stored (which is annoying, and I’d also be happy if it were stored encrypted. Instead, they require client-side backups). It wasn’t with XMPP either until around 2010, but after that it was added. One of the motivating use cases was web clients, which have no local storage. This means that the message store is also unencrypted. If you’re using one of the E2EE XEPs, the payload is encrypted but all of the metadata remains plaintext.
When Signal had had to cooperate with law enforcement, the only thing that they’ve been able to provide is the last connection time and the account creation time. The protocol doesn’t require them to maintain anything else, which is very different from XMPP. In the first threat model, that’s all you care about. In the second threat model, you might care that they could additionally log the mailbox slots that your account uses and therefore build a connection graph, but if they did then this would show up in their responses to search warrants (which they publish as soon as they’re unsealed).
Signal is not perfect. I don’t like the fact that they conflate identifiers and capabilities in stupid ways (XMPP does this too, but it doesn’t claim to be secure and private). I don’t like the fact that they’ve made the client libraries GPLv3, which has prevented alternate implementations (and the fact that they’ve put things like disappearing messages, which rely on client support, in the protocol with no possible mechanism for enforcing it). It remains far better than the alternatives though and, as I said, retrofitting XMPP to give the same baseline security guarantees would require you to replace everything in the core protocol.
Would have responded sooner but Lobsters didn’t notify me. I think I get what you’re saying so here are some counterpoints:
I don’t see a distinction between a compromised server and a malicious server. in practice your distinction is between security compromises that occur at a point in time and those that are ongoing, and it seems naive to think that the latter are so uncommon; see PRISM and room 641A. I would be interested if you could unpack why you care about one type of compromise more than the other. It’s certainly out of step with your earlier statement that “a threat model that assumes server operators are malicious, is table stakes for an IM protocol.” That threat model is generally what people have in mind when discussing metadata protection as well.
I don’t consider contact storage, presence, and message history to be “core features of the protocol,” and it would be trivial to set up XMPP without those things, but I grant that it’s an issue with the most common implementations.
It sounds like a malicious server actually can do that post facto if it continues operating maliciously while the two parties exchange additional messages. The conditions under which this actually makes a difference seem rather contrived: A server is compromised after a message is sent but before it is received, then no further messages are sent until the server stops being compromised. Do I have that right? This is the type of protection that you’re saying is table stakes?
I don’t share your confidence that it would show up in their unsealed warrant responses, or that the instances of cooperation that we know about are the only ones that have happened. The public desire for E2EE grew out of the Snowden leaks so this credulity seems out of place to say the least.
Maybe for your threat model, which still remains obscure to me. One thing XMPP has over Signal is that users can chose a server that is less likely to be compromised by whoever they are worried about; e.g. if they want to hide their metadata from the US government they can pick a server somewhere outside the reach of US agencies. This extremely basic fact bears repeating. XMPP users can hide their metadata from the US government; Signal users can’t.
It’s also worth pointing out that Signal is not an alternative to XMPP for desktop use. Not having a smartphone, I can use XMPP but I can’t use Signal.
So the Signal server is not able to know who is talking to whom and when? The only techniques I’m aware of for hiding that are onion routing and continuous transmission of messages between every client as in Dissent. Oh there was also Vuvuzela; I forget how that one worked… How does the server manage to deliver the message if it doesn’t know who it’s going to?
There’s one article that mentions this feature (or a similar feature, not sure):
https://arstechnica.com/information-technology/2018/10/new-signal-privacy-feature-removes-sender-id-from-metadata/
However, Signal’s security policy can sometimes be confusing, and some of their features seem more like security through obscurity. For example, the fact that there is only one client available feels like it walks over the line between usability vs. security. After all, “in a perfectly secure world, nobody would be able to use anything”.
Also, phone number requirement to improve privacy and security, and it’s OK to everyone? Sometimes I feel like we’ve lost touch on what is secure, what is private, and what is public.
Sealed sender definitely doesn’t hide the identity of the recipient, but maybe it’s what @david_chisnall had in mind. It certainly leaks more metadata than the last time you connected to the network and from what IP though.
Sealed sender seems like a perfect example of the confusion around Signal’s security model. As far as I can tell it doesn’t hide the sender in practice because Signal can still see sender’s IP address and can build a near-perfect mapping between users and their last used IP address. In theory maybe you can deliberately share IP addresses between a few accounts with the right VPN setup providing a small anonymity set for the sender, but that’s still largely broken if there’s an ongoing conversation where Signal sees the recipient of every message. Nobody seems willing to argue that this mostly useless security enhancement is worth the complexity. It seems like Signal added it mostly because it’s a fairly novel feature that they can write a blog post about and claim that they’re “raising the bar.” In other words they’re willing to add complexity that provides little practical benefit for marketing purposes, which is awfully concerning for an app that claims to be suitable for security-critical applications.
[Comment removed by author]
One nice thing with XMPP is that it has a pretty simple core protocol (RFC 6120) and then extensions on top. While a modular nature and managing backwards compatibility does bring its own complexities with it, it makes it possible to incrementally replace parts of the protocol. XMPP is not the same protocol today as it was 20 years ago, there is slow and uneven but steady improvement and evolution.
And don’t forget the problem domain, human communication is pretty complex in itself.
Yeah it just also means that, like IRC, having a combination of clients and servers that actually correctly jump through all the collective hoops to do table-stakes things like “presence notifications”, “group chats” and “transfer a file” is a multi-day R&D project. Speaking from my experience with it at the time. (Long ago now, ofc.)
Once upon a time, there was a project to add IRC support to Prosody. This made a lot of people very angry and been widely regarded as a bad move. I mostly remember that it was not possible to do based on the IRC RFC alone, popular clients had expectations that weren’t explained there and there was a lot of packet captures involved in taking it to the point where the differences in addressing between IRC and MUC made further development very hard.
No idea what the state of IRC documentation is these days. At least the simple line based nature is easier to get started with, writing bots, until you get your first
PING. And how much extra reading does IRCv3 bring? :)I’m a bit surprised the author didn’t share their XMPP address, given the exhortation to do so (ok they said just to share with contacts, but still).
There is also this beginner friendly guide on XMPP: https://contrapunctus.codeberg.page/the-quick-and-easy-guide-to-xmpp.html
The best thing I can say about XMPP is that it was a really clever SAX parser hack.
It’s not forgotten is as much as it’s balkanized so much that none of the fancy features reliably work. I’m afraid matrix is going the same way
How is matrix getting balkanized? The org makes both clients and servers, effectively defining what’s canonical.
the biggest issue right now is sliding sync. now, it is extremely new but I have a hard time believing every other client is going to pick it up, which means supporting the old style sync forever. also, the vast majority of non-element clients don’t support calls, which means you can’t necessarily hop on a call with someone else. you can’t even call an element user from an elementX user because they have different and incompatible calling APIs. there are also various, incompatible MSCs (Matrix Spec Change, I think. the RFCs of the matrix world) for lots of features people want (like arbitrary reacts like you’d have in discord). These may or may not be implemented in clients, or they might be incompatible. that is how you get balkanization.
Sounds like Matrix and XMPP has a lot in common. Maybe XML vs JSON, XEPs vs MSCs, or message passing vs database replication doesn’t matter as much as the size, resources and priorities of the ecosystem?
Regardless, I much prefer having these kinds of problems instead of problems with a single vendor deciding to mess with my privacy while showing me ads and removing features I enjoy.
Does anyone know of decent public rooms that are active in XMPP? I like the protocol, and I’ve got a good client installed, but I don’t really know where to go next.
What kind of topics are you looking for?