32 ms·

XMPP, a comeback story

380 points by upofadown 5y ago

kseistrup 5y ago
I've been using XMPP since its inception as Jabber, and it's my preferred way of communicating. Prosody and Ejabberd are two good, lightweight XMPP servers that will let you synchronize messages across devices.
PaulHoule 5y ago
It's little known that XMPP is a big hit with military and police organizations. (e.g. the Baltimore police department has XMPP-based chat and feeds the messages into Lotus Notes) Vendors in that market heavily use extension mechanisms. For instance commanders of infantry units might fill out forms every day about what kind of contacts they had with the enemy and get them sent to a central location.
- dragontamer 5y ago
  > Vendors in that market heavily use extension mechanisms. For instance commanders of infantry units might fill out forms every day about what kind of contacts they had with the enemy and get them sent to a central location. How does XMPP help with this over a HTTP form?
  - PaulHoule 5y ago
    On the battlefield you don't have good internet so the cycle of GET the HTML form and POST the fields is not reliable. XMPP Forms are deeply asynchronous. I'd assume that the "blank form" already exists on the soldier's laptop and the message gets stored-and-forwarded until it gets to the destination.
    - dragontamer 5y ago
      Isn't this just an issue of saving the POST until you successfully deliver it? HTML is an async protocol. We pretend it is sync through a mountain of cookies. But innately, HTTP and HTML are all async. Without PHPSESSID, there really isn't an official way to correlate GETs with POSTs. XMPP is synchronous. It's a chat interface. I'd assume it's be harder to do async comms with it. IIRC, it's a stream of XML that coincides with the servers state.
  - larma 5y ago
    HTTP would be fine as well, you could GET an XML with the form to fill and POST the XML with form data. But: - HTTP forms might be less flexible when it is about structured data. - HTML needs a complex renderer software Remember that this stuff might need to work on low resource devices and over low bandwidth connections.
    - mattbk1 5y ago
      Sounds similar to WinLink forms on ham radio, used to make sending structured data easier: https://www.winlink.org/WinlinkExpressForms https://www.winlink.org/WinlinkExpressForms
    - dragontamer 5y ago
      I happen to have been an avid user of the Lynx web browser. A long time ago yes but I still remember it. HTML forms are pretty flexible and could be designed in a low CPU environment.
- sennight 5y ago
  heh, back in my day that role was filled by IRC over a low bandwidth SIPRNet link - with each room being a different command or area of operation. You can see evidence of this from Manning's tactical data dump.
obiwan14 5y ago
Memories! I'm sure I have at least one Jabber account somewhere. Don't even recall where to find it. Easier to just creat a new one and see if things have really improved from way back.
IceWreck 5y ago
> meaning people from different servers can talk to each other while no central authority can have influence on another server unlike Matrix Elaborate please. Matrix doesn't have a central authority server which can influence other servers.
- jagermo 5y ago
  Also, the bridge system in matrix is solid. Most people do not want to ban all other messengers, but they want all their communication in one place. Matrix-based messengers like Element or Bleeper seem like the way to go. And if people then start using matrix based chatrooms, all the better. But I doubt you can reach critical mass with a system that is not open to other chat systems, even if those are closed.
  - akho 5y ago
    XMPP has bridges.
    - jagermo 5y ago
      Yes, but it does not sell them well. Look at Beeper (beeper.com) or Element One (element.io), they actively market the fact, that you can use whatsapp or signal or telegram with them. Using matrix is nearly an afterthought, it's more like using pidgin or trillian back in the day. And I think it's clever because it lets me switch away from whatsapp etc, but I don't have to bring all my friends over at once. And, once I am on board, I can start to look into the features provided by matrix. People don't switch to a protocol, I think, they want to leave a service or provider. And yes, you are still part of whatever walled garden you choose to use, but whatsapp can run on an old phone and never touch my new phone, never getting the data on that device.
      - zamadatix 5y ago
        Beeper seemed cool but trying to find out more it just put me on a waitlist. Element One is extremely limited in bridges. Element Home seems better in that regard but still doesn't have a major one for me Google Chat/Hangouts. Neither seems clear on if I can use my personal domain while they host and manage the homeserver+bridges. Element One mentions subdomains and beeper mentions self hosting but neither seem to comment on personal domains which seem a natural fit to use for a federated service.
SaltySolomon 5y ago
The whole issue with XMPP is that yes, in theory you could do e2ee accross multiple servers and devices but only if all the servers support the right extensions and the clients support them properly.
- Andrew_nenakhov 5y ago
  The whole issue with XMPP is that users are brainwashed to demand e2ee even without fully understanding what it means and what unavoidable downsides in UX true e2ee brings. Most users would have the same level of security as with e2ee by simply running their own server. E2ee mostly helps against service owner you don't trust, so just be your own service owner and have nicely syncing history and server side search.
  - pkulak 5y ago
    I totally agree, though I run my own Matrix server and still find value in e2ee because I don't really trust AWS (or maybe my ability to secure AWS). I suppose I could run the service on a machine in my house, but that's not going to be good for uptime, the NAT screws things up, etc. Plus, even that could be hacked if I fuck something up.
    - Andrew_nenakhov 5y ago
      If you run a legal operation, you don't have to worry about hosting company admins logging into your database. That can be done only on police inquiry.
      - pkulak 5y ago
        Eh. I'm still not storing passwords, keys, documents, photos, et all, plain text in some RDS database.
        Andrew_nenakhov 5y ago
        On photos/documents, you are in a tiniest of minorities: ~99% of all smartphone users store photos in unencrypted cloud services like Google Photos and use Google Docs and MS Office 365. (But but chats are surely the holy cow and must be encrypted - strictly demand those same users, paradoxically) And no modern server stores passwords in plain text, and keys are not stored on servers at all.
