Hacker News new | past | comments | ask | show | jobs | submit login
The State of Mobile XMPP in 2016 (gultsch.de)
114 points by e12e on June 4, 2016 | hide | past | favorite | 96 comments



Related: https://news.ycombinator.com/item?id=2069810

To this day, XMPP is a bandwidth-hungry, unreliable mess of a protocol. Despite the enthusiasts having an XEP they can flash for every objection, the sad fact is servers and clients support varied subsets of XMPP, and it's a rare day when everyone involved supports all the features everyone wants to use.

The author seems to think that XMPP is qualified to compete with WhatsApp. While WhatsApp recently abandoned several platforms, for many many years they had even S40 (dumbphone) support. I tried to find XMPP/Jabber clients for S40 phones for YEARS, and every single one I found would immediately crash with OOM errors.

It's easy to blow off complaints like mine, because everyone on hackernews has a Samsung Universe S2000 or an iPhone 128 Plus, but these are real concerns that real people have in the real world. Wholly aside from network effects, even nontechnical users said "why do I need a smartphone to send text messages?" and "because XML" is not going to convince them.

XMPP is just a bad protocol, a holdover from an era where gleefully wrapping everything in XML was the new hotness. I hope we're moving past Global XML Obsession, and I hope I don't have to hear XMPP evangelism once we get past.


People are always bashing XMPP around but truth to be told, my experience with the Android client Conversations is pretty damn good.

I use the Android client with a personal XMPP server based on Prosody and I frequently use it to communicate with a friend who is also running his own XMPP server and the experience is very good. We never lost a message, we can share pictures just like in WhatsApp, we can send any type of file and the battery usage is unnoticeable.

It seems to me that the people who bash XMPP are people who never actually used it and they are just echoing myths from the last decade.


It seems to me that the people who bash XMPP are people who never actually used it and they are just echoing myths from the last decade.

That's my take as well. At this point "XMPP sucks on mobile" seems to be just an outdated meme that keeps replicating itself, but has little actual relevance.


Agreed, I used the Xabber client on Android for years to keep in touch with our entire remote team (20ish people) using a basically out of the box ejabberd server. Never noticed poor battery life or heavy bandwidth usage and the communication was rock solid. Switching back and forth between desktop clients and mobile worked as expected with no weird surprises. All around a great experience, and this was 2011 ish through 2014.


>It seems to me that the people who bash XMPP are people who never actually used it and they are just echoing myths from the last decade.

In the interest of productive discourse, I'm not going to react to the suggestion that I'm an ignoramus who just parrots ancient usenet posts. I'll merely mention it, because I want you to understand that this sort of response does not provide for a discussion of the technical merits of a communications protocol.

Yes, XMPP advocates are continually providing anecdata about how wonderful things have been lately. My problem is that I've been running XMPP/Jabber servers for over a decade, at several different institutions with wildly varying deployment needs... and not once has it ever been a good experience. The failure modes vary, it's true. Sometimes it has been a matter of sheer bandwidth consumption, such as communications over satellite uplink. Sometimes the problem has been interoperability across a federated network. Sometimes the problem has been with specific clients, both commercial and FOSS. But there have always been problems. There are other protocols and solutions that have been far less painful to run, but this is not a discussion about $protocol, it's a discussion about XMPP.

Honestly, I'd rather see XMPP win. The best-case deployment scenario for it is miles above the best-case for most other protocols. But every time someone brings up limitations, the drumbeat starts: "we're working on an XEP for that, implementation coming soon" "you're just rehashing complaints from five years ago" "this wouldn't be a problem if you'd stop using $server_one and switch to $server_two" "that client doesn't work with $server_two, change the client" ad infinitum.


> Related: [comment from 1977 days ago]

Yes, people have been bashing XMPP forever. http://stpeter.im/journal/1384.html

The XMPP protocol is quite qualified to compete with WhatsApp, considering they are using XMPP (with some custom non-standard compression).

XMPP is a fine protocol. Just because a bunch of people has been chanting "XMPP is a just a bad protocol" over and over does not make it true.


The irony (yes, actual irony, not coincidence for once) of someone saying "XMPP sucks, WhatsApp has their shit together" is both tragic and hilarious, and completely summarises the majority of "Forget XMPP its dead" arguments.

