Facebook Messenger protocol in Pidgin
github.com
github.com
(At least person-to-person messaging works well - I have not attempted group chats or video or stuff)
XML inside XML inside XML inside XML inside
Edit: PSYC outlines XMPP problems pretty well. I wish PSYC was more prevalent.
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.
XMPP bad. Binary XMPP worse. Etc.
If anything, this should be a lesson for consumers and to learn how to not give that much power to a couple of organizations.
Why.
What matters is how useful users think it is. Whether developers think the code is beautiful is less important for adoption.
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.
Wow, I can easily imagine much better interfaces. In fact I don't even have to imagine - Mercurial is way nicer.
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.
More familiar because it was essentially subversions interface made suitable for a dvcs.
Worse for lacking (or requiring plugins for) features like the index, commit amending, rebasing, lightweight branches, etc.
MSNP (older versions):
FLN user@example.com
:nick!user@example.com PART #channel
<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
<thread>act2scene2chat1</thread>
<gone xmlns='http://jabber.org/protocol/chatstates'/>
</message>
NFY PUT 268
Routing: 1.0
To: 1:mypassport@hotmail.com
From: 1:en-cn@hotmail.com
Reliability: 1.0
Notification: 1.0
NotifNum: 0
Uri: /user
NotifType: Partial
Content-Type: application/user+xml
Content-Length: 50
<user><s n="IM">
<Status>FLN</Status>
</s></user>
A user going offline would be:
<presence from="juliet@capulet.com/balcony" type="unavailable"/>
And their XML parsing were quite limited.
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.
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.
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.
* 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.
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)
Every company wants their walled garden though... though there's moats stocked with alligators and piranha around them..
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).
Tox is a nice experiment, but has efficiency issues and makes it hard to share messages when offline.
Unfortunately, it seems that it's in an infinite, self-proclaimed "not really ready yet" phase, and not used widely.
I found it after trying to write a reasonable XMPP client (previously commented on here: https://news.ycombinator.com/item?id=9772968 ) and haven't looked back since.
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.
(Also, thanks for the vote of confidence :D)
Not implying it isn't true but ... Says who ?
Not my post, but an overview of some of its issues: http://vasters.com/clemensv/2014/06/02/MQTT+An+Implementers+...
tl;dr: Protocol design and implementation isn't easy.
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?
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 library would have to keep up with all the changes or clients would quickly stop working. So is the manpower there to do this?
But it is nice to see the world coming to yet another cycle. sigh.
[edited to address comment]
You wanted to, but you don't, because...?
I doubt that was unintentional.
"The purple-facebook project simply back-ports the purple3 plugin to purple2 [..]"
So i guess you won't see the actual protocol implementation in this repo but only the necessary patches.
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.)