tlackemann 5y ago
I remember using XMPP for a site I built that connected tenants and landlords, a reverse MLS of sorts. Back then, I choose XMPP because I had heard this is what Facebook was using at the time for their new messenger and it provided services like online status, typing status, and live messaging out-of-the-box. I don't recall it being terribly difficult to implement and it was awesome to see it working for the first time! This was almost 10-years ago now, it's incredible to see this technology still moving forward.
- k__ 5y ago
  Interesting. I had the impression the general opinion about XMPP is that it's resented as the SOAP of messaging.
  - dwaite 5y ago
    The primary similarity between the two is the use of XML. Maybe the general opinion is that XML sucks?
    - olau 5y ago
      It's just not a great protocol. Many years back I was working on a desktop client for XMPP. The first problem I encountered was that XMPP does not actually send individual XML documents each time it sends a message. Instead it starts with a tag that is not closed until you actually turn off your client and close the connection. So you couldn't use a simple XML document parser for those relatively simple messages as it would read the start tag and never finish, but had to do some kind of streaming-based thing.
  - jasonwatkinspdx 5y ago
    This was my experience. It did end up doing what we needed and being able to use off the shelf libraries/servers at the time was convenient, but holy heck is the protocol chatty and annoying to debug at the trace level.
jconley 5y ago
We tried our hardest back in the early 2000's to make this stick. I cofounded a startup building servers, clients, and SDK's. Maybe the world is finally ready for it now. The issue we ran into was customers/consumers just didn't care about federated systems. And various implementations had all sorts of quirks making interoperability between domains and clients difficult, at best. There are just SO MANY THINGS you have to do to make good messenger software that lining up all the pieces with open standards proved impossible in the ~8 years I was working on it. Again, maybe it's better now, but I'm skeptical, probably jaded. :)
- mfer 5y ago
  It's not about the protocol. Most people don't care about XMPP, RSS, or any of those things. They have things they want done, like chatting with a friend. They want a solution that delights them in doing that. What delights people has generally changed (like more people care about others not listening in these days). Whose the user and what's their experience? This is where XMPP always failed me. The clients had a poor experience. If someone wants that to change now... focus on a great experience for the people you want to be users.
  - jconley 5y ago
    Yes, this is generally the issue with open networks. Very, very hard to get complex and disparate client/servers to play nicely with each other. Perhaps with the capital that is being put behind web3 someone will figure this out.
    - beepbooptheory 5y ago
      Yeah but then we gotta pay for em!
    - acdha 5y ago
      I’m expecting “web3” to go the other way: all of those speculators are looking to get their money back at a healthy return and that tends to favor building up barriers to switching. I’d expect claims that being open makes it too hard to prevent spam or slows innovation by adding features which, ooops, they totally slack on making interoperable.
anarchogeek 5y ago
What an earnest and well-meaning BS post.... I mean seriously, XMPP is fundamentally flawed, and it's not coming back. What's more, we have matrix which is the protocol re-written from the ground up with the knowledge of XMPP and better design. Matrix IS XMPP 2.0.
- datenarsch 5y ago
  > XMPP is fundamentally flawed how is it fundamentally flawed, can you elaborate?
  - forty 5y ago
    I really wanted to like XMPP back in the days, but honestly I always ended up feeling that the protocol is just bad. This idea of opening an XML document at the beginning of the stream, then only allowing a subset of XML and all the mess with the xmlns, all that bringing really nothing to the table except complexity. I think ideally in a good protocol, the server should not have to parse the content for the messages that are not targetted to itself (only the metadata useful for routing). the XML mess makes it impossible to do that since you have to validate the full document. At the time I think this page was a good summary of the issues https://about.psyc.eu/XMPP https://about.psyc.eu/XMPP No idea if this is still relevant though.
    - icedchai 5y ago
      I've built an XMPP client for an internal application. My impression was the protocol was overly complex, starting with the lower level problems you describe ("streaming XML.") It's been years since I've looked at. Maybe things are better now.
    - Yoric 5y ago
      Well, I guess it kinda makes sense? Beats having to reinvent a tokenization format from scratch? Of course, smaller messages (à la Matrix) probbably make more sense.
      - 5y ago
rapnie 5y ago
I watched the FOSDEM 2019 video [0] showcasing how XMPP can be used as a "generic message bus" for a broad range of application types using PubSub XEP and some other XEP's. Yet the vast majority of information, like 99.9%, deals with IM chat stuff and additional, related features (like Movim supports blogs, video via WebRTC, etc). Makes me wonder if it is indeed applicable for this generic use (like arbitrary business apps that would benefit from a well-specified message-based networking stack), or one should better stay away from that. [0] https://youtube.com/watch?v=JEDRSNGDxUQ https://youtube.com/watch?v=JEDRSNGDxUQ
- zaik 5y ago
  You can send arbitrary XML to some other node on the network. Just built upon the extensions you need and ignore the rest.