I also don't really get the fucking obsession with 'xml sucks'. Like most things, it has its uses, and abuses. The fucking hoops people jump through to make something like JSON work even halfway as well in particular scenarios are a joke in and of themselves.


Your claim that XMPP is a bandwidth-hungry, but in my experience, if XMPP based systems drain battery and consume a lot of bandwidth, then it's because of a poor implementation and design decisions, and not because of the protocol.


But your average user doesn't care about the distinction. If their XMPP-branded client is battery hungry, they're not going to look for another client. They're going to think xmpp is battery hungry and move on. That's where the problem is.


But XMPP is a standard protocol... not a client or library. Should we all abandon HTTP because IE6 sucked? Thats the logical equivalent to the argument.


There are two key differences :

- There was no real alternative to the web. - More importantly, ie6 worked for the end-user. It only sucked for the developers.


Yes. Everything should use HTTPS now.


You're not giving people enough credit. They were able to identify that MSIE as a browser was terrible, and switch to Firefox/Chrome/etc.


And yet MSIE still ruled the earth as a major pain in the foot in 2010, with a whooping 40% marketshare[0] (All versions of ie). It's only when chrome started doing very aggressive advertising that people started to switch.

MSIE worked for most people. The devs suffered how bad it was, but the people didn't see that because most of the web was designed for it. That's the kind of power you get when you are lead in marketshare. We see that nowadays with websites that only work in chrome (though it's less of a problem, chrome is a lot more open to standards, and the engine is open source).

Concerning branding, I still see a lot of people that think the internet is that "e" icon on their desktop. Other people think chrome is the only gateway to the internet. It's the same situation as when IE6 was the lead. People don't know about alternatives, or don't care. Either way, if their "internet app" sucks, it's generally that internet sucks.

[0] Using https://www.w3counter.com/trends as a source, don't know how accurate it is but it does match my memory of how it all happened.


> And yet MSIE still ruled the earth as a major pain in the foot in 2010, with a whooping 40% marketshare

That was largely related to large install bases in corporate/government/educational institutions where legacy requirements (e.g. we built/bought this IE-optimised internal mission-critical web app, and it shits its pants in other browsers).

> It's only when chrome started doing very aggressive advertising that people started to switch.

In 2010 Statcounter and W3 counter both give MSIE ~50% and Firefox ~30%. There was huge shift away from MSIE long before Chrome existed, and longer still before they started using shitty tactics to 'encourage' people to change from other perfectly functioning modern browsers.


> I tried to find XMPP/Jabber clients for S40 phones for YEARS, and every single one I found would immediately crash with OOM errors.

> It's easy to blow off complaints like mine, because everyone on hackernews has a Samsung Universe S2000 or an iPhone 128 Plus, but these are real concerns that real people have in the real world.

I am using Conversations with my family and friends on a prosody server I put on a kimsufi server. It works like a charm, and we don't have all super awesome android phones (but I have to agree, nobody has an S40. Do they even exist anymore?).

I think your experience is outdated and not correct anymore.


> Do they even exist anymore?

Maybe not S40 exactly but there are still plenty of "dumb" phones.

It was only 3 years ago that smartphones started to outsell dumb phones [0]. In America, there are still ~24 million "dumb" phone shipped each year [1].

They are still around, people do still use them.

[0]: http://techcrunch.com/2014/02/13/smartphones-outsell-dumb-ph...

[1]: http://www.techtimes.com/articles/157114/20160510/u-s-flip-p...


I have a "dumb" phone but I don't expect it to be able to run a XMPP client. Even if it could, it's screen is too small and there are only numeric keys.


And yet you can send SMS with a dumb phone; why wouldn't be able to at least send such simple messages with XMPP or any messaging client ?


> Samsung Universe S2000

Not to be confused with the Honda Galaxy S III


I'm not sure I follow this line of reasoning, there appears to be different, unrelated claims here: 1) xmpp, when encrypted and compressed, is inherently chatty and leads to battery drain on mobile. I don't think this is true.

2) Managed services are easier to use, and can deliver a better user experience than having to learn how to do everything yourself. I don't think anyone disagrees with that.

I don't think it follows that picking a subset of xmpp and building on that makes for a poor chat experience. Apart from "actual" xmpp/jabber services working just fine, Google talk and Facebook chat both worked fine with open xmpp clients.


This is a fascinating response, for a couple of reasons. The primary reason is that I never mentioned power consumption at all. I'm not sure what claim you think I'm making in that regard.

