It's a shame that Facebook removed support for XMPP in the first place. I guess it's part of their strategy to make the world more "open" and connected.
XMPP wasn't a great protocol though... I'm not aware of a better option though. I know that something over WebRTC may not be much better, but may be the best chance of seeing something more open in the next decade again.
Every company wants their walled garden though... though there's moats stocked with alligators and piranha around them..
Do you think it's strictly that they want walled gardens? I have a feeling more large companies would support open protocols if they provided the features they needed with the efficiency to provide those services cost (and battery) effectively. It seems all the many open protocols (XMPP, Web and CalDav, etc.) are simply not efficient or feature rich enough for companies that are in a constant features escalation war with competitors.
I imagine it's that, but amplified by NIH syndrome. Something like "oh yeah we could do it with XMPP, but it's all complicated and stuff and if we just built our own protocol we'd be able to do everything we'd ever want exactly how we want it! It'll be the future!"
I've fallen victim to something similar myself many times. "Oh yeah, I could do <this> with <tool x>, but it's ugly and not how <tool x> is meant to be used! I'll just design and implement <tool y> myself to do exactly <this> and it'll be the future!" It's the temptation to make something customized for yourself and it's hard to resist. Particularly when the existing solution has some flaws, which makes the relative cost/effort of rolling your own solution seem lower (even when it inevitably turns out to still be quite high).
If they want open protocols they can propose it and work in standards bodies (IETF or other) but that would limit their flexibility. And walled garden is good to keep users.
I use Matrix on the desktop, my ipad, and my android phone -- the much vaunted multi-device cross-platform success story that seems to be the one nice thing people have to say about facebook chat, you can have that with FOSS too! -- and just for an out-of-left-field bonus, it replaces my need for an IRC bouncer because they have a bridge for that. Finding Matrix was probably my best FOSS discovery of all 2015.
The people at matrix.org are attempting to create such a better option. I offer no particular opinion as to whether they've yet succeeded since I've not got around to digging into it properly.
You can log into an @gmail.com Hangouts account through XMPP. The instructions on https://wiki.bitlbee.org/HowtoGtalk worked for my account which is also accessed by Hangouts on Android L.
(At least person-to-person messaging works well - I have not attempted group chats or video or stuff)
Indeed. Google voice texts, group chats, and video stuff do not work. I get incoming audio chat requests on pidgin for google voice calls, but they don't work.
I used it on my desktop. You can call XMPP horrible, it still worked without any problem. Much better than having a browser tab dedicated for Facebook.
With respect, you're only one person out of billions. Individually, I used it as well. And (as far as I heard), XMPP sucks for developers to implement and support, not necessarily for users themselves.
The technical part doesn't really matter. The problematic part is that Facebook (and Google) took a page from old Microsoft and applied "Embrace, Extend, Extinguish" to the one alternative we had for an open and federated messaging platform.
If anything, this should be a lesson for consumers and to learn how to not give that much power to a couple of organizations.
Because lots of things flourish despite not being the most beautifully designed piece of technology. Git survives despite its widely-derided UI, email proliferates despite spam, and Linux is dominant despite having a less beautiful kernel than BSD.
What matters is how useful users think it is. Whether developers think the code is beautiful is less important for adoption.
Yeah, these things are mostly true (apart from git, which I think has the best possible interface for a VCS), but I don't understand why did you suddenly switch from a question about a decision by a particular company to a question of wide adoption of technology by a community.
And your second paragraph misses the point: it's not about one of the factors, it's about balance between them. In this particular case, the amount of users who prefer XMPP doesn't seem to be big enough to counter the pain of supporting it.
Shame mercurial didn't catch on. I started learning DVCS' with mercurial, back when they were still a new concept, and git wasn't very good (this is an understatement, git was horrible back then).
What I really liked was the very friendly and usable command line interface, out of the box shortcuts (which I now emulate in my .gitconfig), clear help pages. It was a bit slower than git for enormous projects but it worked wonderfully for me.
Git didn't have any of those things either except "lightweight branches". It wasn't until 2006 or so that git grew a reasonable commit command. Before then, people relied on tools such as cogito in order to get work done.
Yeah as much as I appreciate the concept of XMPP, I find it unlikely that the average person cares about that sort of stuff. Of course, I'm limited to the people I know, so maaaaybe I'm mistaken, but if you think about the average Facebook user (Joe Smith, has 600 friends he barely knows, likes to quote songs in his statuses), what are the odds they would NOT want a dedicated app or tab?
"The tech folks", "text based therefore simple", suggesting anybody ever used XML and simple in one sentence, implying http would be better off binary, … how can such a small comment pack such a misleading punch.
Impressive, in a way.
The point isn't text → simple (semantics), it's text > binary (syntax).
Complexity is mostly a property of semantics, text vs binary is about the syntax used to convey those semantics. For the same semantics, text is easier to debug than binary. That's all.
I agree with the browser tab, this is annoying. I've tried alternatives for Mac: Current and Goofy (basically wrappers around the conversation page), but they're both quite unstable.
So far the best option was to keep another tab open, just switch from messenger.com to see only conversations without all the FB feed
There are multiple pain points with the way the XMPP protocol is "organized":
* It's designed to accommodate as many use-cases as possible with a variety of actors chiming in with their own requirements
* a tiny core that doesn't do a lot, and a gazillion extensions
* when you want to implement a software in XMPP world, you don't have a clear view on what extensions you need to implement and what extensions are nice-to-have (other than word of mouth)
* corollary: extensions can move fast, some are new, some die, but the perception doesn't change as fast, so old habits remain for a long time (cue "PSYC said XMPP sucks") and softwares don't evolve to accommodate later improvements
* second corollary: since the bulk of what makes XMPP useful is defined in extensions, as a user you don't know which client or which server you should pick
* by design there's no reference implementation, which means you don't really know where to start
* it's XML, and XML doesn't exactly play well with recent languages (you won't write XML itself so you'll use what your language gives you, but it doesn't always map very well with XML)
To summarize, XMPP can do everything, provided that you know your way. If you don't know anything you will most likely be disappointed by your first experience, as a user.
Does xmpp handle the case where you've read a message on another client and you want all clients to see it as read? Seems like possibly an argument for centralized storage
At this point I don't think there is a huge benefit in starting another protocol. There are problems with XMPP, but IMHO they're more in how it is organized than in the protocol itself. XMPP has surveyed a huge chunk of the space, it has seen where things are difficult and proposed a solution for that. It is in use by many entities already, with many different use cases (one of the later extensions (https://xmpp.org/extensions/xep-0365.html) is to use XMPP over radios with atrocious conditions: latency in minutes, throughput as low as 75 bits/s. Also, for some reason XMPP has seen some success in military), it has all the benefits of being an approved IETF protocol (one of which being that it will still be here in 10 years, whatever happens). Sure, it's old stinky XML, but it's not like it's a brand new technology where little documentation exists. There are libraries in most languages already.
What we really lack is a bit more guidance: the XSF (XMPP Standards Foundation) is only interested in making sure the standard is properly specified, that demands are met appropriately. It's a huge huge job, but for a community of developer it's not enough. There has already been talks to update the suite of extensions that are considered almost-mandatory in a modern IM software; it would also be really awesome to have a reference implementation for each usage (ie one server, one IM client, one VoIP client, one microblogging client, ...) because, like many others, I find tangible code we all agree on to be of very high value.
I fear that other protocols will be created, they will all (or at least a good part) die, and in the end we'll have XMPP, standing there in the waves of protocols, chugging along quietly. People will be mocking it not because it doesn't work, but because they don't understand it (and that will be a fault with XMPP, not with people, because it will remain extremely complex)
As someone who implemented stuff for XMPP many years ago: it's a super complex, XML infested protocol that if implemented correctly can only result in a bad user experience. It gets a little bit better if you support only a subset of it (eg: you take away the federation aspect of it) and target a single server and assume you control all clients.
But it's really very tricky to get a good user experience with it and the protocol is just not at all fun to work with. If it would not be the darling of the open source community it would not have gone far.
It's not really complex on its own, just that a lot of developers used ad-hoc regexp-based parsers and made some assumptions (like hardcoded namespace names, say, some software really expected "x:" prefix and didn't care for "xmlns"es) when processing it. I absolutely admit (and don't like) a bad framing scheme — it would've been much better not as XML stream, but as TLVs of structured data — but that's manageable with streaming parsers, and otherwise I don't see why XMPP's core is super complex.
When I think of something super complex that's SOAP (where you can literally write the same call in multiple different and server-incompatible ways), and XMPP is nowhere close.
As much as I don't like XML (and I do), it allowed XMPP a great amount of extensibility that's just not possible with simpler/non-extensible formats like JSON (although possible with YAML or ASN.1, and doable with implementing some format on top of JSON). Most chat protocols just don't allow to implement arbitrary extensions. E.g. you want your chat service to have a concepts of, say, hats¹ for participants — with IRC the best you can do is to run a HatsBot or make a custom DCC protocol. With XMPP you just decide on a schema and put your stuff with a custom namespace (then if it's something useful for everybody, file a XEP). So, while XML may be not best format, I think it absolutely it made sense.
___
¹) I just wanted something silly. So, I thought of Team Fortress-style hats.
So even ignoring XMPP's intrinsic complexity, it's based on XML. XML is impossible to use securely out of the box without severely tweaking the parser. XML entity bombs, gazillion of different charsets you might encounter, stack exhaustion due to nesting of namespaces or elements in places you don't expect etc.
The main reason many of these issues are not better known is because it did not get popular enough that people bothered exploiting it.
> As much as I don't like XML (and I do), it allowed XMPP a great amount of extensibility that's just not possible with simpler/non-extensible formats like JSON
You do not need schemas and namespaces to be extensible.
> The main reason many of these issues are not better known
Nope, they all well-known and were exploited (I saw all of this stuff, in vivo). Except for charsets — XMPP had limited charsets right from the beginning, so it's not applicable.
XML absolutely has a lot of issues, I'm with you on this. I've just pointed it made some sense.
> You do not need schemas and namespaces to be extensible.
Schemas - no. Namespaces - I'm sure they're necessary. Even if the namespaces are just prefixes of JSON dictionary keys or custom ASN.1 OID, they're still namespaces (and XML namespaces aren't really different here, just a URL-to-short-prefix maps and colon-separted prefixes). Otherwise it will end up very messy.
I mean, nobody wants a logic like "that's a message from Foobar 1.x client, so 'x-typing' property here means typing state, not use of monospaced typewriter-style font like Bazbaz 2.x software does." And that's inevitable without namespaces.
That's what I read in a couple of blog posts in articles by people who implemented it. I can't bring the up right now, but after one minute in google, I found this conversation to be quite interesting: https://news.ycombinator.com/item?id=2069810
I think older MSNP and IRC are the best of all the IM protocols I've seen, and I've written clients for both. OSCAR (ICQ/AIM) is a binary format that doesn't look too hard to parse; I'd say it's still better than working with XML.
And yes, XMPP is extensible, so you might see such notifications with more content (e.g. the user can set an offline message), but the beauty is that not every client need implement support for that, which is handy if you're writing a thin client like a bot, or doing machine-to-machine communication. But every XMPP client will interpret the core meaning exactly the same: the user has gone offline.
Message size is important, but for low-bandwidth instant messaging is XML really bothersome? I mean it's not like you're writing your own XML parser or serialiser, is it?
The sad truth about XMPP is that a lot of developers actually did this (at least in early days). Maybe because a lot of readily available libraries weren't really compatible with XML streams and XMPP's idea of framing.
And isn't designed as a federated chat protocol, so not really comparable. You could use it as a transport layer to run a chat protocol on top, but it doesn't replace XMPP on it's own.
What do you mean by "federated"? I've heard XMPP described as that but never really seen it explained.
The impression I've gotten is that somehow users on one XMPP network could chat with users on another? So if Google and Facebook still both fully embraced it, a GChat user could message a FB user without anything extra?
That's exactly it, except each of them is not an XMPP network but just a single domain (there's only a single authority, so it doesn't make a lot of sense to talk of network). XMPP works exactly like SMTP in this regard: you can send a mail from a@gmail.com to b@fastmail.com just like you can (could, at least) send an XMPP message from c@duckgo.com to d@facebook.com
Basically all public XMPP/Jabber servers implement this, and it is fairly easy to set up (multiple of my contacts run their private servers). Spam has never been an issue for me.
Google used to implement this, DDG still implements this, most small->medium XMPP servers still implement this. For a while, Facebook was the odd one out for not supporting it.
Spam was less of a problem than e.g. spam on AIM. There's the fact that it's not any harder to sign up for AIM than a XMPP network, it's not popular enough and the audience too tech-savvy for spammers to bother, and if a specific host was a bad apple it's easy to BL them.
This part is actually the one that is in the core of XMPP, so it doesn't work in theory, it just works everywhere (as long as administrators have allowed federation, of course).
What I'm worried about: The protocol is proprietary, not a public API and all official clients can be updated by Facebook almost instantly. This means they can make arbitrary changes to the protocol at any time without bothering the users of official clients very much.
This library would have to keep up with all the changes or clients would quickly stop working. So is the manpower there to do this?
Well there used to be this thing called AOL instant messenger. Then people cloned the protocol. So AOL would just start causing purposeful buffer overflows that would take them to specific parts in their code but mess up the people trying to imitate it. But they figured it out, and now they teach students in class how to overcome it. The other illegal thing they taught us was decrypting a DVD.
which is OK, as long as there is a community to support the effort. I remember when Pidgin (or another IM client) had to keep up with not one, but three protocols: MSN, Yahoo and AOL. And that was done before the age of Github and pull requests.
Awesome. Now we will be able to have a XMPP/Jabber transport that works with Facebook. Great for sort of keeping in touch with the relatives without the horror of actual Facebook.
If I get it right, MQTT is just a PubSub protocol, i.e. it essentially carries the messages, but doesn't care about their contents.
Is there a standard on how chat layer (the content of published messages) is implemented? (I haven't looked into source code, but guess it's not just a plain text, but it has some structure to it.)
