I think in this case they recommend the standards, which are worth implementing. E.g.
"Our recommendations highlight only the XEPs you need to implement for a modern messaging application, ignoring historical cruft and excessive backwards-compatibility."
Do you have constructive suggestions on introducing cohesive design into open ecosystems without a guiding documentation project? (disclaimer: I started this one)
There are other ecosystems that are going "fine" that have centralised, official documentation and don't require a third party to intervene and collate documentation and recommendations in an attempt to make it easier for developers. The fact this is necessary, or people feel is necessary, makes me want to avoid XMPP at all costs. That's just my very shallow surface level opinion.
With all that said, i have to say; what you're doing here is commendable. I don't mean to (pardon my language) shit on something you seem to have worked very hard on. Doing something like this isn't an easy task I'm sure.
This kind of thing is pretty common with complex systems that have a very long legacy. There's a huge amount of features, many of which are very niche and most people don't even need to know about them. Official docs tend to be unopinionated and cover everything, while third parties create "guides" and similar docs for the features that matter to them.
You see something similar with end-user software like Adobe's entire suite where the official docs are basically useless if you just want to learn the common operations quickly and so you have to rely on third-party books and tutorials (like the Dummies books).
XMPP has a long history... Two decades of accumulated specifications can make it a bit overwhelming to find what you're looking for. It's important to have external individuals/collectives gathering the pieces they find important and remarks to achieve what they consider a good implementation.
It's just like when you do web stuff you may read from MDN, csstricks or smashing magazine. It doesn't mean that the W3C/IETF specs are useless, far from it. But in my view it's useful to find guidance in a nebula of specifications and endless UX possibilities.
The core of XMPP may be simple, but when you add in various XEPs, the complexity builds really fast. Just look at all this stuff: https://xmpp.org/extensions/
That's a growing list of documents over the course of XMPP. It doesn't really prove anything other than... XMPP has been around a long time, and people continue to develop it.
People saying "look at all this stuff" is one reason the Modern XMPP project was born. To draw attention to the actually important things that developers need to read.
The XSF receives a lot of submissions each year. Many of these proposals never make it past the "experimental" stage. Others are only applicable in certain domains (IoT, etc.). Over time some of these become widely adopted and progress through the standards process. Some do not.
That is true to some extent, however most of extensions listed there are not required or even recommended to implement useful clients/servers. It's just like if you took the list of RFCs using TCP/IP then said "ha! TCP/IP complexity builds really fast".
Overall, the impressions expressed in that comment from 2011 were relevant at the time, back when "Compliance Suites" specifications were not a thing and there was a lot more room for interpretation in many specifications. The situation has much improved since then. To reply to individual bits from that comment:
> It has never seen serious adoption because nobody wants to touch it - and for good reasons.
That's outright false. There's many successful commercial products using XMPP right now (eg. WhatsApp/Zoom or games and gaming systems like Fortnite, Origin, League of Legends) including for non-IM usecases (Google Cloud Print, Firebase Cloud Messaging, Nintendo Switch, Apple's push notifications).
In the free-software world, there's actively maintained featureful clients (gajim/dino on desktop and snikket family of clients on mobile) and servers (ejabberd/proosdy/tigase). I can't say there's no bugs but i can say with confidence they're actively being hunted down.
> It leads to ridiculous overengineering through layered complexity.
Layering complexity may sound like engineering, but that's where the "eXtensible" promise of XMPP comes from. The same goes with Matrix/ActivityPub protocol: there's a reason people are doing it this way, and that reason is not "overengineering".
> Take a lesson from IRC, a group-chat protocol that, despite its age, works and scales amazingly well.
The protocol works remarkably well because it's dead simple. However, implementing a decent client/server that plays well with others is not easy (see IRCv4 debates) and each server in practice operates differently, more so even than XMPP servers.
> It wouldn't take much fix the warts on IRC and extend it to cover everything that XMPP tries to do.
Please by all means try. It'll take you far more time to design, and you can be 100% sure you're going to break many existing clients and servers by extending the IRC protocol. XMPP/Matrix clients on the other hand can handle missing features gracefully because the protocol is namespace'd/schema'd properly.
I appreciate that concern for fighting NIH and that's a criticism i've addressed to the Matrix project myself, that it could have been implemented on top of existing XMPP clients and servers with two simple XEPs: one for decentralized chatrooms and state resolution, the other for client-to-server JSON API. But when comparing those newer federated protocols with IRC, i think the comparison has no grounds.
Let me know if you're not convinced by these answers or have more questions.
Maybe I should take another look! It sounds like a lot has changed. My experience, working on an XMPP client for an internal application, dates from 2011.
If you're still into that same domain, then sure you should have another look. There's plenty of chatrooms where you can ask questions, jdev@muc.xmpp.org is a popular one for implementers. The Jabber/XMPP community, despite a too-much-information syndrom, is full of very friendly folks who always take time to answer questions in public chats to guide you in the right direction. That's something i truly miss in most dev chatrooms where i often feel like i'm talking into the void (or to other people like me who have different problems and no clue).
From a client perspective, picking a good/modern XMPP library will save you a lot of headaches, because a good library is supposed to hide away the complexity. If you're not sure what to pick, just ask around in dev chatrooms.
My needs were relatively simple in that I needed a system to route quick, short messages without much client overhead. I'd previously done this with XMPP (using Python) which worked well, but the protocol offered way too many options. Also, trying to find a decent client for my iPad was a nightmare. I switched over to MQTT which is more suited to the role in my case and works as intended.
MQTT looks interesting, do you have links to simple implementation of the protocol? I often find simple (even if partial) implementations of protocol a better documentation than the complete specifications.
to run the IoT stuff in my house. Mostly I access it through AQMP but it supports MQTT also. An asyncio-driven python script takes events from the outside world and systems that have an cloud component like SmartThings and posts them to RabbitMQ. Other scripts listen for events, make things happen, log data to arangodb, etc.
On paper XMPP supports M2M applications but it's not a great fit compared to other protocols.
Yeah, if your needs are simple enough and your clients are small, MQTT is a good choice. Two or three XMPP servers even have built-in MQTT bridges for supporting very lightweight clients.
From what I've seen, XMPP is used in IoT more for the federation aspect rather than as the "last mile" to the sensors/devices. Cases where you need interoperability and security across different sites/organizations.
In any case, the Modern XMPP project (this article) currently only focuses on XMPP for the IM use-case.
My first impression was that "there isn't any there there" but after this article got a lot of upvotes I realized I could find real content using the navbar at the top.
I really hate it when "modern" is used generically in technical documentation. What does "Modern" mean? Does it mean lightweight? Heavyweight? Easy to implement? Simpler? More complex?
The vague descriptions like "modern" usually mean "More like whatever the author's today's usecase is", and good luck trying to get anyone except yourself onboard with that...
Modern means: "we analyzed all bad things about the thing and fixed many of them". Paradigm in "modern"-term is "more time - better solution". So "modern" - many time passed.
Bad for whom exactly?
For example, here it seems today's usecase was a "SMS-like mobile messenger", so they are deprecating stuff such as resources, priorities and presence notifications. WHY? My use-case as is the entire of my network is multiple devices, so resources AND priorities are a must.
So rather than "modern XMPP" this looks like "how to use XMPP to build a SMS-like messaging program for mobile phones". Now it's clear who is the target of the document and you avoid a weasel term like "modern" which also annoys every other consumer of the protocol.
I think it's fair to describe the SMS-like mobile messenger as the modern goal of XMPP if that is in fact what people are using. The goal here is to get broader adoption for the protocol, and the only way to do that is to make it easy to deploy and use for a mass-market audience that expects certain things already.
You're right. I take responsibility for the name, but naming things is hard!
As for the focus, you're right, there is a bunch of advice that is specific to this class of personal messaging apps. As time, resources and interest allow, I would like to grow it to document other "profiles" of XMPP as well. For example the Slack-like "team chat" use-case, or even IoT.
If you're using XMPP in a particular domain and you feel it would benefit from documentation like this, PRs are absolutely welcome. It's in scope.
We develop Web in C++ and all our protocols looks like this:
serializer.put<uint32_t>(item).put(another).put(this);
if (writer.valid()) {
// no overflows or other problems
socketwriter.write(serializer.data());
}
A company I used to work for used to do something like this (I never had access to the source code, but I inspected it closely with Wireshark a time or two).
Sent over UDP this had stood the test of time for a couple decades or so.
Disadvantage: the rest of the system was also written in C++ and it was impossible to get those who had access to the source code and knew it to fix anything. As a result the system looked more and more antiquated and there were more and more hoops to jump through to get it working with every new version of Windows:-/
Edit: that said, I think your comment is a bit off topic :-)
You have a protocol there, you have an understanding of what's expected on either side of that communication. That is the definition of a protocol. And if that's for Web stuffs, as you say, then you must be implementing something related to HTTP/HTTPS, protocols.
Good luck with upgrading or downgrading anything. There's a reason why people serialise to well-known formats like protobuf and JSON, and it's because they are extensible.
Moreover, there's a reason why people standardize/specify their profobuf/JSON/XML schemas, and it's because that's more extensible than unversioned, unnamespaced serialized data.
I have a suggestion for this and other projects like it:
When you are establishing a standard that clients and servers will advertise that they adhere to, don't leave technical decisions to the end-user by default. Make the best decision that you can.
In this document, there's discussion about STARTTLS vs TLS-from-the-beginning, and how to deal with that in the UI. Don't do that. Decide that TLS-from-the-beginning is the requirement for client-server interactions, and now you don't have a UI issue. You already decided that /resource and priority were not going to be useful; make this decision too.
Indeed. I think this stems from presumably wanting to support legacy XMPP where possible, email servers and FTP servers are the other two places this option often comes up.
But it should probably be really clear that the correct way is X, and support for Y should be buried somewhere so most users don't have to think about it, if you do feel a need to retain support for it.
You're completely right, thanks for the spotting that and the feedback!
I was going to remove it, but I don't think that's the problem. The whole section you mention is the problem - all these options should be auto-discovered, and in fact are, in any normal deployment. It's sometimes used for unusual deployments (connecting over a VPN, or a testing/development server).
For normal deployments, XMPP already defines which host/port/TLS-mode to use and how a client can pick between them.
So I've just merged an update that clarifies that these options are not generally recommended for implementations to expose to users, except to support testing/development.
I'd rather have this documented (i.e. "if you are going to do this anyway, at least do it correctly, like this").
> all these options should be auto-discovered, and in fact are, in any normal deployment.
I think that's a slightly different thing than what was suggested. For some options, auto-discovery is fine. For security, I think the current consensus is just make the best choice you can, and if something really requires a major change, version the standard (major version, like from 1.x to 2.0, so it's obvious). Auto-discovery of a setting to do with security is just another possible location where a security issue might be found because or a poor implementation of the standard.
Sure, but I don't think that applies here. The section in question is about a settings screen where (for some reason) the user is manually entering all the connection parameters. There is no way to detect (without probing) whether the port that the user configured is using STARTTLS or direct TLS. Both are commonly deployed.
Probing could be implemented, but that quickly introduces complexity (and code just as likely for security issues to hide in) to implementations. It would be nice to one day say "only support direct TLS" for example, but that's not the reality of today's network (looks like ~41% of servers advertise direct TLS as of today, slowly climbing).
So the happy path is using auto-discovery as standardized. If you go the manual path and configure a host/port, I don't think probing is sensible to recommend, and I don't think strictly assuming only one or the other is going to fly right now.
Is this just for clients, or for servers as well? If it's for servers also, I guess that's a question of what you want this to be then. Is it a descriptive document that says "this is what Modern XMPP looks like as we see it in the wold" or a prescriptive document that says "This is what you need to do to be a modern XMPP deployment so we can fix some problems of the past".
Maybe one way that might look is user clients that probe, but when defining how servers should act, there's a "one true way" unless they aren't adhering to Modern XMPP spec or best practices. Changes like this need a push from outside or they never happen, and someone just being able to point at a spec and say "look, you aren't compliant with Modern XMPP, the world has moved on from what you're doing" is incredibly useful in spurring change.
I agree it doesn't necessarily make sense for a client options perspective, but it might be a good principle to adopt or consider for other aspects of the document. If you want to actually push things forward, I think it's very useful way to do so.
This project is certainly aiming to push things forward. Indeed a decade ago it would be totally unsurprising to see a client with a drop-down for "STARTTLS", "Direct TLS", "No TLS" (!).
I think it's best described as something of an evolving "current best practices" document. There is certainly room to tell developers to implement (or not implement) certain features. Indeed that is done already for some things (e.g. file transfer mechanisms).
I think this specific TLS example is unfortunate because it's something that is documented only for advanced use (recognising that some people may need it for specific purposes that some clients may want to support).
Similarly, I remember implementing an Android IRC client years ago and having to provide an option in a dropdown not to verify the TLS certificate since so many servers ran self signed certs at that time (thankfully Lets Encrypt put a stop to that).
> When you are establishing a standard that clients and servers will advertise that they adhere to, don't leave technical decisions to the end-user by default.
On principle I agree, but ironically the exact scenario you suggest was the single biggest event that "killed" XMPP as we used to know it. In late 2013 there was an XMPP community manifesto calling for mandatory TLS (even STARTTLS) for XMPP server-to-server communication by a drop-dead date in early 2014: https://github.com/stpeter/manifesto/blob/master/manifesto.t...
"The schedule we agree to is:
- January 4, 2014: first test day requiring encryption
- February 22, 2014: second test day
- March 22, 2014: third test day
- April 19, 2014: fourth test day
- May 19, 2014: permanent upgrade to encrypted network, coinciding
with Open Discussion Day <http://opendiscussionday.org/>"
Well-intentioned for sure, but the one XMPP provider with an actual critical mass of users (Google Talk) remained non-TLS-only, all Google Talk users dropped off the federated XMPP network after May 2014, and so XMPP effectively ceased to matter.
In fairness, by 2014 it was fairly obvious that Google was no longer interested in furthering Google Talk. It was about the time that they were pushing folk to Google+ and Hangouts.
Google's XMPP server continued to accept unencrypted connections for many years after this point. I think the XMPP operators made the right choice, rather than letting Google weaken the security of the entire network.
> by 2014 it was fairly obvious that Google was no longer interested in furthering Google Talk
Definitely, but I think it was a huge PR failure that we in the XMPP community were the ones to sever the conversational link. Users shouldn't be expected to think about the protocol details, hence this thread, and it was an XMPP community decision that resulted in people being suddenly unable to talk to their friends.
We provided perfect justification for any Google project manager to look at the stats and see zero incoming s2s connections as justification to kill Talk entirely so they could Move Fast™ on Hangouts or whatever.
I guarantee we pushed more overall XMPP users to WhatsApp/FB than we pushed Google Talk users to privacy-first XMPP hosts since it's not like Google popped up any alert in the GMail Talk UI explaining to people why their nerd friends all suddenly vanished from their buddy lists. The moment any of those people used a non-XMPP service to reach out and ask "What's up?" we had already lost :/
That UX description is intended for "additional connection options" prompts, which are useful when your server is misconfigured or you want to reach it in a different manner than advertized over DNS (eg. over a .onion address).
Great question! onion vhosts (user@foobar.onion addresses) don't need that, as long as your client can resolve onion addresses (Gajim/Conversations have good tor integration, otherwise Tor's AutomapHostsOnResolve will do the trick systemwide but in that case your client may complain that the domain doesn't support TLS or with a wrong certificate).
"Advanced" connection settings is required when the vhost you are connecting to doesn't match the hostname you need to reach on the network. For example, if you're reaching your server over a VPN/SSH/IPSEC tunnel.
Another example is if you wish to login as user@foobar.com by reaching foobar.onion. This is useful if you want to be part of the broader Jabber federation, in which not every host supports federation over onion addresses (i'd be curious to make stats about that) but it still gives you the security guarantees of Tor when reaching your server (though not for server-to-server connections).
Implementing something similar XMPP side would be easy. Prosody already has a community mod_onions, but currently only supports a static map of hosts to their onion addresses. It could use some love: https://modules.prosody.im/mod_onions.html
Another problem we face from a UX perspective for onion services is that currently XMPP server implementations are very strict about which node/resource messages are intended for, and to my knowledge none support aliasing systems as we have in the email world. In this specific example application of aliases, there's currently no way (that i know of) to have the same account across .org/.onion domains and having servers to know it's the same account in a federated manner, eg. to prevent you from adding the same person twice to your contact list.
All in all there's interesting challenges and none of them is really hard so if you'd like to get involved or just let us know about your ideas and expectations, feel free to drop by xmpp:privacy@joinjabber.org?join
So we just had some conversation about it and it and in fact onion discovery works fine with SRV records. The problem is if you set the highest priority for an onion, tor-unaware clients may try to make a DNS request for it, and i believe a bunch of resolvers are still happy to try and resolve onions despite rfc7686 special-casing .onion (back in 2015), which would result in metadata leak: your resolver would learn what onion addresses you tried to reach.
Whether that's a huge concern or not is a good debate. In the case where the .onion is a security upgrade to the network connection for a "normal" vhost, then it's not a problem because your resolver has already learned about the vhost you'd like to reach (via the SRV query).
The real problem would be if a client tried to resolve foobar.onion through DNS when provided with a user@foobar.onion login. According to spec DNS software should not do that, but from a super quick review it appears a number of DNS implementations still do that.
I'm not sure what the best approach is here. But surely there's a solution to find.
I understand where this is coming from. But this kind of early decision making can hurt the growth and adoption of projects.
Think of it as Apple making a bunch of decisions for themselves and their users and it keeping problematic for future adoption.
The spirit of open source is voluntary participation and openness to all platforms and ideas. Though I cannot understand the distinction behind TLS and STARTTLS , I don’t think locking in one option will make it all that better.
> Though I cannot understand the distinction behind TLS and STARTTLS , I don’t think locking in one option will make it all that better.
StartTLS starts unencrypted then "upgrades" the connection to TLS if the client and server support it. This leaves a whole lot of room for an active attacker on the network to prevent all forms of encryption, rendering TLS essentially useless.
That's not to say TLS is perfect: having to trust an entire list of third-party CAs with their own incentives/pressures is a flawed model. But TLS is better than no TLS, so direct TLS is better than StartTLS.
> This leaves a whole lot of room for an active attacker on the network to prevent all forms of encryption, rendering TLS essentially useless.
This is a common misconception about STARTTLS. It is certainly possible to implement it poorly (and that has certainly happened). But there are no inherent security issues with a correct implementation. An active attacker can just as easily block TLS handshake packets on a direct TLS connection.
The problem used to be that many software implementations (not just XMPP) would happily continue unencrypted if STARTTLS was not offered. But these days everyone requires TLS, and will not proceed to connect unless TLS is in use (regardless of whether it is negotiated or "direct").
However the future is certainly direct TLS, that has been obvious for some time. It has many advantages, such as allowing the use of off-the-shelf middleware such as loadbalancers and proxies, and bypassing certain firewalls. It's also easier to implement, and there is of course the (relatively new) ESNI which is beneficial.
XMPP is doing fine without Google. There are lots of public and federating XMPP servers out there you can just sign up for:
https://xmpp.org/getting-started/
Hi, thanks for your support of our project, and all the users and developers of XMPP in 2021 :)
Google closing down XMPP support was indeed a sad day for everyone. But there are plenty of us supporting the idea that Google does not control the internet.
Plus while I was very sad they closed down the federation, XMPP is still how I connect to the google chat network today, I just had to switch to having my client make two outgoing connections instead of one.
I really hope this works. Does it need a new name and mascot ;) Its such an important application that's dominated owned by Slack/Facebook messenger/What App etc.
(In case any one doesn't know XMPP was Jabber.)
Also important to note that this project is still aimed at developers (as is XMPP and all the protocol documentation). What's needed are friendly projects promoting to end-users.
Current work in that area would be:
- https://snikket.org/ - a client+server package of XMPP software for personal messaging (disclaimer: I started this project).
- https://joinjabber.org/ - a community of folk working to support new users joining the network with documentation and infrastructure.
Modernization/UX improvement projects are badly needed in many areas in free software where the underlying technology is great, but the experience of actually using it is not.
Snikket, which a maintainer of modernxmpp.org (who also comments in this thread) is also a maintainer for, is a project focused on forking existing clients (in a friendly manner, contributing patches upstream) to provide a consistent UX/"brand" across platforms. Really cool project!
It'd really be great if selfhosters could take snikket as container, tie it into one of their existing reverse proxies (like Traefik) and go to town. It's what I do for Synapse and it works a treat.
It would be nice if I could, say, post a picture or an emoji in one xmpp client and have it displayed in all other clients that are capable of sending emojis and pictures. XMPP has so many ways of doing both of those that if you're not both using the same client it's a total crapshoot.
Also the desktop clients are garbage:
- Libpurple is such a lowest-common-denominator implementation that lots of features I expect from XMPP tend to just not work (maybe there's configuration buried somewhere in pidgin to make them work, but I haven't found them).
- Psi got abandoned and so has like a dozen forks, some of which sometimes work; and many of which look a bit sketchy
- Gajim is almost great. However its a plugin-based system and too few plugins are enabled by default, so out-of-the-box it doesn't work quite right.
- Dino is getting to the point where it is usable, but if history is any clue, it will be abandoned shortly.
There used to be some promising BOSH clients that could be served as static JS to make a usable web client, but they are quickly becoming out-of-date.
XMPP is fully Unicode-aware and always has been, so clients lacking emoji support are probably due to platform-specific issues. I'd be interested in specific examples if you can name names.
libpurple (and derived clients such as Pidgin) have been lacking in XMPP love for some time, they've been focusing on more fundamental changes within the project. There are signs things may be improving, but unfortunately it's only a good example of XMPP in 2006. Things have moved on.
As you say, Gajim and Dino are good modern clients, and actively developed. I see no evidence of either of them being abandoned any time soon.
Converse.js and JSXC are actively-developed web clients. JSXC just received an EU grant to implement group audio/video calls.
Converse.js was "the best at the time" when I tried about a year ago. I just tried it now and it is far improved, so that's good.
JSXC was so-so when I tried a year ago. They seemed to be more focused on "Add XMPP to your web-page/webapp" rather than "use as a standalone" and a lot of the UI decisions seem informed by that (it very much tries to only use a fraction of the display, and managing more than about 3 chats starts to get crowded). Perhaps with theming I could make a good standalone app out of it, but it feels like swimming upstream.
[edit]
Didn't address your comment on Dino; I don't see any signs of it being abandoned either, this is more my cynical rule of "every time a jabber client gets stable enough that you can use the one from your distro's package manager, it gets abandoned" it's purely empirical and Gajim is the only exception to it so far in the past 20 years.
Not all clients send unicode emoji; some send their own emoji, as the clients emoji support predate's unicode's emoji support (2010). Psi is one example off the top of my head.
Sending an image from one client software will always result in either an inline image or a link to the image being displayed in other client(s). However there are combinations of clients which won't expand inline images from each other (IIRC conversations.js 6.x and dino seem to do things slightly differently, while conversations.im views both just fine).
Then there's the fact that not all Jabber clients will convert to jpeg, so e.g. in my Dino chat history I have a bunch of WebP images that don't expand inline, but show fine on Gajim and Conversations.im
> It would be nice if I could, say, post a picture or an emoji in one xmpp client and have it displayed in all other clients that are capable of sending emojis and pictures.
I don't personally think multi-device will ever be solved in a satisfactory way in XMPP. Like IRC, the whole architecture is fundamentally based on relaying messages. This works great for desktop computers, but as you add more devices with more intermittent connectivity, it breaks down quickly as you need to resort to hacks like sending deltas to other devices as carbon copies, which may or may not be delivered or interpreted correctly by clients. To solve it you need to fundamentally rethink your protocol not as one that relays messages, but synchronizes history. This is extremely hard to do without breaking backwards compatibility as you basically need to rearchitect every part of the stack. Matrix is a notable open messaging standard that does this and although it has it's flaws, multi-device experience is not one of them.
I'd definitely welcome XMPP making improvements in this area, but I'm not personally optimistic it can be done in time considering the generally dwindling userbase.
Jabber has almost completely solved this. TFA mentions how and notes the two places that have in-progress XEPs for improving (there's a race with MAC/Carbons where you have to either risk duplicate messages or dropping; current recommendation is to do the former and check for dupe).
On top of this, by far the best client I've used for XMPP is Android-only (Conversations.im). I have no problem using Gajim on my desktop and Conversations on my phone, and I have an SMS/MMS bridge (jmp.chat) that lets me send even to people without jabber from it. Multi-device and mobile is the one place where XMPP is ahead of 99% of the other messages, and it works similarly well to Matrix in my limited experience with Matrix.
In my experience (which was echoed by coworkers requests to resend messages, until we switched) there are a select few happy paths where it works reasonably well and a lot more where it doesn't. You seemed to agree with that in your original comment.
In general the problems with XMPP are rarely with missing checkboxes or things that miraculously don't exist somewhere in the hundreds of accepted and in-progress XEPs, but the long tail of user experience in the real world.
Linux desktop clients not named "gajim" were very slow to adopt Carbons as the delivery method. And in Gajim you needed to enable a plugin. Things were very bad in the transition period (which ended about 5 years ago?). At work we setup a jabber server for a small group of about 6 people and then more people started using it. It was running an ejabberd that was too old to support carbons. Once it became clear that some sort of IM solution was wanted, we came up with a list of features. Upgrading ejabberd and recommending proper clients fixed every box except "iOS client with push notifications" (XMPP didn't at the time support out-of-band push notifications, it does now).
And now every Zoom and Whatsapp and meet.jit.si user is. This sort of thing didn't really go away, companies just decided to construct walled gardens instead of federate.
WhatsApp used to be ejabberd, IIRC, but I'm sure they're both their own thing now. FunXMPP is WhatsApp's weird non-standard compression mechanism. Basically they took XMPP and replaced eg. <message> with <m> to save a few bytes, but it's been a while since I looked into it, it may do more now.
Not really. I can't easily find any statistics, but I just based it on the fact that a few years ago roughly half of my techy friends used XMPP. Many ran their own servers and all of the clubs had one. The work one had hundreds of users online at all times. Today all of these numbers are zero. Roughly split 40/40/20 between telegram, matrix and discord.
The killer app of centralized chat systems is their general protections against unwelcome abusive contact from strangers (spam, harassment, death threats). Everyone focuses on the protocol but I focus on the experience, what with having been stalked for twenty years by an Internet-competent stalker. So I see nothing in this Modern XMPP website that is competitive on that point, which means I'll likely continue ignoring XMPP, same as I do IRC these days. Is there something I've missed that Modern XMPP implements that protects against abusers?
Do you mean forced non-anomymity to the provider so every time you block them they need a new phone number to contact you again?
Figuring out the right combination of G-lines to get some bastard to stay out on IRC is a bit trickier, certainly, but I'm sufficiently stubborn that even the worst of the harassers I've been chasing down for users have given up before I have.
I don't know if what you describe is the answer, but certainly I mean "someone is implementing anti-attacker processes upon new signups and existing accounts", so that the majority of abusive attacks are stopped before I'm required to Block someone.
As you describe with G-lines, without a centralized anti-attacker system, it is very much the whack-a-mole game that I'm accustomed to from XMPP or IRC.
> without a centralized anti-attacker system, it is very much the whack-a-mole game
Unfortunately, even centralized networks play this whack-a-mole game. Facebook/Google requesting ID cards or phone number has unfortunately not eliminated abuse from their network. Which is not to say there's no way we can improve the situation (see my other comment).
Your statement is incomplete, and presents only the framing "abuse was not eliminated", as if eliminating abuse were a boolean Y/N flag and therefore all steps taken to date are a total failure.
The two centralized networks you referenced have eliminated some abuse from their network by taking those steps.
As I said elsethread, I won't try to persuade you that it's right for them to have taken steps, but I'm certain we still both agree that it's impossible to completely eliminate abuse from any system containing user-generated content, and therefore the metric of success you set ("eliminated") is provably unattainable, which does^ invalidate your framing.
^ (unless you think it's possible to fully eliminate abuse, in which case you have a trillion dollar startup idea to pursue, because we all sure need that!)
> The two centralized networks you referenced have eliminated some abuse from their network by taking those steps.
That is true, but at the same time they have also eliminated many legitimate users and placed remaining users in dangerous situations by requesting more personal information that can and will be leaked and will be used again them.
Also, their anti-abuse model relies exclusively on the benevolence of law enforcement: that's why they collect more information in order to cooperate with law enforcement. However in most (all?) parts of the world law enforcement is neither concerned with protecting people, especially victims of cyber-harassment and misogynistic violence.
Internally, Facebook and such platforms usually combat violent (as in, blood is visible) and "indecent" (a woman breastfeeding in a photo, what a scandal) content but not hateful fascist/masculinist propaganda. It usually takes a massive media scandal for such platforms to close down well-known groups coordinating harassment/doxxing campaigns.
From my personal and political perspective as a politically-active non-binary person, that tradeoff is not worth it. But i can understand and respect if your perspective on the matter is different.
> unless you think it's possible to fully eliminate abuse
I don't think it's possible to fully eliminate abuse ever, whether in cyberspace or in the physical space. We can however, develop collective processes and reflexes in order to strongly mitigate the harm done by people attempting abuse.
From a protocol's perspective, reputation systems and WoTs are not hard to specify. The real problem that has not truly been explored yet is how to develop a good UI/UX for this pattern, where the user can turn many knobs until they feel safe, but they don't have to do it in order to enjoy reasonable defaults.
I'm not at all saying it's an easy problem to tackle, but there is also interest in anti-abuse systems in other federated protocols such as ActivityPub. See for example this talk "Decentralized social networks vs the trolls" from the last AP Conference: https://conf.tube/videos/watch/d8c8ed69-79f0-4987-bafe-84c01...
I sure hope we can make a better situation overall, and that sacrificing privacy to reach that is not an option on the table. Privacy/pseudonymity is a fundamental pillar of anti-abuse schemes and removing it for short-term gains is sure to backfire sooner or later down the road.
I sort of wish we had an effective way to say e.g. "no DMs from account that isn't <this> verified" on less centralised systems - the "no DMs from unregistered users" switch on some ircds being the most primitive possible gesture in such a direction.
I imagine you'd want to turn that dial rather higher than I would, and with good reason, but having a dial at all seems like a good way to avoid a whole bunch of other potential problems.
(though "if this was going to happen it probably already would have" is likely a good argument for not holding one's breath)
It's a draft XEP, so it's not widely implemented yet. I know the server I'm using supports it via a plugin, but I don't think even Conversations supports it yet.
The one thing I do think XMPP really has going on for privacy protection is that multi-user chats can be configured to not give out the real JID of members to other members, which is something I kind of miss in Matrix.
> It's a draft XEP, so it's not widely implemented yet.
Just to pick on this, sorry. The XSF terminology is not obvious (it was inherited from other standards organizations).
Draft here means the protocol is absolutely in use, it just means that it is theoretically open to changes. The next stage is "Final", and that is typically only reached after substantial time in production (it's basically a statement that the document is 100% finished and won't ever be updated).
There have been proposals to change the term "Draft" to "Active" or similar.
Block commands are not the solution I'm describing, sorry.
If the Block command is the network's only available abuse prevention tool, then chat network has failed to do a good enough of job of implementing anti-abuse protections.
(I'm aware that some people don't believe in network-level anti-abuse protections, and I'm not going to try to convince anyone to agree with me. This is just how I evaluate whether a given chat network is accessible to me or not. XMPP is one such network, and doesn't have any, so.)
I'm sorry that's happened to you. There definitely should be ways to mitigate that. There's not a lot happening on this front to my knowledge in the Jabber/XMPP ecosystem, but there's already building blocks in place which effectively limit abuse:
- Jabber addresses (JIDs) are not broadcast to everyone in public chat, only to the admins of services you use, except in private encrypted chatrooms (for encryption key retrieval)
- most public chatrooms support nicknames, so you can have different nicknames in every room
- it's easy with some clients to support multiple accounts to separate your activities
- your address cannot be automatically gathered from 3rd party information (eg. a phone number) unless you precisely declare it in your contact information (vCard) or use a server which relies on such feature (like quicky.im to use your phone number as account name)
- 3rd party information cannot be leaked from your address unless you explicitly declare it in your contact information (vCard) ; it's quite common for services based on phone numbers such as Signal to leak your phone number to third parties
Unfortunately, there is nothing yet like a Web of Trust or reputation system which you could use, for example to only display friend requests from friends of friends or something like that. And there's no support for single-use aliases as we have in the email world. But there is some level of interest for that and other fields of experimentation, and there's overall strong interest in keeping users safe and happy from the community at large, and a vast majority of server operators.
Many servers are operated by non-profits and much like in the Fediverse don't hesitate to defederate with a server whose admins are not interested in preventing abuse from their network. Following some issues with misogynistic neonazis in a public chatrooms a few months ago, we also setup a chatroom to discuss such issues on xmpp:abuse@joinjabber.org?join and you're more than welcome to join us and formulate ideas on how we can improve in this domain. In case you don't want to setup an account for that, you can reach the chatroom via https://anon.joinjabber.org (works on Tor browser).
It's okay. It started on ICQ and it's continued on every major Internet-connected social network that has ever existed. Exhaustion appears to have set in somewhat, but I'm still comforted to hear that you're studying the problem.
There's certainly no support for "I don't wish to be contacted by people who are confirmed abusers" (which requires some sort of centralization and human review), because neither voting nor web of trust on their own will address the problems of sock puppets online versus real human beings, cooperative manipulation by groups of abusers, and how to select among all possible codes of conducts for one that defines and demonstrates acceptable (to me) decisions about what is abusive behavior.
I appreciate the invite, but my day job takes priority, and I'm not able to allocate time for side projects this year.
> neither voting nor web of trust on their own will address the problems of sock puppets online versus real human beings, cooperative manipulation by groups of abusers
That's definitely what WoTs are about, because a group of harassers trying to boost one another's reputation will not be part of your social graph (or at least not closely) so their scheme would be useless.
The main reason WoTs have turned out of fashion is they leak an incredible about of metadata about interpersonal relationships, which can lead to imprisonment or outright death ("We kill based on metadata" - NSA). However there's active research as part of the GNU/Net project on Fog Of Trust, a zero-knowledge implementation of a WoT which preserves the social graph. I hope more serious cryptographers give this approach a look because from my non-cryptographer's perspective it looks like it would offer the best from both worlds of decentralized WoTs and centralized anti-abuse systems.
> how to select among all possible codes of conducts
The problem with CoCs is they're abstract constructs often disconnected from actual moderation practices. You can have the worst CoC or no COC at all and very friendly/respectful admins who will go to lengths to protect their users, or on the contrary a very good-looking CoC that will never be respected in practice because admins will find a loophole in there or threaten you for your outstanding hysteria when pointing out that you've been receiving hundreds of death/rape threats in the past hours.
It's the same as with any legal system. Of course a more respectful legal code is better than a bad legal code, but that's not what's actually solving problems. Legal tools cannot solve human (political) problems, only we collectively can do it. The same can be said about the law in most countries, it's just on paper but however it gets applied/interpreted is up to the cops and judges who are happy to make your life as a victim more miserable.
> I appreciate the invite, but my day job takes priority, and I'm not able to allocate time for side projects this year.
Good luck for the day job! If by any chance you can still find time to collect a few links you find would give us important perspective on the topic, or even to write down your own reflections, consider us interested.
You hit on the real core problem: There's no connection between the legal protections against abusive behaviors by strangers and unrestricted communication with strangers over the Internet :)
Well if you believe legal constructs and centralized law enforcement are the answer to abusive behavior, then sure. In my case, and that of most people i know, it's very rarely brought any satisfying solution, even when not talking about internet abuse. I have exactly zero trust in the judicial system and law enforcement agencies, and to be more precise as an anarcha-feminist i believe their structure and culture is part of the problem, promoting many forms of abuse across society.
See for example Angela Davis in "Are prisons obsolete?" or Emma Goldman in "Prisons: a social crime and failure" for (dated) explorations of these questions.
I love their social networking features and have periodically used their nodes but I've never managed to get family and friends on board. I suspect easier clients would be key there, but last I checked (2015, admittedly) server support for movim wasn't great.
Author here. Yes, Movim is a great project! The Movim author has indeed contributed to the Modern XMPP documentation.
As one of the other commenters pointed out, most of the current docs here are aimed at a particular use-case of XMPP, which I tend to call "personal messaging".
I think the Modern XMPP project is just about growing to the point where it will make sense to potentially split some of the recommendations into different "profiles", so you would have a "social" profile of XMPP which Movim sits squarely in.
Finally, regarding server support, Movim has always been pushing at the edge of XMPP, which is great. It certainly led to improvements in Prosody (the server implementation I work on) since you tried it in 2015, so it may well be worth another try. I don't personally use it myself (yet?), but probably someone from the Movim community could give advice.
The ideas/promises of both protocols are roughly the same (more than a decade apart), but there's major differences in the approach. We have a summary list of pros & cons here: https://joinjabber.org/faqs/advanced/#faq-advanced-matrix
Let us know if something is missing or not clear in there. I would probably add to that that Jabber/XMPP has several producion-grade free-software server implementations (ejabberd/prosody/tigase, maybe metronome?) whereas matrix has only one (dendrite/conduit are still experimental although they made great progress). Likewise, Matrix only has one reference client implementing all features. In both cases, the reference implementation is bloated and not compatible with low-end/second-hand hardware which is very popular in the Jabber/XMPP ecosystem.
I expect the situation to keep steadily improving on both sides, or to quote our FAQ:
> As you can see, both protocols have their strengths and weaknesses, but they still operate on similar principles. In theory, it would have been possible (and easier) to build the matrix protocol on top of XMPP to avoid fragmenting the ecosystem. Why this was not done is a good question, but the fact is we now have two protocols/ecosystems with similar goals, and we should try to dismantle our egos and work for interoperability, for the benefit of end-users.
However, if your goal is censorship-resilience (not privacy) against state actors, then i would strongly recommend to use Matrix instead of Jabber/XMPP because decentralized rooms are tailored to that threat model.
122 comments
[ 2.8 ms ] story [ 190 ms ] threadThere are other ecosystems that are going "fine" that have centralised, official documentation and don't require a third party to intervene and collate documentation and recommendations in an attempt to make it easier for developers. The fact this is necessary, or people feel is necessary, makes me want to avoid XMPP at all costs. That's just my very shallow surface level opinion.
With all that said, i have to say; what you're doing here is commendable. I don't mean to (pardon my language) shit on something you seem to have worked very hard on. Doing something like this isn't an easy task I'm sure.
You see something similar with end-user software like Adobe's entire suite where the official docs are basically useless if you just want to learn the common operations quickly and so you have to rely on third-party books and tutorials (like the Dummies books).
It's just like when you do web stuff you may read from MDN, csstricks or smashing magazine. It doesn't mean that the W3C/IETF specs are useless, far from it. But in my view it's useful to find guidance in a nebula of specifications and endless UX possibilities.
Just look at this relative lack of stuff: https://docs.modernxmpp.org/client/protocol/
People saying "look at all this stuff" is one reason the Modern XMPP project was born. To draw attention to the actually important things that developers need to read.
The XSF receives a lot of submissions each year. Many of these proposals never make it past the "experimental" stage. Others are only applicable in certain domains (IoT, etc.). Over time some of these become widely adopted and progress through the standards process. Some do not.
The XSF publishes annually the "compliance suite" which describes what clients and servers should be supporting in different areas: https://xmpp.org/about/compliance-suites.html
> It has never seen serious adoption because nobody wants to touch it - and for good reasons.
That's outright false. There's many successful commercial products using XMPP right now (eg. WhatsApp/Zoom or games and gaming systems like Fortnite, Origin, League of Legends) including for non-IM usecases (Google Cloud Print, Firebase Cloud Messaging, Nintendo Switch, Apple's push notifications).
In the free-software world, there's actively maintained featureful clients (gajim/dino on desktop and snikket family of clients on mobile) and servers (ejabberd/proosdy/tigase). I can't say there's no bugs but i can say with confidence they're actively being hunted down.
> It leads to ridiculous overengineering through layered complexity.
Layering complexity may sound like engineering, but that's where the "eXtensible" promise of XMPP comes from. The same goes with Matrix/ActivityPub protocol: there's a reason people are doing it this way, and that reason is not "overengineering".
> Take a lesson from IRC, a group-chat protocol that, despite its age, works and scales amazingly well.
The protocol works remarkably well because it's dead simple. However, implementing a decent client/server that plays well with others is not easy (see IRCv4 debates) and each server in practice operates differently, more so even than XMPP servers.
> It wouldn't take much fix the warts on IRC and extend it to cover everything that XMPP tries to do.
Please by all means try. It'll take you far more time to design, and you can be 100% sure you're going to break many existing clients and servers by extending the IRC protocol. XMPP/Matrix clients on the other hand can handle missing features gracefully because the protocol is namespace'd/schema'd properly.
I appreciate that concern for fighting NIH and that's a criticism i've addressed to the Matrix project myself, that it could have been implemented on top of existing XMPP clients and servers with two simple XEPs: one for decentralized chatrooms and state resolution, the other for client-to-server JSON API. But when comparing those newer federated protocols with IRC, i think the comparison has no grounds.
Let me know if you're not convinced by these answers or have more questions.
From a client perspective, picking a good/modern XMPP library will save you a lot of headaches, because a good library is supposed to hide away the complexity. If you're not sure what to pick, just ask around in dev chatrooms.
Happy hacking
There are a bunch of implementations there.
https://nodered.org/
https://cookbook.nodered.org/mqtt/connect-to-broker
https://en.wikipedia.org/wiki/RabbitMQ
to run the IoT stuff in my house. Mostly I access it through AQMP but it supports MQTT also. An asyncio-driven python script takes events from the outside world and systems that have an cloud component like SmartThings and posts them to RabbitMQ. Other scripts listen for events, make things happen, log data to arangodb, etc.
On paper XMPP supports M2M applications but it's not a great fit compared to other protocols.
From what I've seen, XMPP is used in IoT more for the federation aspect rather than as the "last mile" to the sensors/devices. Cases where you need interoperability and security across different sites/organizations.
In any case, the Modern XMPP project (this article) currently only focuses on XMPP for the IM use-case.
The vague descriptions like "modern" usually mean "More like whatever the author's today's usecase is", and good luck trying to get anyone except yourself onboard with that...
So rather than "modern XMPP" this looks like "how to use XMPP to build a SMS-like messaging program for mobile phones". Now it's clear who is the target of the document and you avoid a weasel term like "modern" which also annoys every other consumer of the protocol.
As for the focus, you're right, there is a bunch of advice that is specific to this class of personal messaging apps. As time, resources and interest allow, I would like to grow it to document other "profiles" of XMPP as well. For example the Slack-like "team chat" use-case, or even IoT.
If you're using XMPP in a particular domain and you feel it would benefit from documentation like this, PRs are absolutely welcome. It's in scope.
Sent over UDP this had stood the test of time for a couple decades or so.
Disadvantage: the rest of the system was also written in C++ and it was impossible to get those who had access to the source code and knew it to fix anything. As a result the system looked more and more antiquated and there were more and more hoops to jump through to get it working with every new version of Windows:-/
Edit: that said, I think your comment is a bit off topic :-)
You have a protocol there, you have an understanding of what's expected on either side of that communication. That is the definition of a protocol. And if that's for Web stuffs, as you say, then you must be implementing something related to HTTP/HTTPS, protocols.
When you are establishing a standard that clients and servers will advertise that they adhere to, don't leave technical decisions to the end-user by default. Make the best decision that you can.
In this document, there's discussion about STARTTLS vs TLS-from-the-beginning, and how to deal with that in the UI. Don't do that. Decide that TLS-from-the-beginning is the requirement for client-server interactions, and now you don't have a UI issue. You already decided that /resource and priority were not going to be useful; make this decision too.
In general, resolve incompatibilities.
But it should probably be really clear that the correct way is X, and support for Y should be buried somewhere so most users don't have to think about it, if you do feel a need to retain support for it.
I was going to remove it, but I don't think that's the problem. The whole section you mention is the problem - all these options should be auto-discovered, and in fact are, in any normal deployment. It's sometimes used for unusual deployments (connecting over a VPN, or a testing/development server).
For normal deployments, XMPP already defines which host/port/TLS-mode to use and how a client can pick between them.
So I've just merged an update that clarifies that these options are not generally recommended for implementations to expose to users, except to support testing/development.
I'd rather have this documented (i.e. "if you are going to do this anyway, at least do it correctly, like this").
I think that's a slightly different thing than what was suggested. For some options, auto-discovery is fine. For security, I think the current consensus is just make the best choice you can, and if something really requires a major change, version the standard (major version, like from 1.x to 2.0, so it's obvious). Auto-discovery of a setting to do with security is just another possible location where a security issue might be found because or a poor implementation of the standard.
Probing could be implemented, but that quickly introduces complexity (and code just as likely for security issues to hide in) to implementations. It would be nice to one day say "only support direct TLS" for example, but that's not the reality of today's network (looks like ~41% of servers advertise direct TLS as of today, slowly climbing).
So the happy path is using auto-discovery as standardized. If you go the manual path and configure a host/port, I don't think probing is sensible to recommend, and I don't think strictly assuming only one or the other is going to fly right now.
Maybe one way that might look is user clients that probe, but when defining how servers should act, there's a "one true way" unless they aren't adhering to Modern XMPP spec or best practices. Changes like this need a push from outside or they never happen, and someone just being able to point at a spec and say "look, you aren't compliant with Modern XMPP, the world has moved on from what you're doing" is incredibly useful in spurring change.
I agree it doesn't necessarily make sense for a client options perspective, but it might be a good principle to adopt or consider for other aspects of the document. If you want to actually push things forward, I think it's very useful way to do so.
I think it's best described as something of an evolving "current best practices" document. There is certainly room to tell developers to implement (or not implement) certain features. Indeed that is done already for some things (e.g. file transfer mechanisms).
I think this specific TLS example is unfortunate because it's something that is documented only for advanced use (recognising that some people may need it for specific purposes that some clients may want to support).
On principle I agree, but ironically the exact scenario you suggest was the single biggest event that "killed" XMPP as we used to know it. In late 2013 there was an XMPP community manifesto calling for mandatory TLS (even STARTTLS) for XMPP server-to-server communication by a drop-dead date in early 2014: https://github.com/stpeter/manifesto/blob/master/manifesto.t...
"The schedule we agree to is:
- January 4, 2014: first test day requiring encryption
- February 22, 2014: second test day
- March 22, 2014: third test day
- April 19, 2014: fourth test day
- May 19, 2014: permanent upgrade to encrypted network, coinciding with Open Discussion Day <http://opendiscussionday.org/>"
Well-intentioned for sure, but the one XMPP provider with an actual critical mass of users (Google Talk) remained non-TLS-only, all Google Talk users dropped off the federated XMPP network after May 2014, and so XMPP effectively ceased to matter.
Google's XMPP server continued to accept unencrypted connections for many years after this point. I think the XMPP operators made the right choice, rather than letting Google weaken the security of the entire network.
Definitely, but I think it was a huge PR failure that we in the XMPP community were the ones to sever the conversational link. Users shouldn't be expected to think about the protocol details, hence this thread, and it was an XMPP community decision that resulted in people being suddenly unable to talk to their friends.
We provided perfect justification for any Google project manager to look at the stats and see zero incoming s2s connections as justification to kill Talk entirely so they could Move Fast™ on Hangouts or whatever.
I guarantee we pushed more overall XMPP users to WhatsApp/FB than we pushed Google Talk users to privacy-first XMPP hosts since it's not like Google popped up any alert in the GMail Talk UI explaining to people why their nerd friends all suddenly vanished from their buddy lists. The moment any of those people used a non-XMPP service to reach out and ask "What's up?" we had already lost :/
That UX description is intended for "additional connection options" prompts, which are useful when your server is misconfigured or you want to reach it in a different manner than advertized over DNS (eg. over a .onion address).
"Advanced" connection settings is required when the vhost you are connecting to doesn't match the hostname you need to reach on the network. For example, if you're reaching your server over a VPN/SSH/IPSEC tunnel.
Another example is if you wish to login as user@foobar.com by reaching foobar.onion. This is useful if you want to be part of the broader Jabber federation, in which not every host supports federation over onion addresses (i'd be curious to make stats about that) but it still gives you the security guarantees of Tor when reaching your server (though not for server-to-server connections).
Onion name discovery for automatically upgrading to onion routing when Tor is available client-side is not yet specified within the XMPP ecosystem. Onion discovery in the HTTP ecosystem is usually done via Onion-Location HTTP header (HTTPS only), in the email ecosystem they use _onion-mx DNS SRV records: see https://gitweb.torproject.org/tor-browser-spec.git/tree/prop... and https://github.com/ehloonion/onionmx/blob/master/SRV.md respectively
Implementing something similar XMPP side would be easy. Prosody already has a community mod_onions, but currently only supports a static map of hosts to their onion addresses. It could use some love: https://modules.prosody.im/mod_onions.html
Another problem we face from a UX perspective for onion services is that currently XMPP server implementations are very strict about which node/resource messages are intended for, and to my knowledge none support aliasing systems as we have in the email world. In this specific example application of aliases, there's currently no way (that i know of) to have the same account across .org/.onion domains and having servers to know it's the same account in a federated manner, eg. to prevent you from adding the same person twice to your contact list.
All in all there's interesting challenges and none of them is really hard so if you'd like to get involved or just let us know about your ideas and expectations, feel free to drop by xmpp:privacy@joinjabber.org?join
Whether that's a huge concern or not is a good debate. In the case where the .onion is a security upgrade to the network connection for a "normal" vhost, then it's not a problem because your resolver has already learned about the vhost you'd like to reach (via the SRV query).
The real problem would be if a client tried to resolve foobar.onion through DNS when provided with a user@foobar.onion login. According to spec DNS software should not do that, but from a super quick review it appears a number of DNS implementations still do that.
I'm not sure what the best approach is here. But surely there's a solution to find.
Think of it as Apple making a bunch of decisions for themselves and their users and it keeping problematic for future adoption.
The spirit of open source is voluntary participation and openness to all platforms and ideas. Though I cannot understand the distinction behind TLS and STARTTLS , I don’t think locking in one option will make it all that better.
StartTLS starts unencrypted then "upgrades" the connection to TLS if the client and server support it. This leaves a whole lot of room for an active attacker on the network to prevent all forms of encryption, rendering TLS essentially useless.
That's not to say TLS is perfect: having to trust an entire list of third-party CAs with their own incentives/pressures is a flawed model. But TLS is better than no TLS, so direct TLS is better than StartTLS.
This is a common misconception about STARTTLS. It is certainly possible to implement it poorly (and that has certainly happened). But there are no inherent security issues with a correct implementation. An active attacker can just as easily block TLS handshake packets on a direct TLS connection.
The problem used to be that many software implementations (not just XMPP) would happily continue unencrypted if STARTTLS was not offered. But these days everyone requires TLS, and will not proceed to connect unless TLS is in use (regardless of whether it is negotiated or "direct").
However the future is certainly direct TLS, that has been obvious for some time. It has many advantages, such as allowing the use of off-the-shelf middleware such as loadbalancers and proxies, and bypassing certain firewalls. It's also easier to implement, and there is of course the (relatively new) ESNI which is beneficial.
Thanks for the correction. I thought that was in fact a "feature" from a StartTLS perspective.
> easily block TLS handshake packets on a direct TLS connection
But then no downgrade attack is possible at all.
> (relatively new) ESNI
Is there any deployment of that in XMPP clients/servers yet?
Google closing down XMPP support was indeed a sad day for everyone. But there are plenty of us supporting the idea that Google does not control the internet.
If you're interested to know what's happening in the XMPP community these days, there are monthly newsletters published to the blog ( https://xmpp.org/category/newsletter.html ) and by email ( https://xmpp.org/newsletter.html ).
Also important to note that this project is still aimed at developers (as is XMPP and all the protocol documentation). What's needed are friendly projects promoting to end-users.
Current work in that area would be:
- https://snikket.org/ - a client+server package of XMPP software for personal messaging (disclaimer: I started this project).
- https://joinjabber.org/ - a community of folk working to support new users joining the network with documentation and infrastructure.
I’m happy about each one.
Snikket, which a maintainer of modernxmpp.org (who also comments in this thread) is also a maintainer for, is a project focused on forking existing clients (in a friendly manner, contributing patches upstream) to provide a consistent UX/"brand" across platforms. Really cool project!
If you feel like trying it with Traefik and submitting some example config for the docs, that would be very welcome :)
Also the desktop clients are garbage:
- Libpurple is such a lowest-common-denominator implementation that lots of features I expect from XMPP tend to just not work (maybe there's configuration buried somewhere in pidgin to make them work, but I haven't found them).
- Psi got abandoned and so has like a dozen forks, some of which sometimes work; and many of which look a bit sketchy
- Gajim is almost great. However its a plugin-based system and too few plugins are enabled by default, so out-of-the-box it doesn't work quite right.
- Dino is getting to the point where it is usable, but if history is any clue, it will be abandoned shortly.
There used to be some promising BOSH clients that could be served as static JS to make a usable web client, but they are quickly becoming out-of-date.
libpurple (and derived clients such as Pidgin) have been lacking in XMPP love for some time, they've been focusing on more fundamental changes within the project. There are signs things may be improving, but unfortunately it's only a good example of XMPP in 2006. Things have moved on.
As you say, Gajim and Dino are good modern clients, and actively developed. I see no evidence of either of them being abandoned any time soon.
Converse.js and JSXC are actively-developed web clients. JSXC just received an EU grant to implement group audio/video calls.
JSXC was so-so when I tried a year ago. They seemed to be more focused on "Add XMPP to your web-page/webapp" rather than "use as a standalone" and a lot of the UI decisions seem informed by that (it very much tries to only use a fraction of the display, and managing more than about 3 chats starts to get crowded). Perhaps with theming I could make a good standalone app out of it, but it feels like swimming upstream.
[edit]
Didn't address your comment on Dino; I don't see any signs of it being abandoned either, this is more my cynical rule of "every time a jabber client gets stable enough that you can use the one from your distro's package manager, it gets abandoned" it's purely empirical and Gajim is the only exception to it so far in the past 20 years.
Not all clients send unicode emoji; some send their own emoji, as the clients emoji support predate's unicode's emoji support (2010). Psi is one example off the top of my head.
Sending an image from one client software will always result in either an inline image or a link to the image being displayed in other client(s). However there are combinations of clients which won't expand inline images from each other (IIRC conversations.js 6.x and dino seem to do things slightly differently, while conversations.im views both just fine).
Then there's the fact that not all Jabber clients will convert to jpeg, so e.g. in my Dino chat history I have a bunch of WebP images that don't expand inline, but show fine on Gajim and Conversations.im
I don't personally think multi-device will ever be solved in a satisfactory way in XMPP. Like IRC, the whole architecture is fundamentally based on relaying messages. This works great for desktop computers, but as you add more devices with more intermittent connectivity, it breaks down quickly as you need to resort to hacks like sending deltas to other devices as carbon copies, which may or may not be delivered or interpreted correctly by clients. To solve it you need to fundamentally rethink your protocol not as one that relays messages, but synchronizes history. This is extremely hard to do without breaking backwards compatibility as you basically need to rearchitect every part of the stack. Matrix is a notable open messaging standard that does this and although it has it's flaws, multi-device experience is not one of them.
I'd definitely welcome XMPP making improvements in this area, but I'm not personally optimistic it can be done in time considering the generally dwindling userbase.
On top of this, by far the best client I've used for XMPP is Android-only (Conversations.im). I have no problem using Gajim on my desktop and Conversations on my phone, and I have an SMS/MMS bridge (jmp.chat) that lets me send even to people without jabber from it. Multi-device and mobile is the one place where XMPP is ahead of 99% of the other messages, and it works similarly well to Matrix in my limited experience with Matrix.
In general the problems with XMPP are rarely with missing checkboxes or things that miraculously don't exist somewhere in the hundreds of accepted and in-progress XEPs, but the long tail of user experience in the real world.
Once Upon A Time every GMail user was also an XMPP user.
For me iOS (upcoming version), Web and Android (internal beta) clients sync no worse than Telegram.
Figuring out the right combination of G-lines to get some bastard to stay out on IRC is a bit trickier, certainly, but I'm sufficiently stubborn that even the worst of the harassers I've been chasing down for users have given up before I have.
As you describe with G-lines, without a centralized anti-attacker system, it is very much the whack-a-mole game that I'm accustomed to from XMPP or IRC.
Unfortunately, even centralized networks play this whack-a-mole game. Facebook/Google requesting ID cards or phone number has unfortunately not eliminated abuse from their network. Which is not to say there's no way we can improve the situation (see my other comment).
The two centralized networks you referenced have eliminated some abuse from their network by taking those steps.
As I said elsethread, I won't try to persuade you that it's right for them to have taken steps, but I'm certain we still both agree that it's impossible to completely eliminate abuse from any system containing user-generated content, and therefore the metric of success you set ("eliminated") is provably unattainable, which does^ invalidate your framing.
^ (unless you think it's possible to fully eliminate abuse, in which case you have a trillion dollar startup idea to pursue, because we all sure need that!)
That is true, but at the same time they have also eliminated many legitimate users and placed remaining users in dangerous situations by requesting more personal information that can and will be leaked and will be used again them.
Also, their anti-abuse model relies exclusively on the benevolence of law enforcement: that's why they collect more information in order to cooperate with law enforcement. However in most (all?) parts of the world law enforcement is neither concerned with protecting people, especially victims of cyber-harassment and misogynistic violence.
Internally, Facebook and such platforms usually combat violent (as in, blood is visible) and "indecent" (a woman breastfeeding in a photo, what a scandal) content but not hateful fascist/masculinist propaganda. It usually takes a massive media scandal for such platforms to close down well-known groups coordinating harassment/doxxing campaigns.
From my personal and political perspective as a politically-active non-binary person, that tradeoff is not worth it. But i can understand and respect if your perspective on the matter is different.
> unless you think it's possible to fully eliminate abuse
I don't think it's possible to fully eliminate abuse ever, whether in cyberspace or in the physical space. We can however, develop collective processes and reflexes in order to strongly mitigate the harm done by people attempting abuse.
From a protocol's perspective, reputation systems and WoTs are not hard to specify. The real problem that has not truly been explored yet is how to develop a good UI/UX for this pattern, where the user can turn many knobs until they feel safe, but they don't have to do it in order to enjoy reasonable defaults.
I'm not at all saying it's an easy problem to tackle, but there is also interest in anti-abuse systems in other federated protocols such as ActivityPub. See for example this talk "Decentralized social networks vs the trolls" from the last AP Conference: https://conf.tube/videos/watch/d8c8ed69-79f0-4987-bafe-84c01...
I sure hope we can make a better situation overall, and that sacrificing privacy to reach that is not an option on the table. Privacy/pseudonymity is a fundamental pillar of anti-abuse schemes and removing it for short-term gains is sure to backfire sooner or later down the road.
I imagine you'd want to turn that dial rather higher than I would, and with good reason, but having a dial at all seems like a good way to avoid a whole bunch of other potential problems.
(though "if this was going to happen it probably already would have" is likely a good argument for not holding one's breath)
It's a draft XEP, so it's not widely implemented yet. I know the server I'm using supports it via a plugin, but I don't think even Conversations supports it yet.
The one thing I do think XMPP really has going on for privacy protection is that multi-user chats can be configured to not give out the real JID of members to other members, which is something I kind of miss in Matrix.
Just to pick on this, sorry. The XSF terminology is not obvious (it was inherited from other standards organizations).
Draft here means the protocol is absolutely in use, it just means that it is theoretically open to changes. The next stage is "Final", and that is typically only reached after substantial time in production (it's basically a statement that the document is 100% finished and won't ever be updated).
There have been proposals to change the term "Draft" to "Active" or similar.
XEP-0191 is supported by practically all servers: https://compliance.conversations.im/test/xep0191/
And supported by all modern clients.
If the Block command is the network's only available abuse prevention tool, then chat network has failed to do a good enough of job of implementing anti-abuse protections.
(I'm aware that some people don't believe in network-level anti-abuse protections, and I'm not going to try to convince anyone to agree with me. This is just how I evaluate whether a given chat network is accessible to me or not. XMPP is one such network, and doesn't have any, so.)
- Jabber addresses (JIDs) are not broadcast to everyone in public chat, only to the admins of services you use, except in private encrypted chatrooms (for encryption key retrieval) - most public chatrooms support nicknames, so you can have different nicknames in every room - it's easy with some clients to support multiple accounts to separate your activities - your address cannot be automatically gathered from 3rd party information (eg. a phone number) unless you precisely declare it in your contact information (vCard) or use a server which relies on such feature (like quicky.im to use your phone number as account name) - 3rd party information cannot be leaked from your address unless you explicitly declare it in your contact information (vCard) ; it's quite common for services based on phone numbers such as Signal to leak your phone number to third parties
Unfortunately, there is nothing yet like a Web of Trust or reputation system which you could use, for example to only display friend requests from friends of friends or something like that. And there's no support for single-use aliases as we have in the email world. But there is some level of interest for that and other fields of experimentation, and there's overall strong interest in keeping users safe and happy from the community at large, and a vast majority of server operators.
Many servers are operated by non-profits and much like in the Fediverse don't hesitate to defederate with a server whose admins are not interested in preventing abuse from their network. Following some issues with misogynistic neonazis in a public chatrooms a few months ago, we also setup a chatroom to discuss such issues on xmpp:abuse@joinjabber.org?join and you're more than welcome to join us and formulate ideas on how we can improve in this domain. In case you don't want to setup an account for that, you can reach the chatroom via https://anon.joinjabber.org (works on Tor browser).
There's certainly no support for "I don't wish to be contacted by people who are confirmed abusers" (which requires some sort of centralization and human review), because neither voting nor web of trust on their own will address the problems of sock puppets online versus real human beings, cooperative manipulation by groups of abusers, and how to select among all possible codes of conducts for one that defines and demonstrates acceptable (to me) decisions about what is abusive behavior.
I appreciate the invite, but my day job takes priority, and I'm not able to allocate time for side projects this year.
That's definitely what WoTs are about, because a group of harassers trying to boost one another's reputation will not be part of your social graph (or at least not closely) so their scheme would be useless.
The main reason WoTs have turned out of fashion is they leak an incredible about of metadata about interpersonal relationships, which can lead to imprisonment or outright death ("We kill based on metadata" - NSA). However there's active research as part of the GNU/Net project on Fog Of Trust, a zero-knowledge implementation of a WoT which preserves the social graph. I hope more serious cryptographers give this approach a look because from my non-cryptographer's perspective it looks like it would offer the best from both worlds of decentralized WoTs and centralized anti-abuse systems.
> how to select among all possible codes of conducts
The problem with CoCs is they're abstract constructs often disconnected from actual moderation practices. You can have the worst CoC or no COC at all and very friendly/respectful admins who will go to lengths to protect their users, or on the contrary a very good-looking CoC that will never be respected in practice because admins will find a loophole in there or threaten you for your outstanding hysteria when pointing out that you've been receiving hundreds of death/rape threats in the past hours.
It's the same as with any legal system. Of course a more respectful legal code is better than a bad legal code, but that's not what's actually solving problems. Legal tools cannot solve human (political) problems, only we collectively can do it. The same can be said about the law in most countries, it's just on paper but however it gets applied/interpreted is up to the cops and judges who are happy to make your life as a victim more miserable.
> I appreciate the invite, but my day job takes priority, and I'm not able to allocate time for side projects this year.
Good luck for the day job! If by any chance you can still find time to collect a few links you find would give us important perspective on the topic, or even to write down your own reflections, consider us interested.
See for example Angela Davis in "Are prisons obsolete?" or Emma Goldman in "Prisons: a social crime and failure" for (dated) explorations of these questions.
https://movim.eu/
I love their social networking features and have periodically used their nodes but I've never managed to get family and friends on board. I suspect easier clients would be key there, but last I checked (2015, admittedly) server support for movim wasn't great.
As one of the other commenters pointed out, most of the current docs here are aimed at a particular use-case of XMPP, which I tend to call "personal messaging".
I think the Modern XMPP project is just about growing to the point where it will make sense to potentially split some of the recommendations into different "profiles", so you would have a "social" profile of XMPP which Movim sits squarely in.
I'm excited that the XMPP-ActivityPub gateway will enable Movim joining the Fediverse ecosystem (Mastodon, etc.).: https://www.goffi.org/b/activitypub-gateway-and-pubsub-e2ee-...
Finally, regarding server support, Movim has always been pushing at the edge of XMPP, which is great. It certainly led to improvements in Prosody (the server implementation I work on) since you tried it in 2015, so it may well be worth another try. I don't personally use it myself (yet?), but probably someone from the Movim community could give advice.
Let us know if something is missing or not clear in there. I would probably add to that that Jabber/XMPP has several producion-grade free-software server implementations (ejabberd/prosody/tigase, maybe metronome?) whereas matrix has only one (dendrite/conduit are still experimental although they made great progress). Likewise, Matrix only has one reference client implementing all features. In both cases, the reference implementation is bloated and not compatible with low-end/second-hand hardware which is very popular in the Jabber/XMPP ecosystem.
I expect the situation to keep steadily improving on both sides, or to quote our FAQ:
> As you can see, both protocols have their strengths and weaknesses, but they still operate on similar principles. In theory, it would have been possible (and easier) to build the matrix protocol on top of XMPP to avoid fragmenting the ecosystem. Why this was not done is a good question, but the fact is we now have two protocols/ecosystems with similar goals, and we should try to dismantle our egos and work for interoperability, for the benefit of end-users.
However, if your goal is censorship-resilience (not privacy) against state actors, then i would strongly recommend to use Matrix instead of Jabber/XMPP because decentralized rooms are tailored to that threat model.