The secondary reason is that I never said anything about easier to use or even better experience -- I talked about the fact that WhatsApp worked at all on j2me devices. And for the record, I only even mentioned WhatsApp because the original article in question brought it up in the very first paragraph.

As for gchat and facebook chat, I'm not sure 'arbitrarily yanked out from under users' is "worked fine." See my other comment for the classes of problems I found with "actual" xmpp/jabber...


XMPP "when encrypted and compressed" seems fairly pointless; it's insecure.

The CRIME attack demonstrated that compress-then-encrypt fails to provide confidentiality if it mixes confidential data with attacker-controlled data.


CRIME allows for the recovery of certain parts of the cipher text, by sending many requests. I don't see an easy way to use it to apply it to xmpp (or imap).

In https, it is possible to enumerate certain headers, or other predictable data - session cookies in particular. How would you leverage the use of compression to attack xmpp?


Not easy, but it can be applied to XMPP: https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-an...


Interesting. Perhaps digest auth should make a comeback with tls.

[and rate-limiting logins, obviously, as well as 2fa etc]


I've used Bombus on my Nokia 6300 without any troubles for quite some time back in the day.

The problem with OOM was actually pretty common for J2ME apps in general, because of how widely the phones differed in their specs, and how little heap they often exposed to J2ME.


do you (or anyone) have a recommendation for an alternative open-standard protocol?


I vote for matrix.org

It is open and federated. Compared to XMPP it is overweight a bit, but at least it has sane mobile and browser clients and keeps all history in sync out of the box.


From the comment, his alternative seems to be WhatsApp. Which is built on XMPP.

So.. no?


For the record, WhatsApp is in no way my recommended replacement. For obvious reasons it's completely inapplicable for intranet or institutional use. I mentioned it only because the original article made the comparison.


Propietary license and held by Facebook. As open as possible lol %)


matrix.org ?


In the same vein, see this comment from the same article a few days ago:

https://news.ycombinator.com/item?id=11826855


I use Xabber on Android and it works great. All the hysteria over how bad XMPP is on mobile is over-stated in my experience. Battery life is barely affected by Xabber, compared to the main drains, like Gmail, Facebook, etc. And it pretty much "just works". I think anybody avoiding XMPP because they heard "it doesn't work on mobile" out to give it a try for themselves.


Just a reminder, since this blog did not mention it at all, Matrix is great, is NOT an XML hellhole, and has their own implementation of Axolotl for private messaging: https://matrix.org/git/olm/

And Vector is pretty great too. I had the pleasant experience this weekend of making a new chat room to persistently share photos with relatives this weekend using it. And the Android client is really solid as well.


XMPP is great, NOT a JSON hellhole, and has its own implementation of Axolotl for private messaging: https://conversations.im/omemo/

And Conversations is pretty great too. etc...


Honestly, there isn't a big XMPP v. Matrix thing (or at least I wish there wasn't). A good example is on the Olm side of things, where the OMEMO guys are investigating whether there's value in using Olm as their double ratchet implementation: https://github.com/anurodhp/Monal/issues/9#issuecomment-2080... etc.


Then why, every time XMPP is mentioned, do droves of people praising Matrix and bashing XMPP show up out of nowhere?


I guess an overabundance of enthusiasm from the wider Matrix community, i guess. Speaking on behalf of the Matrix core team, we genuinely wish the XMPP community the best - for as long as Matrix & XMPP end up interoperating nicely, we're working towards the same goal of open communication. Hell, I spend most of my life atm wandering around wearing an XMPP hoodie!

If you like XMPP's philosophy of passing stanzas around, XML and XEPs, then use XMPP. If you like Matrix's philosophy of eventual-consistent synchronising conversation history, JSON and a monolithic spec, then use Matrix. Different tools for different jobs.

It's like SMTP and NNTP. You can use both of them to have conversations. They look kinda similar. You can build bridges between them. But they are totally different architectures and philosophies however and there's room in the world for both :)


Just to be pedantic, there is no such thing as Axolotl. Olm is a new protocol, different from Signal Protocol, that uses the double ratchet internally for part of its function. However, they've made other design decisions that are different from Signal Protocol and may have received less study or scrutiny at this point.

