15 ms·
Modern XMPP
- alberth 5y agoObligatory XKCD comic: https://imgs.xkcd.com/comics/standards.png https://imgs.xkcd.com/comics/standards.png
- kenniskrag 5y agoI 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."
- ShrigmaMale 5y agoXMPP is a rather old protocol at twenty-two years. If anything it is other standards that are newer and causing the "standard proliferation".
- jpxw 5y agoXMPP plus plus, perhaps. Or XMPPPP.
- mst 5y agoBut XMPP is federated, not point to point?
- 0xdeadb00f 5y agoAnyone else feel like the fact XMPP needs this kind of signals that it's pretty... shit? (Excuse my language).
- MattJ100 5y agoDo you have constructive suggestions on introducing cohesive design into open ecosystems without a guiding documentation project? (disclaimer: I started this one)
- 0xdeadb00f 5y agoFirstly, to answer your question: No. 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.
- franga2000 5y agoThis 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).
- southerntofu 5y agoXMPP 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.
- cat199 5y agoif so then same is true for say, TCP/IP, HTTP and HTML
- 0xdeadb00f 5y agoFair point. I think I've maybe changed my tune on this a little bit since writing that comment.
- icedchai 5y agoXMPP is basically an abomination of a protocol. It's too complicated. Other people can explain it better than I: https://news.ycombinator.com/item?id=2069810 https://news.ycombinator.com/item?id=2069810
- pmlnr 5y agoSeriously? Go check out Matrix or ActivityStreams, XMPP is actually much simpler.
- icedchai 5y agoThe 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/ https://xmpp.org/extensions/
- mst 5y agoOne of the key points of the article we're discussing is to recommend a small curated set of XEPs. Just look at this relative lack of stuff: https://docs.modernxmpp.org/client/protocol/ https://docs.modernxmpp.org/client/protocol/
- MattJ100 5y agoThat'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. 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 https://xmpp.org/about/compliance-suites.html
- southerntofu 5y ago
- FerretFred 5y agoMy 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.
- p4bl0 5y agoMQTT 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.
- Jtsummers 5y agohttps://mqtt.org/software/ https://mqtt.org/software/ There are a bunch of implementations there.
- kitd 5y agoAnd once you have your MQTT server running, you can install NodeRed alongside it for a complete "low-code" IoT solution. https://nodered.org/ https://nodered.org/ https://cookbook.nodered.org/mqtt/connect-to-broker https://cookbook.nodered.org/mqtt/connect-to-broker
- PaulHoule 5y agoI use https://en.wikipedia.org/wiki/RabbitMQ 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.
- MattJ100 5y agoYeah, 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.
- PaulHoule 5y agoMy 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.
- eyelidlessness 5y agoI had a hard time finding it too. It’d be nice to have next/prev in the main body for discoverability.
- AshamedCaptain 5y agoI 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...
- sobakistodor 5y agoModern 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.
- AshamedCaptain 5y agoBad 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.
- MattJ100 5y agoYou'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.
- deleted 5y ago[deleted]
- sobakistodor 5y agoWe 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()); } Simple. Bytes. Dont care about any "protocols".
- eitland 5y agoA 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 :-)
- Jtsummers 5y ago> Simple. Bytes. Dont care about any "protocols". 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.
- selfhoster11 5y agoGood 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.
- southerntofu 5y agoMoreover, 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.
- ajconway 5y ago
- dsr_ 5y agoI 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. In general, resolve incompatibilities.
- ocdtrekkie 5y agoIndeed. 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.
- MattJ100 5y agoAgreed! As in my sibling comment just now, I've updated this section to say basically that.
- MattJ100 5y agoYou'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").
- notorandit 5y agoUnluckily, as soon as xmpp was not supported by Google any more, all interests around it failed. R.I.P.
- zaik 5y agoXMPP 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/ https://xmpp.org/getting-started/
- MattJ100 5y agoHi, 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. 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 https://xmpp.org/category/newsletter.html ) and by email ( https://xmpp.org/newsletter.html https://xmpp.org/newsletter.html ).
- mst 5y agoPlus 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.
- ape4 5y agoI 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.)
- MattJ100 5y agoNames and mascots are hard :) 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/ https://snikket.org/ - a client+server package of XMPP software for personal messaging (disclaimer: I started this project). - https://joinjabber.org/ https://joinjabber.org/ - a community of folk working to support new users joining the network with documentation and infrastructure.
- solarkraft 5y agoModernization/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. I’m happy about each one.
- southerntofu 5y agoYou'll be happy to learn that Snikket project just started a cooperation with Simply Secure to do UX studies on the Snikket family of clients: https://snikket.org/blog/simply-secure-collaboration/ https://snikket.org/blog/simply-secure-collaboration/ 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!
- emptysongglass 5y agoIt'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.
- MattJ100 5y agoYes! That's what people do. I don't know about Traefik specifically, but we have docs for many other reverse proxies: https://github.com/snikket-im/snikket-server/blob/master/docs/advanced/reverse_proxy.md https://github.com/snikket-im/snikket-server/blob/master/doc... If you feel like trying it with Traefik and submitting some example config for the docs, that would be very welcome :)
- aidenn0 5y agoIt 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.
- bertman 5y agore. web client: converse.js (https://conversejs.org/ https://conversejs.org/) is pretty cool!
- MattJ100 5y agoXMPP 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.
- aidenn0 5y agoConverse.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.
- floatingatoll 5y agoThe 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?
- mst 5y agoDo 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.
- floatingatoll 5y agoI 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.
- mst 5y agoI 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)
- hkt 5y agoI'd be really interested to hear the authors' take(s) on movim - is this under the umbrella of "modern" and are they involved? https://movim.eu/ 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.
- MattJ100 5y agoAuthor 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. 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-QGqK 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.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- hammyhavoc 5y agoWhat's the advantage over Matrix in 2021?
- southerntofu 5y agoThe 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 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.
- hammyhavoc 5y agoThanks for this! Really appreciate your time, going to have a dig into it. Fantastic response. :- ) Stay well!
- southerntofu 5y agoYou too!