- kitd 5y ago
  Tbh, unless your business app needed things like presence, file transfer, and federation, you're probably better sticking with something like mqtt, nats or rabbitmq.
  - rakoo 5y ago
    I'd like to ask the question the other way around: is it better/simpler/easier to use MQTT, nats or RabbitMQ instead of XMPP when you don't need those ?
    - mike_d 5y ago
      You are basically asking: is it easier to have two servers just talk to each other, or ping each other back and forth on Slack.
      - Gigachad 5y ago
        The slack option certainly sounds a lot simpler. You don't have to worry about what happens if one server misses a message, what happens if you want to add more server, what happens if you want encryption, what happens if the server gets temporarily backlogged, etc. I wouldn't use slack exactly but a slack like service like XMPP/Matrix/Kafka? sound way simpler than having servers message each other directly.
brunes 5y ago
What would truely make XMPP stick and be a killer app, would be if enterprise interoperability could be shown between apps like Microsoft Teams, Slack, and Discord. The amount of friction that enterprise consumers like myself have to deal with because none of these things interoperate is immense. Making them interoperate at a basic level via XMPP does not seem like it would be overly challenging.
- possiblelion 5y ago
  Have you looked at Mio? https://youtu.be/0mAXRUgJtgg https://youtu.be/0mAXRUgJtgg Basically does what you're talking about
- loremipsium 5y ago
  the technical challenge, or lack thereof, is not the reason why it's not done I suppose.
  - Gigachad 5y ago
    It has been done. Chat apps once did work together and you had multi client apps that would connect to everything. Then they slowly died off and became discontinued because people don't actually care that much about having multiple chat apps. Thanks to modern push notification services, you can receive messages from all IM services without having to have those apps actually running.
- smoldesu 5y ago
  You're looking for Matrix. XMPP wants nothing to do with 'enterprise' apps that rely on potentially backdoored encryption standards. The people who care enough to enable OMEMO on their chats aren't going to do so with the intention of undermining their communique for a slightly better level of compatibility.
- VWWHFSfQ 5y ago
  but what if they don't want to interoperate with each other
- deleted 5y ago
olah_1 5y ago
Snikket is absolutely the future of XMPP imo. They have the right ideas: https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/
tschellenbach 5y ago
I think XMPP is too complex for most use cases, I'd be surprised if it doesn't continue to decline in popularity.
- zaik 5y ago
  What makes you think it is currently declining?
  - tschellenbach 5y ago
    My company, Stream, powers chat for thousands of apps. XMPP used to come up in the past as a way for people to build in-house chat apps. The last year or 2 it's gone from being rare to non-existent. If people do build in-house it's usually from scratch with Go or Rust.
FpUser 5y ago
I do not think any protocol can claim true privacy. If they want they'll find you.
- Andrex 5y ago
  Even in that defeatist context, it's still worthwhile to try.
  - FpUser 5y ago
    Did I tell you not to try? Mine was just a warning of - do what you do but be aware type.
zmix 5y ago
I wonder what ever happened to SIP presence and text messaging (and related specs)?
- Arathorn 5y ago
  The barely even got as far as group chat, for which they used MSRP. Then they turned into RCS :/
spankalee 5y ago
Instead of all the web3 nonsense, which still requires implementations working with interoperable protocols like this, that energy should be put into advocacy for standard protocols, or building apps that use them.
- esjeon 5y ago
  Yup, I second this. The whole web3 idea is completely pointless if the ecosystem is designed to be heavily centralized. Everyone is and will be fighting for a pie in the “platform” market. We need decentralization in the application side first, and that is only possible with standard protocols.
wpietri 5y ago
I reverse-engineered the comms for my cheap Ecovacs robot vacuum and was surprised to discover that, like some angsty teen, it spent all day hanging out in an XMPP chatroom waiting for somebody to talk to it: https://github.com/wpietri/sucks/blob/master/developing.md https://github.com/wpietri/sucks/blob/master/developing.md
- stefan_ 5y ago
  XMPP is a part of TR069 as some sort of rendevzous point for device and controller: https://www.qacafe.com/resources/2015-03-26-using-xmpp-for-tr-069-connection-requests/ https://www.qacafe.com/resources/2015-03-26-using-xmpp-for-t...
rekoros 5y ago
boo
skunkworker 5y ago
I remember back in 2008 reading on how Tivo started using XMPP instead of polling to check for new recordings. https://www.socialmediatoday.com/content/xmpp-aka-jabber-future-cloud-services https://www.socialmediatoday.com/content/xmpp-aka-jabber-fut...
- ajcp 5y ago
  That article is just one poorly aged sentence after another. Love it. Two of my favorites: "Therefore cloud services aren't real-time, won't scale, and often can't clear the firewall" "While Twitter is not a cloud service, nor the largest demand service on the internet (with a paltry 350,000ish users, which pales in comparison to a MySpace or Yahoo!)"