We renamed the Axolotl Protocol and the Axolotl Ratchet because of the confusion between the two (https://whispersystems.org/blog/signal-inside-and-out/), particularly when people just used the word "Axolotl."

Often when people intentionally continue to use the word "Axolotl" now, it's because they're trying to benefit from that confusion. Olm, however, has been clear about being a different protocol.


Just to echo (again), Olm is indeed an independent C/C++ implementation of the double ratchet, and we've been avoiding the overloaded term 'axolotl'. Olm has recently added a group ratchet on top called Megolm which diverges significantly from the Signal protocol, as it's optimised for Matrix's specific use cases of (optionally) syncing and decrypting existing history onto new devices, which obviously comes at the expense of PFS.

In terms of study & scrutiny: Olm and Megolm is still alpha, we're even not using it in earnest in Matrix yet. Things are moving forward fast though, and we're getting a security audit booked in which should hopefully significantly improve our study & scrutiny quotient!

(moxie: did you see my mail? any interest in grabbing a beer next week?)


Any news on how the e2e support is progressing? The FAQ [0] says "End-to-end encryption is coming shortly to clients for both 1:1 and group chats to protect user data stored on servers, using the Olm cryptographic ratchet implementation. As of October 2015 this is blocked on implementing the necessary key distribution and fingerprint management." and I can't see much floating around on Github.

I tried asking in the group chat as well but nobody seemed to know.

[0]: https://matrix.org/docs/guides/faq.html#how-secure-is-this


E2E is our main focus at the moment - sorry for missing the question; we must have missed it. There's nothing on github as the E2E stuff is all hosted on https://matrix.org/git/olm. The FAQ is old - we have finished the 1:1 ratchet and group ratchet and almost all the key distribution stuff. Currently wiring it into all the SDKs and checking it works and then getting it audited. We should be ready to yell about it in N weeks where 2<N<5.


Matrix will eat XMPPs lunch.

Conversations is ok, but Vector is already better because they can focus on usability instead of implementing an inane amount of protocol specs.

Also the bridges to IRC and slack are very helpful.

Oh and running your own matrix server is much easier as it only needs to expose the https port.


I think both have a place in the world (as another comment pointed out, similar to NNTP vs SMTP). Does it really need to be an "us vs them" eat each other's lunch kind of a deal to you?

I use both. Conversations works well out-of-the-box on Android. I use Vector on my desktop, Matrix Console Android, and Vector Android, but none of them work very smoothly. I'm hopeful they will improve as time goes on as I tend to use XMPP more since I have more personal contacts that I can communicate with via that protocol, but I also like and use Matrix.

You don't seem to be aware, but there was an XMPP<->IRC bridge long before Matrix existed. It was about as satisfying as the Matrix version, though that's still improving.

I'm running my own matrix server (synapse), and my own XMPP server (ejabberd), and honestly ejabberd was easier to get off the ground. Again, I'm hopeful that synapse will improve with time, but I really think there's room for both to exist since they do have slightly different use cases.


What are the main not-working-smoothly problems you're seeing with Vector Web/Android out of interest? Matrix Console is very much a raw dev-focused app on top of the SDKs, but at this point in its life Vector should be relatively polished...

ejabberd obviously is much more mature than synapse, but i'd be interested to know where synapse had problems getting off the ground - it's been a few years since I've run ejabberd, but it wasn't particularly fun at the time, and I'd hope that synapse can do better! :)


Of course. I think competition is good and my words were not meant as us vs. them although in hindsight I see that they sound like it.


> Does it really need to be an "us vs them" eat each other's lunch kind of a deal to you?

The present state of messaging affairs is that 99.9% of the market is proprietary spy apps that lock users in to one platform to try to force their acquaintances onto said platform for monetization purposes.

That is an undesirable state to be in for anyone advocating for open and private communications.

So you are either splitting efforts between the two, or saying damn one for the others benefit. I would gladly accept an XMPP implementation that could outpace Matrix / Vector's current performance and accept it wholeheartedly - there just isn't one, and as long as Matrix is at the forefront of usable federated open secure extensible private messaging thats who I'm putting my eggs behind, to the degree where I would say "damn XMPP" only insofar as free software developer hours are precious and wasting them are two different implementations of the same thing (much like Tox vs Ring for secret messaging) wastes a ton of effort that could be better spent making one of the two excellent rather than having two working solutions nobody uses.


> as long as Matrix is at the forefront of usable federated open secure extensible private messaging

You say this as if the truth of this statement was obvious to everyone.

> free software developer hours are precious and wasting them are two different implementations of the same thing (much like Tox vs Ring for secret messaging) wastes a ton of effort that could be better spent making one of the two excellent rather than having two working solutions nobody uses.

That's precisely the reason I work on ejabberd/XMPP rather than just throwing everything away and starting from scratch.


To be fair, XMPP and Matrix are very different beasts (even if you can use them both for chat). From the Matrix perspective, it's great that Conversations exists and shows that XMPP works well on mobile. It makes it even more important to have a good XMPP<->Matrix bridge if anyone reading this feels like helping progress one :)


I looked at Matrix before but it was easier to just roll with a custom MQTT server. Obviously this isn't a solution if you need true federation but I'd argue most don't.


Yup, if you don't need federation, message history, e2e crypto, etc then there's little point in Matrix (or XMPP). +1 for using the right tool for the job :)


