Pidgin will probably struggle with this because Fb Messenger is quite a moving target. You can currently send audio, video, photos, stickers, and payments. Also it supports audio and video calls. Not to mention messenger platform which enables developers to build just about anything else.
Plus, the dynamics around group chats are tricky. Messenger shows when people are typing and what point everybody has read up until. You can rename group messages, leave them, add people, mute/disable notifications, or mute for a period of time.
Without good compatibility or fallbacks for all of this behavior, Pidgin users are in for a bad time. Most will probably go back in frustration and pin messenger.com in a browser tab.
Except that even with a limited feature set, Pidgin has one advantage: it integrates with a lot of networks. It's the same with IRC: Pidgin's IRC support is mediocre compared to real clients like XChat but I still used it. I'd only have to launch Pidgin to log into multiple IRC networks, MSN, two Google Talk accounts and Facebook. It has a single logging mechanism, single interface, it's not a website, there are no ads and I can install/update it using apt-get.
It would be nice if Pidgin would build in all the features you mentioned, but I'd be perfectly happy if it just connected to my chats and allowed me to send and receive text messages. Typing notifications would be nice-to-have, but this is all I ever use anyway. Not such a bad time for me.
Agreed, connecting to other networks is huge. But the other features might be more important to others. Personally, I would rather use multiple clients than entirely miss the stickers, photos, payments, and group chats that get sent my way.
That said- I'm sure pidgin can go a long way by implementing sane fallbacks for these features.
This really ought to be the other way around. If Facebook wants to be accessed by popular client software, then it should expose its service using standard protocols. So Facebook pulls XMPP and the community reacts by rewarding them with a custom integration? How are we supposed to get ahead here?
I know Pidgin is a pragmatic project, not a political one, but this doesn't sit well.
What's old is new again. Around the time Gaim was created there were AIM/ICQ, MSN, and YIM, each with its proprietary protocol, each lacking good official Linux support. Now, fifteen years later, there's Facebook Messenger, Google Hangouts, iMessage, Skype, WhatsApp, Snapchat, LINE, Telegram, Kik, WeChat, Twitter (which is evolving DMs into a chat service), and many others... each with its proprietary protocol (undocumented except for Telegram and Twitter), few with support for all the mobile and desktop platforms one might want to use them on, none that actively encourage use of clients that can access more than one service (except iMessage on OS X for a limited set).
Given the profusion of services, and the resulting difficulty of managing a separate account on each if you want to maximize your connectivity, I'm surprised there isn't more interest in unified chat clients. Third party Pidgin plugins exist for some of those services, but I've never personally heard anyone mention actually using them, and availability is even more barren on mobile - my barometer might be off, but I feel like everyone has just forgotten about the possibility of interoperability. Then again, maybe it's just a question of the right person writing a new client designed for mobile and modern messaging, and that client taking off...
I think there are multiple reasons why multi-protocol mobile clients haven't taken off:
1. More complicated protocols. iMessage and Skype are many times more complicated than AIM/ICQ, MSN or YIM, with lots of layers of custom encryption and authentication. Reverse engineering of these protocols has never been close to done.
2. Battery usage. Each new account you add is (likely) another connection that you have to keep open. With one connection you can apply optimizations like the server bundling packets, but you can not do that when you need to keep connections to many different services.
Skype is actually not that complicated a protocol - at least on the enterprise side. It is basically just straight SIP messaging, with a few Microsoft-specific extensions.
Do you mean "Skype for Business" aka Lync? Cause that's really totally unrelated to Skype except for questionable branding. Skype used a heavily obfuscated system, with all sorts of anti-reversing technology.
And the protocol flowchart for Lync is complicated as all hell, even with SIP at the core. (More complicated than SIP usually is.)
I wonder if Skype itself falls under MS's legal obligations to publish protocol descriptions.
I've used a transport for a while, but I've never successfully done a file transfer using one. Voice/video over transports is going to be even harder to do. I think that makes it a dead-end for most people.
Trust is also a difficult problem with transports, as they often need to store your passwords in plain. A single server storing your Facebook, Google, Twitter and Microsoft passwords just does not sound like a great idea to me.
Have you seen XMPP? Chat is so much more than just text now; it's "voicemail", and "photos", and "videos", and "stickers", and "Western Union" and "voice calls" and "video calls" and so much more. Plus, XMPP, is, like, XML.
Open protocols and federation are cool and all, but XMPP is not the protocol that will let someone be competitive in this space.
(Disclaimer: I work at Google. This is my opinion. I do not work on Hangouts.)
Having recently started working on a chat client that was intended to speak first-and-foremost XMPP, I have to agree: XMPP is... it's decades out of date and missing a number of absolutely critical, central ideas that are essential to making stuff work.
Examples:
- unique message IDs? Absent. XEPs kind of provide; but I can't tell you which of the three or for relevant ones are the most relevant (AMP IDs from XEP 0079? Stream Management from XEP 0198? Acking from XEP 0184? Something from Carbons or MAM in 0313 or 0280? You know, if you wanted some light reading...).
- multi device? Oh. My. God. It's bananas. The spec behavior is that whenever a client sends a message, the server is supposed to consider that one the most alive, and then route all future messages exclusively to that one. So you send a message on your phone? Yeah, your desktop is just going to silently stop receiving messages.
- there's a concept of "message carbons" to deal with this. This involves re-sending all your messages back to the server after you receive them, with special instructions to send them back again to your other clients. The amount of redundantly redundant XML involved is eyewatering.
Combine that multidevice behavior (messages can get randomly routed anywhere at any time) with the wild-west nature of message delivery acks, and you can see how ridiculously difficult this makes the basic idea of "all clients should see the same picture".
Overall, the XEP process, conceptually, is a great example of open extensibility. The trouble is, so much of this stuff is core to sane message delivery semantics that it really, practically speaking, causes huge problems when it's all considered "extensions". Stuff like message IDs fundamentally shouldn't be an extension because it's just too critical that all minimum-viable clients agree. You just can't build higher level stuff without that. XEPs are great. A community process for extensions should exist. It just needs to exist for extensions, not subsume the total set of realistic minimum viable features.
I want an open chat protocol.
I thought XMPP might be the one. Then, as the parent comment jibes, I actually looked at it. Tried to write something with it.
XMPP is not prepared to be the one, in any sense at all except for legacy support. I have all the respect in the world for all the folks who put effort into trying to make an open chat standard, but... honestly, we need a stronger foundation than this.
Since this seems to be resonating with a lot of folks, I'll also follow with something more constructive:
What I'd like to see is a messaging system that gets the basics right, and that's deeply aware that it's AP out of CAP. Messages are inherently commutative (think CRDTs) and can be received in arbitrary order; people on two sides of a partition should have no trouble reconciling coherent logs regardless of if there was a two minute netsplit or someone was backpacking for two weeks. I'm looking for any existing stuff that suits this, and willing to collaborate on making it if it needs to be made!
You may find happiness with matrix (https://matrix.org/). It's basically a "message synchronization protocol" done with today's technology (HTTP+JSON). The synchronization approach versus the messages being sent on the socket actually makes me think about mosh vs ssh.
Thanks for the suggestion. I skimmed their docs before briefly; I'm giving it a second look now, and realizing I passed by way too quickly last time.
It looks like they did tackle acausality head-on; I like what I see about previous message IDs being included in https://matrix.org/docs/spec/#pdus
Nervous about ever christening JSON "today's technology". JSON has the same problem XML in XMPP does: can't tunnel binary e.g. video without extreme backbending (jingle for XMPP is pretty much a textbook example of "too much friction -> not fit for purpose and near zero adoption"). But it looks like matrix is pluggable on transports, too, so that's potentially a sweet spot for lazy REST clients and powerful performance situations to coexist.
... And I popped into their self-hosted chat room. Observation 1: It works (!). Observation 2: the devs are dogfooding and seem both knowledgeable and friendly :) I haven't taken the leap to self-host yet (will later!); but from preliminaries, matrix is looking remarkably solid and well thought out. I'm going to try to build something with this! Thanks again for the link!
> Nervous about ever christening JSON "today's technology".
I use this to say "XML was the hot when XMPP was created, the way JSON is the hot today, when Matrix is created". I 100% agree with you that using a non-binary-friendly format sucks for pretty much anything that goes beyond plain text messaging:
- encryption
- files/emoticons/voice
- on the server side, any routing stuff
But still, like XMPP I hope this will not be enough to hamper its development.
> jingle for XMPP is pretty much a textbook example of "too much friction -> not fit for purpose and near zero adoption"
Amen to that. XMPP is basically an entity-to-entity messaging protocol, and yet because it can't handle binary there needs to be a negotiation step and yet another connection for binary stuff... blah.
The client-server API of Matrix only uses http+json as the lowest common denominator baseline for compatibility. Folks are more than welcome to implement custom more efficient transports like COAP/CBOR or whatever.
The server-server API is currently just targetting https+json just for expedience in getting started, but nothing to stop us negotiating more efficient transports in future - capn proto has come up a lot in conversation as a possible option. Handling signing is a bit more fun as we currently rely on signing canonical json, but surmountable.
As for binary transfers... well, random blobs are just handled as pure HTTP with a mimetype currently :)
Why do I feel that "be competitive" is a euphemism for "nailgun users feet to the ground by locking them into everything possible"?
I'll be honest with you my friend. I would prefer to physically mail people coins then use facebook/google/apple pay. As much as I distrust banks, they at least have a record of letting me move to a competitor if I ask.
Users want Snapchat using the Snapchat client without having to maintain a second account or re-find all their friends. Same with Facebook, Hangouts, Skype, etc. the ship for federation sailed when all the big players decided to kill XMPP and not try a new open standard.
Standards tend to run behind the state-of-the-art, but that's not a reason to avoid them. For example, the iPhone continues to support SMS for interaction with non-iPhone users, even though the iMessage protocol is richer.
If Facebook valued compatibility with as many different products as possible, then they would keep XMPP support. The issue is not about features or XML. Most likely, it's about them wanting full control over the end-user experience: "We recommend people access Facebook Messages on the desktop via Facebook.com or Messenger.com."
An interesting question is "why do standards tend to run behind state-of-the-art"? There are so many examples of this in the past (coming from a graphics background, OpenCL vs. CUDA). Is this something we can fix?
Perhaps it is about providing the right hooks into the specification to not compromise the end user experience.
I think Docker is an interesting project to follow in this regard. They have shown the ability to get both startups and large players (amazon, google, microsoft) onboard by keeping the platform open. Yet they are clearly focused on providing the best experience for developer/ops interaction with cloud services. It will be interesting to see the rollout of their extension mechanisms and whether they can be a primary interface to cloud services or will become a second-teir compatibility layer. However, even in this case perhaps chat protocols could learn something here.
I think the real problem with XMPP (and the visible lag between state of the art and specifications) is that there's no single big vendor behind it. It's both a pro (in that the specs should accommodate what the community wants, not what the vendor wants) and a con (because specs are written when vendors feel like it).
An interesting example is Google with SPDY. They wanted something new, built it, tested it, and then wrote the specifications (along with other actors of course). I think it is fair to say that without the SPDY experiment we wouldn't have seen HTTP/2 coming so fast. Google and the other actors had enough incentive (and actual time and money to spend) to make it go further. In the case of XMPP there's no such actor, unfortunately.
Yeah, good point. USB-C wouldn't have ratified so quickly if Apple didn't hand it over [1]. Apple could also be credited with putting pressure on OpenGL to release Vulcan when they released Metal API a year prior. Before this, OpenCL/GL hand't changed drastically in years. It seems big companies are involved whenever positive momentum happens.
> An interesting question is "why do standards tend to run behind state-of-the-art"? There are so many examples of this in the past (coming from a graphics background, OpenCL vs. CUDA). Is this something we can fix?
Its not broken. Standards are, ideally, distillations and applications of proven experience in a generally applicable way. You don't want standards trying to ride the bleeding edge, they want them to apply what is proven.
(OTOH, its good to have those working on the bleeding edge also opening for discussion how those experiments might be standardized while the experiments are still ongoing, and one vehicle for those discussions is draft standards or draft updates to existing standards.)
While there are XEPs to define these extensions, there is a huge gap between "you can do it" and "it's done here".
Could you cite at least 1 client that does all of the above on each platform (Linux, Windows, Mac OS, WP, Android, iOS) ? (This is a genuine question, I'd like to know if it really is possible, especially on mobile)
I share your pain, the state of actual implementations is sad. I don't know any (combination) of clients that do it all. Jitsi is pretty good but ugly and desktop only. Gajim is really good. Conversations is great for text on Android 4+.
It is no surprise that Whatsapp and the like are so successful. Textsecure/Signal is being too slow, I am afraid they missed their window of opportunity for fast widespread adoption.
Why not work on pushing an open standard instead of locking users into your proprietary client? I already know the answer (ads and user data collection; see also: G+), it just leaves a bad taste in my mouth #dontBeEvil
> If Facebook wants to be accessed by popular client software,
Why would you think they want that? It does not seem as if they do. I think it's much more likely facebook will try to stop this integration, than they will see it as a 'reward'.
> If Facebook wants to be accessed by popular client software
What I find the most funny is that Facebook is seen as a champion of Open-Source, then when it comes to this kind of things they very much take the walled-garden approach just like any other major company around.
> Officially it happened back in April [1], however I'm still logged in
It was the same with MSN, it was going to be turned off at some time but they kept it running a few months more. It's chance though: one day it may be just gone.
They have already removed the xmpp_login OAuth permission, they could shut down the XMPP server any day. I am wondering why they would remove the permission so long before shutting down the server, maybe to not break every client at the same time?
In the present and future, whenever there is a human need for an integration point between multiple services, those humans will need to invest in producing a human-level intelligence to integrate the information. We are compelled to build secretaries for everything that was nominally built for us, but without our best interests in mind.
I implemented a part of a similar Facebook HTTP-based chat protocol in 2009. May be the same one?
I had started in 2001 a KDE multi-protocol messenger client called Kopete. I went inactive later but in 2009 I was using Facebook a lot so I "revived" my Kopete checkout to implement this custom protocol. I got the basics working: send messages and presence.
Ironically, I stopped because they added XMPP support and Kopete already supported XMPP.
I now realize they deprecated XMPP it in early 2014, which is probably the reason Pidgin is now implementing the HTTP protocol I was looking at in 2009.
I used to use Kopete back in the KDE 3 days often. Thanks for your work!
Now, I don't really use IM like I used to. Back then (middle and high school), mainly with AIM and MSN, I'd spend hours on IM each day. Now it's an occasional Google Talk or Facebook message and using HipChat with my work team. A different world I guess.
I actually recently installed Trinity DE (continuation of KDE 3.5) just for fun and old times sake. One of the first things I did was install Kopete. I tried logging into AIM, but found only one person I barely ever knew online, with hundreds offline.
Thanks!. Most of the work, like in lot of opensource projects, was the product of a big team of great people, from which I learned a lot and I owe them a big part of shaping my career.
Completely different world!. Instant Messaging is now done in big part from the smartphone, or from a webpage while visiting a social network or checking email.
what made you want to write kopete when gaim was still pretty popular? i remember kde switching over to use that as the default around 3.5 not understanding why people didn't like gaim/pidgin anymore.
* At that time, most apps where available in their "desktop" versions. So if you used Gnome you tended to use Gnome versions of the app.
(it was a silly world back then)
* I was starting with development at that time, and the Gnome "SDK" was something I found not appealing at all. It could not even be called a platform, but a random collection of libraries. KDE on the other side was very consistent and appealing for developing GUI apps.
(And you may remember the KDE hate about non-standard-C++ and QObject, from the same guys that brought you Vala and GObject later)
* I had back then this opinion of not looking at my contact list by IM system, but by person with multiple transports.
That followed by KDE addressbook integration, etc. I would guess nowadays Pidgin also has this, but that was new back then. Kopete was a testbed for all this ideas.
Nice to see this, hopefully we'll get some more involved features like notification support and group chat. Still sad that Facebook never utilized XMPP chat to its fullest.
Trillian still works with Facebook chat: http://www.trillian.im/
They wrote a little eulogy when imo dropped 3rd-party chat support, I'm sure they'd be happy to see Pidgin add FB support! http://blog.trillian.im/?p=2902
I don't know how or why, but on my workstation at my job, Pidgin still always connects with Facebook, and I still use it every day to chat with people. But at home, on my own laptop, I get an error 500.
I don't get how it's possible that it still works here. Only difference is that my workstation runs Linux and my laptop runs Windows.
That's as long as facebook keeps their protocol open... which can change at a moments notice. I'll keep on using regular old facebook messages, SMS, e-mail, and textsecure.
Plus, the dynamics around group chats are tricky. Messenger shows when people are typing and what point everybody has read up until. You can rename group messages, leave them, add people, mute/disable notifications, or mute for a period of time.
Without good compatibility or fallbacks for all of this behavior, Pidgin users are in for a bad time. Most will probably go back in frustration and pin messenger.com in a browser tab.