etxm 5y ago
At my first startup we used XMPP (wildfire?) to do a lot of our ops work. All of our pet servers had a background process sitting in a chat room. We did deploys, restarted process, got alerts, and a whole bunch of other stuff all via XMPP. It was much cooler than our product that never made any money :)
riccardomc 5y ago
We used XMPP to orchestrate servers and runtimes at one of my previous employers. I might be romanticizing it in my memory a bit, but I remember it fondly. We would run ejabberd servers and could easily know which nodes were up and talk/send commands to them.
deleted 5y ago
[deleted]
artursapek 5y ago
XMPP's biggest flaw is its use of XML. If it modernized its serialization protocol, it might have a much brighter future.
- larma 5y ago
  Which modern serialized protocol do you envision here? That comes with good extensibility by design? Just the fact that XML is old, doesn't mean it's bad. It might be a bit unnecessary verbose or hard to parse for constrained devices, but luckily there is EXI to solve these issues when efficiency is key.
  - artursapek 5y ago
    JSON? Or optionally something like protocol buffers?
    - edhelas 5y ago
      Ah yes, JSON :3 XMPP has an extension for that https://xmpp.org/extensions/xep-0295.html https://xmpp.org/extensions/xep-0295.html
      - artursapek 5y ago
        lol
- Flowdalic 5y ago
  Using XML is one of XMPP its biggest strengths. XML is well designed, good documented and has a rich set of supporting libraries. XML documents can be composed of other XML documents in a sound fashion, which is a major feature for an extensible protocol as XMPP is, and XML documents compress well, making them suitable in low-bandwidth conditions (see [XEP-0365](https://xmpp.org/extensions/xep-0365.html https://xmpp.org/extensions/xep-0365.html)). I also never experienced a considerable battery drain when autark devices are using XMPP compared to a binary protocol.
eecc 5y ago
Oh I used it. Built a POC involving devices advertising their positions and coordinating their group responses to commands via a bot chatroom and json messages. Worked a charm.
kixiQu 5y ago
> Can a 20 year old overlooked technology make a comeback as a completely decentralized, free, and scalable technology for the growing masses of people who value freedom and privacy? Betteridge's law strikes again!
- pugworthy 5y ago
  To speed up those (like me) who had to look it up... https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
oofbey 5y ago
I worked on a large XMPP system for a while and realized it's actually not a very good protocol, for one reason: presence. "Presence" is the feature that shows a little indicator next to each one of your contacts indicating whether they're online or away. The problem with presence is that it generates a LOT of traffic. It's N^2 with the average number of contacts each user has - every time a user changes presence, you have to send a message to every one of their contacts to update them about the presence. This happens whether they're paying attention to your client or not. So on a large system, the big majority of the traffic is just presence messages flying back and forth saying who is at their keyboard and who isn't. This is really wasteful in general. Worse, it's not a super important feature for a lot of people, so it's definitely not worth the effort. And ever since mobile computing became ubiquitous, it's not even clear what this is supposed to represent. So, I say let XMPP die. It was a fine idea for its time. But the protocol has no place in the modern world.
- detaro 5y ago
  That's afaik a problem with pretty much any system that supports presence, even though it can be somewhat optimized potentially (where I don't know how many options exist in XMPP, but I don't think would be fundamentally impossible to add)?
  - fshbbdssbbgdd 5y ago
    It seems like it would be much more efficient for the presence to be stored somewhere where clients can fetch it if needed.
    - secondaryacct 5y ago
      if needed=each time presence change. So you d have an enormous graph with one node in the center refreshing presence for everyone. And end up worse.
    - detaro 5y ago
      Fetch has the downside that with the usual idea of presence you want to know immediately if presence changes, so you'd be polling constantly. What could make some sense is caching server-side and allowing the subscription to be quickly enabled/disabled, so that a client could save traffic while it's not on screen etc. When it returns, it asks for the last message for each contact to be delivered from cache and the subscription to be resumed (in exchange for having to wait for the data to come in, and until then not showing the correct information).
deleted 5y ago
[deleted]
eluusive 5y ago
Until spam becomes a problem on XMPP... And then we're back to the same problems as email. I'm working with some people to build out Stamp which is federated in a similar way to XMPP but attaches small cryptopayments to keep undue about of spam off the network. Take a look: https://www.stampchat.io/whitepaper.pdf https://www.stampchat.io/whitepaper.pdf
z3t4 5y ago
I looked at xmpp 15 years ago and found it overly complicated, inefficient and bloated. Maybe it doesn't stand out as so bad compared to todays tech though.
unglaublich 5y ago
Google Talk and Facebook chat used to be XMPP compatible. Probably even built on XMPP. Pidgin was my client of choice. Then they cut XMPP off and only allowed Google/Facebook webapps to access chat. That was sad.
bullen 5y ago
I made a better standard for this: https://github.com/tinspin/fuse https://github.com/tinspin/fuse But of course it's suffering from this: https://xkcd.com/927/ https://xkcd.com/927/
progmetaldev 5y ago
I setup jabberd in our org, back around 2008, when our President wanted a secure messaging system and downloaded some trial shareware to do this. I setup Pidgin with (I believe) the OTR plugin so everything was secure. I was surprised by how easy it was to get everything up and running, even with limited knowledge of Windows server administration. I just needed to write a few batch scripts to run on startup. Now we run Google Hangouts and are locked into their ecosystem. I miss open systems, even if I wasn't taking full advantage of them at the time.
tlavoie 5y ago
I've seen a different use case for XMPP that I thought was interesting. Basically, a public-facing site uses it for running customer support chat bots, providing FAQs and the like. Under the hood, initiating a chat is basically launching an in-browser client over WebSockets, and spawning a "chat room" with a dynamically-created bot. Maybe this is common, I don't know, but seems to work well.

380 points by upofadown 5y ago

I've been using XMPP since its inception as Jabber, and it's my preferred way of communicating. Prosody and Ejabberd are two good, lightweight XMPP servers that will let you synchronize messages across devices.

PaulHoule 5y ago

It's little known that XMPP is a big hit with military and police organizations. (e.g. the Baltimore police department has XMPP-based chat and feeds the messages into Lotus Notes) Vendors in that market heavily use extension mechanisms. For instance commanders of infantry units might fill out forms every day about what kind of contacts they had with the enemy and get them sent to a central location.

dragontamer 5y ago
> Vendors in that market heavily use extension mechanisms. For instance commanders of infantry units might fill out forms every day about what kind of contacts they had with the enemy and get them sent to a central location. How does XMPP help with this over a HTTP form?
- PaulHoule 5y ago
  On the battlefield you don't have good internet so the cycle of GET the HTML form and POST the fields is not reliable. XMPP Forms are deeply asynchronous. I'd assume that the "blank form" already exists on the soldier's laptop and the message gets stored-and-forwarded until it gets to the destination.
  - dragontamer 5y ago
    Isn't this just an issue of saving the POST until you successfully deliver it? HTML is an async protocol. We pretend it is sync through a mountain of cookies. But innately, HTTP and HTML are all async. Without PHPSESSID, there really isn't an official way to correlate GETs with POSTs. XMPP is synchronous. It's a chat interface. I'd assume it's be harder to do async comms with it. IIRC, it's a stream of XML that coincides with the servers state.
- larma 5y ago
  HTTP would be fine as well, you could GET an XML with the form to fill and POST the XML with form data. But: - HTTP forms might be less flexible when it is about structured data. - HTML needs a complex renderer software Remember that this stuff might need to work on low resource devices and over low bandwidth connections.
  - mattbk1 5y ago
    Sounds similar to WinLink forms on ham radio, used to make sending structured data easier: https://www.winlink.org/WinlinkExpressForms https://www.winlink.org/WinlinkExpressForms
  - dragontamer 5y ago
    I happen to have been an avid user of the Lynx web browser. A long time ago yes but I still remember it. HTML forms are pretty flexible and could be designed in a low CPU environment.
sennight 5y ago
heh, back in my day that role was filled by IRC over a low bandwidth SIPRNet link - with each room being a different command or area of operation. You can see evidence of this from Manning's tactical data dump.

obiwan14 5y ago

Memories! I'm sure I have at least one Jabber account somewhere. Don't even recall where to find it. Easier to just creat a new one and see if things have really improved from way back.

IceWreck 5y ago

> meaning people from different servers can talk to each other while no central authority can have influence on another server unlike Matrix Elaborate please. Matrix doesn't have a central authority server which can influence other servers.

jagermo 5y ago
Also, the bridge system in matrix is solid. Most people do not want to ban all other messengers, but they want all their communication in one place. Matrix-based messengers like Element or Bleeper seem like the way to go. And if people then start using matrix based chatrooms, all the better. But I doubt you can reach critical mass with a system that is not open to other chat systems, even if those are closed.
- akho 5y ago
  XMPP has bridges.
  - jagermo 5y ago
    Yes, but it does not sell them well. Look at Beeper (beeper.com) or Element One (element.io), they actively market the fact, that you can use whatsapp or signal or telegram with them. Using matrix is nearly an afterthought, it's more like using pidgin or trillian back in the day. And I think it's clever because it lets me switch away from whatsapp etc, but I don't have to bring all my friends over at once. And, once I am on board, I can start to look into the features provided by matrix. People don't switch to a protocol, I think, they want to leave a service or provider. And yes, you are still part of whatever walled garden you choose to use, but whatsapp can run on an old phone and never touch my new phone, never getting the data on that device.
    - zamadatix 5y ago
      Beeper seemed cool but trying to find out more it just put me on a waitlist. Element One is extremely limited in bridges. Element Home seems better in that regard but still doesn't have a major one for me Google Chat/Hangouts. Neither seems clear on if I can use my personal domain while they host and manage the homeserver+bridges. Element One mentions subdomains and beeper mentions self hosting but neither seem to comment on personal domains which seem a natural fit to use for a federated service.

SaltySolomon 5y ago

The whole issue with XMPP is that yes, in theory you could do e2ee accross multiple servers and devices but only if all the servers support the right extensions and the clients support them properly.

Andrew_nenakhov 5y ago
The whole issue with XMPP is that users are brainwashed to demand e2ee even without fully understanding what it means and what unavoidable downsides in UX true e2ee brings. Most users would have the same level of security as with e2ee by simply running their own server. E2ee mostly helps against service owner you don't trust, so just be your own service owner and have nicely syncing history and server side search.
- pkulak 5y ago
  I totally agree, though I run my own Matrix server and still find value in e2ee because I don't really trust AWS (or maybe my ability to secure AWS). I suppose I could run the service on a machine in my house, but that's not going to be good for uptime, the NAT screws things up, etc. Plus, even that could be hacked if I fuck something up.
  - Andrew_nenakhov 5y ago
    If you run a legal operation, you don't have to worry about hosting company admins logging into your database. That can be done only on police inquiry.
    - pkulak 5y ago
      Eh. I'm still not storing passwords, keys, documents, photos, et all, plain text in some RDS database.
      - Andrew_nenakhov 5y ago
        On photos/documents, you are in a tiniest of minorities: ~99% of all smartphone users store photos in unencrypted cloud services like Google Photos and use Google Docs and MS Office 365. (But but chats are surely the holy cow and must be encrypted - strictly demand those same users, paradoxically) And no modern server stores passwords in plain text, and keys are not stored on servers at all.

tlackemann 5y ago

I remember using XMPP for a site I built that connected tenants and landlords, a reverse MLS of sorts. Back then, I choose XMPP because I had heard this is what Facebook was using at the time for their new messenger and it provided services like online status, typing status, and live messaging out-of-the-box. I don't recall it being terribly difficult to implement and it was awesome to see it working for the first time! This was almost 10-years ago now, it's incredible to see this technology still moving forward.

k__ 5y ago
Interesting. I had the impression the general opinion about XMPP is that it's resented as the SOAP of messaging.
- dwaite 5y ago
  The primary similarity between the two is the use of XML. Maybe the general opinion is that XML sucks?
  - olau 5y ago
    It's just not a great protocol. Many years back I was working on a desktop client for XMPP. The first problem I encountered was that XMPP does not actually send individual XML documents each time it sends a message. Instead it starts with a tag that is not closed until you actually turn off your client and close the connection. So you couldn't use a simple XML document parser for those relatively simple messages as it would read the start tag and never finish, but had to do some kind of streaming-based thing.
- jasonwatkinspdx 5y ago
  This was my experience. It did end up doing what we needed and being able to use off the shelf libraries/servers at the time was convenient, but holy heck is the protocol chatty and annoying to debug at the trace level.

jconley 5y ago

We tried our hardest back in the early 2000's to make this stick. I cofounded a startup building servers, clients, and SDK's. Maybe the world is finally ready for it now. The issue we ran into was customers/consumers just didn't care about federated systems. And various implementations had all sorts of quirks making interoperability between domains and clients difficult, at best. There are just SO MANY THINGS you have to do to make good messenger software that lining up all the pieces with open standards proved impossible in the ~8 years I was working on it. Again, maybe it's better now, but I'm skeptical, probably jaded. :)

mfer 5y ago
It's not about the protocol. Most people don't care about XMPP, RSS, or any of those things. They have things they want done, like chatting with a friend. They want a solution that delights them in doing that. What delights people has generally changed (like more people care about others not listening in these days). Whose the user and what's their experience? This is where XMPP always failed me. The clients had a poor experience. If someone wants that to change now... focus on a great experience for the people you want to be users.
- jconley 5y ago
  Yes, this is generally the issue with open networks. Very, very hard to get complex and disparate client/servers to play nicely with each other. Perhaps with the capital that is being put behind web3 someone will figure this out.
  - beepbooptheory 5y ago
    Yeah but then we gotta pay for em!
  - acdha 5y ago
    I’m expecting “web3” to go the other way: all of those speculators are looking to get their money back at a healthy return and that tends to favor building up barriers to switching. I’d expect claims that being open makes it too hard to prevent spam or slows innovation by adding features which, ooops, they totally slack on making interoperable.

anarchogeek 5y ago

What an earnest and well-meaning BS post.... I mean seriously, XMPP is fundamentally flawed, and it's not coming back. What's more, we have matrix which is the protocol re-written from the ground up with the knowledge of XMPP and better design. Matrix IS XMPP 2.0.

datenarsch 5y ago
> XMPP is fundamentally flawed how is it fundamentally flawed, can you elaborate?
- forty 5y ago
  I really wanted to like XMPP back in the days, but honestly I always ended up feeling that the protocol is just bad. This idea of opening an XML document at the beginning of the stream, then only allowing a subset of XML and all the mess with the xmlns, all that bringing really nothing to the table except complexity. I think ideally in a good protocol, the server should not have to parse the content for the messages that are not targetted to itself (only the metadata useful for routing). the XML mess makes it impossible to do that since you have to validate the full document. At the time I think this page was a good summary of the issues https://about.psyc.eu/XMPP https://about.psyc.eu/XMPP No idea if this is still relevant though.
  - icedchai 5y ago
    I've built an XMPP client for an internal application. My impression was the protocol was overly complex, starting with the lower level problems you describe ("streaming XML.") It's been years since I've looked at. Maybe things are better now.
  - Yoric 5y ago
    Well, I guess it kinda makes sense? Beats having to reinvent a tokenization format from scratch? Of course, smaller messages (à la Matrix) probbably make more sense.
    - 5y ago

rapnie 5y ago

I watched the FOSDEM 2019 video [0] showcasing how XMPP can be used as a "generic message bus" for a broad range of application types using PubSub XEP and some other XEP's. Yet the vast majority of information, like 99.9%, deals with IM chat stuff and additional, related features (like Movim supports blogs, video via WebRTC, etc). Makes me wonder if it is indeed applicable for this generic use (like arbitrary business apps that would benefit from a well-specified message-based networking stack), or one should better stay away from that. [0] https://youtube.com/watch?v=JEDRSNGDxUQ https://youtube.com/watch?v=JEDRSNGDxUQ

zaik 5y ago
You can send arbitrary XML to some other node on the network. Just built upon the extensions you need and ignore the rest.
kitd 5y ago
Tbh, unless your business app needed things like presence, file transfer, and federation, you're probably better sticking with something like mqtt, nats or rabbitmq.
- rakoo 5y ago
  I'd like to ask the question the other way around: is it better/simpler/easier to use MQTT, nats or RabbitMQ instead of XMPP when you don't need those ?
  - mike_d 5y ago
    You are basically asking: is it easier to have two servers just talk to each other, or ping each other back and forth on Slack.
    - Gigachad 5y ago
      The slack option certainly sounds a lot simpler. You don't have to worry about what happens if one server misses a message, what happens if you want to add more server, what happens if you want encryption, what happens if the server gets temporarily backlogged, etc. I wouldn't use slack exactly but a slack like service like XMPP/Matrix/Kafka? sound way simpler than having servers message each other directly.

brunes 5y ago

What would truely make XMPP stick and be a killer app, would be if enterprise interoperability could be shown between apps like Microsoft Teams, Slack, and Discord. The amount of friction that enterprise consumers like myself have to deal with because none of these things interoperate is immense. Making them interoperate at a basic level via XMPP does not seem like it would be overly challenging.

possiblelion 5y ago
Have you looked at Mio? https://youtu.be/0mAXRUgJtgg https://youtu.be/0mAXRUgJtgg Basically does what you're talking about
loremipsium 5y ago
the technical challenge, or lack thereof, is not the reason why it's not done I suppose.
- Gigachad 5y ago
  It has been done. Chat apps once did work together and you had multi client apps that would connect to everything. Then they slowly died off and became discontinued because people don't actually care that much about having multiple chat apps. Thanks to modern push notification services, you can receive messages from all IM services without having to have those apps actually running.
smoldesu 5y ago
You're looking for Matrix. XMPP wants nothing to do with 'enterprise' apps that rely on potentially backdoored encryption standards. The people who care enough to enable OMEMO on their chats aren't going to do so with the intention of undermining their communique for a slightly better level of compatibility.
VWWHFSfQ 5y ago
but what if they don't want to interoperate with each other
deleted 5y ago

olah_1 5y ago

Snikket is absolutely the future of XMPP imo. They have the right ideas: https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/

tschellenbach 5y ago

I think XMPP is too complex for most use cases, I'd be surprised if it doesn't continue to decline in popularity.

zaik 5y ago
What makes you think it is currently declining?
- tschellenbach 5y ago
  My company, Stream, powers chat for thousands of apps. XMPP used to come up in the past as a way for people to build in-house chat apps. The last year or 2 it's gone from being rare to non-existent. If people do build in-house it's usually from scratch with Go or Rust.

FpUser 5y ago

I do not think any protocol can claim true privacy. If they want they'll find you.

Andrex 5y ago
Even in that defeatist context, it's still worthwhile to try.
- FpUser 5y ago
  Did I tell you not to try? Mine was just a warning of - do what you do but be aware type.

zmix 5y ago

I wonder what ever happened to SIP presence and text messaging (and related specs)?

Arathorn 5y ago
The barely even got as far as group chat, for which they used MSRP. Then they turned into RCS :/

spankalee 5y ago

Instead of all the web3 nonsense, which still requires implementations working with interoperable protocols like this, that energy should be put into advocacy for standard protocols, or building apps that use them.

esjeon 5y ago
Yup, I second this. The whole web3 idea is completely pointless if the ecosystem is designed to be heavily centralized. Everyone is and will be fighting for a pie in the “platform” market. We need decentralization in the application side first, and that is only possible with standard protocols.

wpietri 5y ago

I reverse-engineered the comms for my cheap Ecovacs robot vacuum and was surprised to discover that, like some angsty teen, it spent all day hanging out in an XMPP chatroom waiting for somebody to talk to it: https://github.com/wpietri/sucks/blob/master/developing.md https://github.com/wpietri/sucks/blob/master/developing.md

stefan_ 5y ago
XMPP is a part of TR069 as some sort of rendevzous point for device and controller: https://www.qacafe.com/resources/2015-03-26-using-xmpp-for-tr-069-connection-requests/ https://www.qacafe.com/resources/2015-03-26-using-xmpp-for-t...

rekoros 5y ago

boo

skunkworker 5y ago

I remember back in 2008 reading on how Tivo started using XMPP instead of polling to check for new recordings. https://www.socialmediatoday.com/content/xmpp-aka-jabber-future-cloud-services https://www.socialmediatoday.com/content/xmpp-aka-jabber-fut...

ajcp 5y ago
That article is just one poorly aged sentence after another. Love it. Two of my favorites: "Therefore cloud services aren't real-time, won't scale, and often can't clear the firewall" "While Twitter is not a cloud service, nor the largest demand service on the internet (with a paltry 350,000ish users, which pales in comparison to a MySpace or Yahoo!)"

etxm 5y ago

At my first startup we used XMPP (wildfire?) to do a lot of our ops work. All of our pet servers had a background process sitting in a chat room. We did deploys, restarted process, got alerts, and a whole bunch of other stuff all via XMPP. It was much cooler than our product that never made any money :)

riccardomc 5y ago

We used XMPP to orchestrate servers and runtimes at one of my previous employers. I might be romanticizing it in my memory a bit, but I remember it fondly. We would run ejabberd servers and could easily know which nodes were up and talk/send commands to them.

deleted 5y ago

[deleted]

artursapek 5y ago

XMPP's biggest flaw is its use of XML. If it modernized its serialization protocol, it might have a much brighter future.

larma 5y ago
Which modern serialized protocol do you envision here? That comes with good extensibility by design? Just the fact that XML is old, doesn't mean it's bad. It might be a bit unnecessary verbose or hard to parse for constrained devices, but luckily there is EXI to solve these issues when efficiency is key.
- artursapek 5y ago
  JSON? Or optionally something like protocol buffers?
  - edhelas 5y ago
    Ah yes, JSON :3 XMPP has an extension for that https://xmpp.org/extensions/xep-0295.html https://xmpp.org/extensions/xep-0295.html
    - artursapek 5y ago
      lol
Flowdalic 5y ago
Using XML is one of XMPP its biggest strengths. XML is well designed, good documented and has a rich set of supporting libraries. XML documents can be composed of other XML documents in a sound fashion, which is a major feature for an extensible protocol as XMPP is, and XML documents compress well, making them suitable in low-bandwidth conditions (see [XEP-0365](https://xmpp.org/extensions/xep-0365.html https://xmpp.org/extensions/xep-0365.html)). I also never experienced a considerable battery drain when autark devices are using XMPP compared to a binary protocol.

eecc 5y ago

Oh I used it. Built a POC involving devices advertising their positions and coordinating their group responses to commands via a bot chatroom and json messages. Worked a charm.

kixiQu 5y ago

> Can a 20 year old overlooked technology make a comeback as a completely decentralized, free, and scalable technology for the growing masses of people who value freedom and privacy? Betteridge's law strikes again!

pugworthy 5y ago
To speed up those (like me) who had to look it up... https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...

oofbey 5y ago

I worked on a large XMPP system for a while and realized it's actually not a very good protocol, for one reason: presence. "Presence" is the feature that shows a little indicator next to each one of your contacts indicating whether they're online or away. The problem with presence is that it generates a LOT of traffic. It's N^2 with the average number of contacts each user has - every time a user changes presence, you have to send a message to every one of their contacts to update them about the presence. This happens whether they're paying attention to your client or not. So on a large system, the big majority of the traffic is just presence messages flying back and forth saying who is at their keyboard and who isn't. This is really wasteful in general. Worse, it's not a super important feature for a lot of people, so it's definitely not worth the effort. And ever since mobile computing became ubiquitous, it's not even clear what this is supposed to represent. So, I say let XMPP die. It was a fine idea for its time. But the protocol has no place in the modern world.

detaro 5y ago
That's afaik a problem with pretty much any system that supports presence, even though it can be somewhat optimized potentially (where I don't know how many options exist in XMPP, but I don't think would be fundamentally impossible to add)?
- fshbbdssbbgdd 5y ago
  It seems like it would be much more efficient for the presence to be stored somewhere where clients can fetch it if needed.
  - secondaryacct 5y ago
    if needed=each time presence change. So you d have an enormous graph with one node in the center refreshing presence for everyone. And end up worse.
  - detaro 5y ago
    Fetch has the downside that with the usual idea of presence you want to know immediately if presence changes, so you'd be polling constantly. What could make some sense is caching server-side and allowing the subscription to be quickly enabled/disabled, so that a client could save traffic while it's not on screen etc. When it returns, it asks for the last message for each contact to be delivered from cache and the subscription to be resumed (in exchange for having to wait for the data to come in, and until then not showing the correct information).

deleted 5y ago

[deleted]

eluusive 5y ago

Until spam becomes a problem on XMPP... And then we're back to the same problems as email. I'm working with some people to build out Stamp which is federated in a similar way to XMPP but attaches small cryptopayments to keep undue about of spam off the network. Take a look: https://www.stampchat.io/whitepaper.pdf https://www.stampchat.io/whitepaper.pdf

z3t4 5y ago

I looked at xmpp 15 years ago and found it overly complicated, inefficient and bloated. Maybe it doesn't stand out as so bad compared to todays tech though.

unglaublich 5y ago

Google Talk and Facebook chat used to be XMPP compatible. Probably even built on XMPP. Pidgin was my client of choice. Then they cut XMPP off and only allowed Google/Facebook webapps to access chat. That was sad.

bullen 5y ago

I made a better standard for this: https://github.com/tinspin/fuse https://github.com/tinspin/fuse But of course it's suffering from this: https://xkcd.com/927/ https://xkcd.com/927/

progmetaldev 5y ago

I setup jabberd in our org, back around 2008, when our President wanted a secure messaging system and downloaded some trial shareware to do this. I setup Pidgin with (I believe) the OTR plugin so everything was secure. I was surprised by how easy it was to get everything up and running, even with limited knowledge of Windows server administration. I just needed to write a few batch scripts to run on startup. Now we run Google Hangouts and are locked into their ecosystem. I miss open systems, even if I wasn't taking full advantage of them at the time.

tlavoie 5y ago

I've seen a different use case for XMPP that I thought was interesting. Basically, a public-facing site uses it for running customer support chat bots, providing FAQs and the like. Under the hood, initiating a chat is basically launching an in-browser client over WebSockets, and spawning a "chat room" with a dynamically-created bot. Maybe this is common, I don't know, but seems to work well.