How does SIP compare to Matrix? Are they even the same kind of thing?


The similarities are that you can use them both to set up federated voip calls and instant messages. SIP is still the standard way for doing interoperable VoIP on the net.

The differences are huge: * SIP is geared up for initiating sessions (hence the name), whilst Matrix is for synchronising data. SIP is heavily modelled after the requirements of the old PSTN phone network. * It's quite an old and fragmented protocol and interop can be a pain, especially between IETF and 3GPP style variants * It has many competing messaging systems layered on it (SIMPLE, MSRP, etc). You have to try very hard to extract a modern chat experience out of them - eg synchronised history, let alone end to end crypto. * Matrix is HTTP; SIP is its own dedicated UDP-or-TCP transport.


I remember SIP as being very HTTP-like.

Looking at https://tools.ietf.org/html/rfc3261#section-4 this seems to be accurate.

> SIP is based on an HTTP-like request/response transaction model.

The protocol wire format is basically identical to HTTP with verbs, headers, status codes etc. Different set of verb etc however.


Superficially it's HTTP-like, but just enough to give you a false sense of familiarity. (For context, we spent ~10 years writing commercial SIP stuff before ditching it all in favour of Matrix).

You can just about reuse the request/response header & mime parsing stuff (most of which is as much SMTP as HTTP), but the actual stack is completely different - supporting transports on unreliable transports like UDP via three-way handshakes (INVITE -> 200 OK -> ACK), both client->server and server->transactions, different kinds of transactions, registration methods, multiple responses, and all manner of voodoo when it gets to handling all the various types of routing headers. There are two entirely separate abstractions of the stack (ignoring the parsing layer) - the transaction layer (handling those INVITE->200->ACK things that look a bit like HTTP requests but aren't), and then the dialog engine on top that actually the lifecycle of a session (e.g. a phone call).

Random anecdote: a few years a large European telco launched a chat/comms service based on RCS (a GSMA set of standards built on SIP, IMS, MSRP etc). We sniffed the wire to see what happened if you sent the three letters "Hi!" from one client to another. Suffice it to say that it involved 85 round trips and and 54 kilobytes of data (all of which was plaintext, comically) - and this ignored the initial SIP registration. In order to send that message it set up about 3 different sessions (one to send the message as SIP MESSAGE, another to do it again by MSRP (including all the MSRP handshakes) in order to include a typing notification, another to receive the read receipt, etc).

This is why the world needs standards like XMPP and Matrix as a more internetty and less telcoy alternative ;)


Thanks. Matrix seem to to be the way to go, then, at least for text chat. What about audio and video?


Matrix does voip too (Console and Vector implement it using WebRTC as the transport) but it's not as mature as SIP. It's fine for casual use but you wouldn't want to run a telco off it yet :) That said, it's roughly 20x easier to develop on than SIP ;)


So... in practical terms, what's the simplest way for me to get an account on an XMPP server that supports all these modern XEPs? I could maintain my own XMPP server, but I'd really rather not. Life is short, etc. Is there a reasonably-trustworthy company that I can just pay to use their XMPP server? I gather FastMail used to support this, but no longer does.


As of now I recommend everybody to use Prosody stable as XMPP server running on Debian stable. Enable the Prosody modules that provide the XEPs mentioned in Daniel's blog post and/or in XEP-0375: XMPP Compliance Suites 2016[1]. You can either run it at home, which means you have the full stack incl. hardware under your control, or rent a cheap vServer for this, which eventually makes the initial setup easier, as you don't have to deal with dynamic IP addresses. Maintaining a Prosody stable installation on Debian stable means usually nero zero effort. Make sure to have the "security" apt sources and eventually Debian's unattended-upgrade[2] enabled. That's it.

