Modern XMPP
docs.modernxmpp.org
docs.modernxmpp.org
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?
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.
There are a bunch of implementations there.
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.
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.
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.
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 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.
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 :)
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.
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 ).
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.
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
serializer.put<uint32_t>(item).put(another).put(this);
if (writer.valid()) {
// no overflows or other problems
socketwriter.write(serializer.data());
}
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.