1: https://xmpp.org/extensions/xep-0375.html 2: https://wiki.debian.org/UnattendedUpgrades


have a look at https://account.conversations.im I'm - the author of the essay and developer of Conversations - are running this server with one of the ejabberd developers. That server is really up-to-date and has everything you need to run Conversations. (every XEP mentioned in my essay)

If you want alternatives there is jabber.at, which has also proven to be very well maintained in the past.

And there is jabber.de (but they don't have MAM (yet))


This looks like a nice service, and the price seems very reasonable. Hope it works out well for you!


DuckDuckGo runs a free XMPP server - https://duck.co/blog/post/4/xmpp-services-at-duckduckgo


As someone who has been using OTR/DuckDuckGo as my primary chat server since early 2014, I would recommend against it.

When it goes down, it goes down for multiple days, even a week. Prolonged outages have happened twice or thrice in the last two years, with no helpful messages from the staff. Heck, they didn't even bother announcing the outage before I posted on their community forums.

Their server stopped pushing offline messages to clients a long time ago. People complained, it still doesn't work on my end.

They said they would look into creating a status page, but we still can't tell during an outage if they know about it or not.

The bottom line is that maintaining their XMPP server is simply not a priority for them.

You should look into other providers that use better servers, and are also interested in maintaining their node.

EDIT: I'm basically asking you people to recommend a better XMPP node, somewhere you've personally had a good experience over a long period of time.


I can confirm that sadly - this exactly mirrors my own experiences with DDG XMPP. Sometimes for entire weeks I have been what looked like the only person reporting (or caring) that the XMPP servers are down (mind you that this was years ago, I can't comment on the current state of things), sometimes followed with reactions like "Oh, right... We've restarted the server, see if it works for you." at which point I gave up and moved to a self-hosted ejabberd ever since.

While nowadays most of my contacts are on private XMPP servers, I remember few having some reasonably solid experiences with https://jabber.at/ (can be also found at https://xmpp.zone/ for a better sounding domain name, which I guess matters to people who hate the now obsolete "Jabber" term). Can't from my personal experience vouch for a "good for a long period of time", but if someone is looking for at least a well established server, this should be as good start as any. Also, the news page shows they're quite serious about server updates and transparent, which is a big thumb up in my eyes.

Edit: typos


jabber.at is pretty good in my experience


jabberpl.org has good xep support and has a solid service.


Nice, I think XMPP is more relevant than ever, in an era of messaging apps that are incompatible with each others. I hope businesses come to their senses and provide a layer of interop with a standard such as XMPP. It's a win-win for everybody.


Can anyone point to a comprehensive set of good XMPP clients for different platforms? It looks like Conversations is pretty solid for Android. What is there for Linux desktop? Terminal? I know about Pidgin and related ilk - where can I find which XEPs it supports?


gajim is the best graphical client for the Linux desktop. mcabber and profanity are both excellent terminal clients (I use mcabber). GNOME Empathy is also a decent client if you use the GNOME desktop.



Please don't recommend Pidgin; Pidgin is the IE6 of the chat world… it's terrible, it holds back the rest of the world, and it just won't die (although I know this was in response to the question; just sayin')


I know, right? They've been working on their v3 release for centuries now, but it looks like it's another few centuries away. It's a shame, because it's a really good client. I just wish development was faster.


So what desktop client (Win/Linux) do you recommend instead? (I use pidgin, but mostly because that's what I've always used, it has quite a few weaknesses)


You could try http://swift.im/


I wasn't making any recommendation, just directly addressing parent's question of where to find XEPs supported by "Pidgin and related ilk"


Given MiTM, etc attacks, why does this particular statement not sit well with me?

"Any discussion on end-to-end encryption in XMPP should begin with a reminder that in a federated system end-to-end encryption is not always necessary. When you trust your provider encrypting the transport layer is sufficient."


If you trust the CA system (eg https, imaps) and your provider follows the spec and forces ssl, there isn't any particular mitm danger.

Like if you use mail internally in a domain, eg Gmail, outlook.com etc - there's no obvious mitm attack surface. Users logs into Gmail over https or imaps, emails user2@gmail either via https or smtps - and user2 logs in the same way (similar for self-hatred [lol, there were a few autocorrect errors, leaving this one in - appropriate for "self-hosted"] email).

As far as I know xmpp federation is "point2point", and the current standard demands ssl. So user1@jabber1.tld talking to user2@jabber2.tld will have the communication protected by the CA system and TLS from client1 via server1 to server2 down to client2.

It is a system of many devices, each of which might be compromised, but traditional mitm isn't the biggest danger in this case.


Key here is "not always". If two users trust the intermediate chain of servers that have access to their messages, then transport layer security is indeed sufficient; that already safeguards against unauthorised links in the chain (the man in the middle).

On the other hand, if absolute confidentiality is a concern, end-to-end encryption is required. XMPP does not rule out either approach.

End-to-end encryption matters of course, but it is a lot more relevant when one single mega-corporation is in control of every server messages pass through (e.g., WhatsApp). But if, say, you and I decide to run our own XMPP-servers and communicate thus, it may be sufficient to ascertain that a secure channel exists between our servers and between our clients and their servers.


The last time I tried a mobile xmpp client it had a very ugly, painful user interface and needed to send me notifications when people where coming online or offline (which happens all the time with unreliable mobile internet).

That's the only reason I don't use it. If there's a good client I happily use it.


What app did you use? Conversations, ChatSecure and Xabber on Android and all of them are really good.


A naive question, can you do picture/images inside xmpp?

I hope irc can support inline images especially for web clients.


Last I used xmpp to any degree, embedded multimedia worked fine across clients.

IRC can't really do multimedia in a sane/safe way over http or otherwise. But you can of course link (insert a http link) and the client can try do be as smart as it wants about it. I would think allowing the embedding of data:urls and just displaying them in-line in a Web client would be asking for security issues. I'm sure there are some IRC Web clients that supports that ;)


Yes. In fact anything.


http://getkaiwa.com/ some good info on xmpp on that page.

most xmpp client still show inline-image via http-url, I failed to find any xmpp client that can natively insert an inline image just like what other popular IM messengers do these days.


Then I don't see any reason why XMPP can not be used widely nowadays. Just installed xabber on my Android and am going to set up a team server.


Related Communication freedom [1]

[1] https://communicationfreedom.wordpress.com/jabberxmpp/


While this tells you which XEPs you should enable for a modern XMPP experience it doesn't tell you how to do that. In my experience the documentation especially for ejabberd is lacking and it's often not trivial to find out. Also this begs the obvious question: Why aren't the options to have a modern XMPP server enabled by default?


> the documentation especially for ejabberd is lacking

If you happen to remember specific things you were missing on https://docs.ejabberd.im/ we'd be happy to hear about them:

https://github.com/processone/docs.ejabberd.im/issues/new


I found it pretty easy to get prosody setup with all the XEPs Conversations wants. I dunno about ejabberd...


why is XMPP shite? just look:

  <message from="juliet@example.com" to="romeo@example.net" xml:lang="en">
    <body>Art thou not Romeo, and a Montague?</body>
  </message>
69 chars just for the from/to. every. message. (more or less)

There is already a concept of session, why send the full ID? not just a short ID.

each byte costs energy, in this case most of the energy is spend on boilerplate, stuff that can be inferred much more cheaply.

Fortunately its not wrapped in HTTP, as that'd add even more boilerplate each transaction.


https://tools.ietf.org/html/rfc6121#section-5.2.1

because the message can be sent to different devices (resources) the user is connected with. This is not accidental complexity like you make it out to be. It is needed and wanted.

Or are you advocating a binary protocol? Personally I really like the messages exchanged with xmpp: they are easy to understand and easy to craft. I think the success of http too, lies a little bit in the fact that it is human readable.


But they are not human readable. They are only readable by humans because can be converted to text with a text reader. For a protocol to be good, it needs decent debug tools.

Yes I am advocating a binary protocol. If you want to have decent battery life, then you need to be efficient. This is the tradeoff you need to make. for something like text, I really don't understand peoples fear of binary protocols.

As an aside clients have memory nowadays, there is no reason to send the full ID for the sender in each message (unless of course you are doing encyption, but even then, once you've exchanged keys its moot) a client needs to keep track of buddies that are online, so this data can be cached, and a local ID used instead.


The 'from' is not sent for c2s connections

The xml:lang element is rarely if every used.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: