Also it is worth mentioning that Google Talk !== Google Hangouts
Everyone who uses XMPP/iMessage/Adium to connect to Google Talk is:
1) Apparently missing some messages from Hangouts users. Haven't been able to track it down but it's gotten me in trouble with my girlfriend a few times for "ignoring her"
2) Your friends see you as "Online" on hangouts and send you messages, which often seem to relate to #1 (you never see them).
This has been a nightmare for me over the last 2 years and I can't stand how something as simple and SOLVED as chat protocol has been nuked and replaced with proprietary crap that thinks it's impressive to announce a semantic MAJOR release update that touts "Group Messaging" as a major new innovation (I'm looking at you, Apple).
Ok, rant over. Take care my friends and let's just switch everyone to IRC and be done with it.
> 1) Apparently missing some messages from Hangouts users.
Shit, Hangouts itself is an unreliable message delivery system. [0]
At least once an month in both group chats and one-on-one chats I will get messages that seem out of context. Somewhere between many minutes and an hour later, the messages between the OOC one and the previous [1] message will silently appear. The "new" messages are inserted between the previous and OOC message, and bear timestamps that make it look as if they were never missing.
I've even had this happen while I had the conversation in question open in the damn client! It's super-fun to see ten or so "new" messages slide in between two already-delivered ones. :/
So, if you've ever wondering if you had a brain fart and overlooked an important message in Hangouts, you may very well have not!
[0] Yep, I'm using the latest software.
[1] Previous at the time I received the out of context message.
Hangouts/google voice have been really bad in this regard for me. Lots of sms drops a year or so ago. No message drops in a while but constant notification drops getting me in trouble.
This may not be unique to XMPP...I use regular Google Hangouts with my fiancee (also on stock Google Hangouts) and have found that occasionally messages to my fiancee get to her hours later or not at all. Apparently the Hangouts team doesn't consider "reliable message delivery" to be a key feature.
I think people don't realize just how unreliable the major messaging networks are. There was a Reddit thread a year or so ago where some folks who worked in the telecom industry said that they shoot for a 98% delivery rate with SMS, i.e. one in every 50 SMS messages will just get lost. I've personally experienced arriving at a friends' house, sending them a text to let them know I'm there, waiting 10 minutes, knocking on the door, and then 20 minutes later, while I'm in the car with them, my own text message finally arrives.
I'm glad to see that I'm not the only one experiencing this Hangouts problem [0]. The lady friend thinks I'm nuts.
Speaking of SMS, when I lived in the American Southeast, I occasionally had SMS messages from friends be delivered months late.
Neither Hangouts nor SMS are the messaging systems of the future. :P If Signal (nee TextSecure) doesn't gain traction, maybe we need a super-sexy frontend over top of email.
What is worse is that all Internet banking and debit card transactions online(in India at least) depends on SMS for OTP as mandated by RBI guidelines. I have had OTP messages arrive 6 hours late while trying (and failing) to initiate banking transactions (which have a timeout period of 1 - 2 minutes).
Your bank is using a bad SMS service provider. With a SS7 uplink (versus a cheap SMPP connection), it should arrive within seconds, with a delivery report for the sender, if desired.
My wife and I have gone back to emailing each other (from our phones) because we have periodic issues with massively delayed text messages (e.g. ~7PM "ETA?", reply "30 minutes", delivery of that reply ~1:30AM). Some of that's likely due to flakiness of her (old, but has a keyboard!) phone, but regardless of that email moves right through.
Ahhhh that'll explain never receiving messages and my friends not getting them. Some bust scenarios I experience:
1. I will call my wife using Hangouts - she won't be notified on her phone.
2. I chat with someone via Google Talk on my old phone - if they're using Hangouts, they may or may not receive the message.
3. Someone will chat with me via Hangouts. My phone with Google Talk may or may not receive it; BUT! if I open the web browser version on a laptop, it'll receive it (and makes me look like an ignorant weirdo when I reply to messages that have been "there" for days...
Mobile hangouts to mobile hangouts mostly works (apart from the video call at intermittent times). Oddly, the Hangouts client will say that the person was not available for a video call (ie, they didn't pick up) but they didn't receive any alert or ANYTHING to state that there was a call coming in.
No offence to the team there, but it's a piece of junk. Video calling and voice calling and text all worked fine under Google Talk; under Hangouts, I might as well be putting messages in bottles and hoping they will reach the destination...
Even MSN Messenger was more reliable, and that was 15+ years ago; I am not sure how this is not a solved problem! (Not sure if they've fixed the lack of online/offline presence in Hangouts yet; if not, it is STUPID. "Are you there?" Who knows!)
Long before I hangouts I had lots of issues with Google talk. I started numbering my messages as in
1 Hey Joe
2 How are things in SG
3 Are you going to meet me at the airport?
4 Or shall I take a cab?
5 In any case I'll be into the city by 7pm so we can grab dinner
etc.
What we found was that Google talk was dropping messages. Lots of them.
With no way to complain and no way to prove it I just stopped using Google Talk. It was really disappointing to see it do so poorly though. Like most of the rest of you it seemed like chat was a solved issue.
What did you switch to using? My mum has an iPad, my wife has an iPad and also an Android phone, I have a Mac, my brothers have Android phones; do I just spam everyone on each network (Messages / Talk / Hangouts / Skype)? I tend to now SMS everyone - at least that's mostly universal (but my mum will never get any messages).
I would use Skype but it enjoys eating battery as a hobby on both mobile and desktop/laptop.
What I'm more disappointed in is that third-party developers aren't even trying anymore.
Back in the day, there were some truly impressive efforts to reverse-engineer AIM's protocol (and Yahoo! and MSN...) despite AOL actively trying to defeat them.
Nowadays, nobody even tries. When Google launched Hangouts, there was no massive reverse-engineering effort. Just people saying "I'll stick with XMPP and just not use the new Hangouts features". It's sad.
Sean Eagen is the more or less single person behind a LOT of that work. If you've ever used GAIM/Pidgin, you've used his work. Sadly, he was hired by google to work on libjingle, their XMPP video standard. Then he went on to work on google talk and now I believe google maps, but I've not looked him up in eons.
There are just too many different proprietary IM protocols, and they are often fast moving targets. You can't keep up with a team of Google engineers tweaking their protocol every day.
Have a look at WhatsApp, there was a bunch of efforts to reverse engineer their protocol, and they ended up non-working, abandoned or C&Ded [0]
I've seen a radical effect on the usage Talk due to this.
Only my tech-savvy friends would use Google Talk previously and the others would use Facebook. Since the push from Google to use Hangout, nobody I know is using Hangout or Google Talk anymore and it looks like everyone switched to Facebook/Whatsapp on my contact list. I don't even open the chat anymore.
My rant, apart from all your valid points is that they don't support half of XMPP extensions, including offline messages. So if someone writes to you while offline, you only get an inbox notification in Gmail.
Why IRC isn't the foundation for all chat I still don't know. I assume a lot of the typical workflow (logging in, choosing a nick) can be automated for users who don't care to know what chat protocol they are using.
Because it fails to satisfy so many modern demands. It doesn't even understand user names that aren't a subset of ASCII. Most of the commands aren't really standardized. It doesn't support end-to-end encryption (which today even WhatsApp is using). It requires you to be always connected instead of using push notification systems which are way better for the battery of mobile devices.
Probably the only reason the protocol is still around is that it's popular among a certain group. IRC is so different from what you would want from a modern chat system that it doesn't make much sense to build upon it.
True enough, but rather than "doesn't support" end-to-end encryption, it doesn't standardize it. You can slap OTR on pretty much any messaging protocol. Client support is a problem though.
The problem right now is persistent connections on iOS. You need to use push messages instead, which requires a plugin on the jabber server and a matching client.
Not something you can expect all your friends to set up.
There is a number of IM clients for iOS, that store your credential "in the cloud" (use their own infrastructure to terminate the XMPP connection and route push notifications to their clients). This is not ideal for your privacy, to put it into friendly words.
Step #4 (get your friends to use it) is really hard to do. I tried and failed with my friend group. If there's one non-technical user in the group (or one who is tremendously attached to their Hangouts chat history), you're probably doomed to failure.
i've had limited success, one factor that helped was me going cold turkey on the alternatives. also you define your own success, gaining a monopoly is rather a high standard!
We apparently have quite different friends. Removing myself from Hangouts means that I get information either in person, or through email, if at all.
I'm currently relying on the Signal rework of TextSecure to get most of us off of Hangouts: the big barrier to adoption has been easy-to-configure clients that work on Android, iOS, and desktop and sync message history amongst clients.
I have the same experience with not being signed into chat networks, or not having Facebook / WhatsApp / Twitter etc. etc. accounts. People either don't tell me anything, or they email.
The craziest thing I get asked is "Do you have WhatsApp? I can send you pictures, and it's FREE!". Oddly the thought of sending an email with a picture attached (how easy is it on a phone these days??) doesn't pop into their mind as being "free" either!!! Insane! Email is far superior, as I can archive it unlike IM history.
Yep. You'd need a server somewhere to store and replay that message history. There is an XMPP standard that specifies how to do that. Question is whether or not your client can speak that protocol.
XEP-136 is a good example why it's a bad idea to squeeze
everything into a single specification (or XEP in this case): The reason it was not implemented by most XMPP stacks was, because it's so much you have to implement. XEP-313 focuses on what is important to achieve WhatsApp like persistent chats in XMPP. Functionality which is lacking in XEP-313 can be specified later on in a different XEP. After all that's why it is called the "Extensible Message and Presence Protocol (XMPP)".
If you won't drop the other networks there's no need for them to join your server, your still on the networks they're already using. Only you can change that.
I would like to believe the same. The prosody folks are awesome btw (as an alternative to ejabberd).
But there are still open issues. One big one, compared to all the FB/Google/etc. offerings is the ability to have a usable chat log. Current xmpp implementations/standards are more or less useless if you happen to use more than one device and want to look something up/want to see what you wrote to your brother yesterday, on your desktop, while looking at your phone.
Mandatory extensions in my world:
- Stream Management (easy)
- Carbon Copies (easy)
- MAM/Message Archive (described above, hard, haven't found a way yet)
This will substantially change the way I interact with Facebook Messenger, and irritatingly so. For the past as long as I remember, all of my IM services have shown up in one client (naim; then Pidgin; then Adium). I'll now be forced to either use the Facebook web client (and, in doing so, feed the mis-tuned reward system in my brain that stimulates itself from seeing the notifications icon light up ...) or use a poor approximation of a keyboard on my cell phone.
It's irritating when a service that I use gets shut down. But, the thing that's truly irritating to me is that I don't even have the option of not using it: I'm locked in still by network effects, and Facebook know it.
I'm still not over the death of Facebook Messenger for Windows.
I've tried to use Pidgin for a while, but Facebook would often stop working and only come back to life a few days later.
I saw that they were deprecating the XMPP API right after they announced it, and I have been having nightmares about losing the ability to use Adium since. Still have no idea what I'm going to do if they truly don't release some type of client.
So, I don't do web or software development, let me tell you^W^Wrant about how chat in 2015 feels to use. I'm 27, I grew up on IRC, I know my ICQ UIN by heart. Chat has always replaced SMS for me, and most groupware as well. I was happy when Facebook came along, and suddenly even the non-nerdy friends were compatible with my preferred way of having an endless conversation about random things. Chatting feels natural to me, allowing to keep in touch with good friends but not capturing my attention the way a phone call does. It also interleaves very nicely with menial work.
I don't care much about cloud or private cloud or local app. I've used irssi on a server that everybody connected to via ssh. But I switched over to cloud services as soon as I had more than one device that could send and receive messages. Everything else was way too tedious, as I never knew which device was connected, where messages went, where unread notifications went or whatever. Nothing to do with closed vs open, json vs xml or whatever social pattern. XMPP was lacking features, simple as that! From a user perspective! XMPP didn't work!
Give me persistent group chat, shared chat history with a search function, synchronized unread/read statusses, and I'll be leaving the cloud with flying colors. My current best bet for a text messenger is Skype, but the app is way too clumsy on Android and Windows. Close second is WhatsApp with a few groups, running on a large phone with a well-trained SwiftKey2. Both feel about as great as ICQ6 with its banner ad, and none feel as great as Adium or Trillian did comparatively back in the day.
I've been using it for several months now and am very happy. Would love integrated voice calling, especially to landlines/mobiles, and hope someone develops a plugin for this soon (perhaps the guys at Jaconda[0] will do it).
I have just one regular contact still using Facebook messenger, and our conversations are now very disjointed, as sometimes I don't login to that service for several days at a time. I don't use Skype as a messenger service, but do still have about four or five contacts who are wedded to it for free voice calls. I use WebCallDirect[1] for cheap calls to landlines/mobiles.
Telegram looks really interesting. It has an open protocol and API so it should be easy to integrate with other systems; there is a libpurple port for it[1]. Maybe Telegram could be a replacement for XMPP?
My biggest concern with things like this is that AFAICT their business model is kind of foggy. Quoting from their FAQ, "Pavel Durov, who shares our vision, supplied Telegram with a generous donation through his Digital Fortress fund, so we have quite enough money for the time being. If Telegram runs out, we'll invite our users to donate and add nonessential paid options to break even. But making profits will never be a goal for Telegram." https://telegram.org/faq#q-how-are-you-going-to-make-money-o...
That's a very nice sentiment, but it's not a sentiment that fills me with confidence that I can rely on the continued existence of the free thing they're giving me.
You are so right. I really wanted XMPP to succeed and I used in happily back in 2002 or so. But it just doesn't seem to have evolved at all. You pretty much nailed it with persistent group chat and shared chat history. Skype can really get on my nerves, but it had this covered since forever, and trying to get people on XMPP without equivalent features is hopeless.
I used to use Skype for persistent, cross-platform group chat with my close group of friends. But we recently switched to using Slack, and it's far better.
The only thing that's missing, is end-to-end encryption.
Can you go into detail about what features were lacking?
For what it's worth, a lot comes down to what features the server admin has activated. I've heard many complaints about XMPP but this is the first I've heard someone mention lack of features as a problem with it.
In addition to logging as mentioned, I find that file transfers (encrypted!) that Just Work between users regardless of the network/client/server used seems to be missing.
I really like XMPP, and the extensibility it has is brilliant, but at the same time leads to a crazy level of fragmentation for the instant messaging use case.
You're basically guaranteed that you can chat to others and maintain a buddy list, but anything much beyond that is a toss up, depending on the server used, how it's configured, and what client each user has.
Server-side chat logfiles that are distributed to all connecting clients? I've never looked into the protocol, but I'm pretty sure that one is lacking.
There was certain controversy about which protocol to use for sharing history between clients for both private chats and MUC, but now XEP0313 seems to be the future of it.
I haven't heard of an extension that does that either, but I'm not sure that would scale well for busy long-running Multi User Chats.
But the benefit of XMPP is that a new extension can be proposed that does this if enough people want such a feature. Personally I would argue that a better approach would be to make Public MUC logs accessible and searchable via a web interface and to have the client log chats going forward from when they join (with offline messaging from the server so you don't have to be online the whole time).
The problem with XMPP MUC's is that it's modelled after IRC, as that's what the protocol hackers know and love. But (please forgive the hyperbole) normal people don't use IRC, they use Skype. And the Skype model is so foreign to the IRC / XMPP techies that they'll always dismiss any attempts to add these features, often with spurious technical doubts as you just did. Ignoring that Skype has these features since a decade and has taken over (some parts of) the world because it has them. (Skype alone today has about ten times more daily active users than all IRC networks together!)
If you're talking about Multi-User Chats, then on entering a room the server should send previous messages (http://xmpp.org/extensions/xep-0045.html#enter-history), with no requirements set in stone (except when the client specifies a maximum amoun to send).
When a client logs in, it is true that a server doesn't have to send messages back, but that's the goal of XEP-0313.
This is what we get when we embrace closed platforms. Free Software gets you nice, simple, easy to use services and closed platforms will always manipulate you for their needs.
This is why I want to make a Free Hardware cell phone. I have made one wireless product already and wrote the frequency hopping stack myself, but something like a phone needs better data rates and a more advanced protocol.
Still, I dream of a simple cell phone that runs vanilla linux and has apps for IRC, XMPP, and the other functions you would want. The key component would be that the protocol would be designed from the ground up to respect user privacy, including a "broadcast" mode for towers where certain low data rate data channels are streamed without requiring any transmission from the handset. Then you could follow IRC or twitter during a protest without any risk of being probed for your location.
The protocol would also be built with anonymity in mind as much as possible, so phones would route data using rolling anonymous ID numbers and spoofing location could perhaps be trivial for plausible deniability (unless that opens up a vector for DoS).
I met the "Game of Drones" guys last night and they seemed interested in my wireless. I can only do 1km at 20kbps with current boards and 10km at 20kbps with amplified boards, but I think they might be interested in a solution that would work for FPV and that could be a good excuse to develop something that would also work for a cell phone.
I am 100% Free Hardware all the way, so maybe your dreams can come true eventually. :)
Hacker News is not proprietary software. It's open source under the Perl Foundation Artistic License 2.0 (FSF compatible). It's even written in Arc Lisp, which is nifty.
But free software can do things proprietary can't, like maintain trust with the user and provide maximum good. Think about all the good things people could do with facebook but have been blocked because facebook wants to protect their one narrow use case. Social Networks won't reach their full potential until they're totally free software, because facebook has such narrow interests.
So sure, you're happy for now, but billions of people are getting spied on and getting sick of it, and out of work programmers are increasing for number every year. As users get more fed up with proprietary companies jerking them around, I feel like people will start to demand Free Software. However this may be what all engineers who fall for Free Software think... I make Free Hardware so my plan is to prove why Free is better to people. We'll see if I succeed! I just recently realized that was the issue so I am working on that now.
Back then, we had Pidgin, Trillian, Kopete, etc. that would let us connect to all our messaging services with one client.
But nowadays nobody even tries to reverse-engineer protocols anymore. Where are all the people reverse-engineering Hangouts or Facebook Messenger? I wish we could teleport the people who reverse-engineered AIM, Yahoo!, and MSN to the present day, because they don't seem to exist anymore.
I've been saying for years that an update to the IRC protocol to allow for push notifications without requiring users to have a shell and set up a bnc would be pretty much ideal.
The constant ping-pongs really dissuade me from using IRC on my mobile as it kills my battery life. Being able to set some kind of "mobile" mode and receive push notifications if I get a hilight would be ideal.
I've ended up using the www.ircCloud.com service as my bouncer. It gives lovely native mobile apps with proper push and has a much nicer/more usable interface than any other solution I was capable of rigging up myself.
Some of the cloud-based IRC clients do a lot of this (I'm a big fan of IRCCloud). But it would be nice these kinds of features were baked into the protocol. When something like a majority of users want a feature, it should probably be part of the protocol.
I don't know if you're being ironic about JSON. Note that jkarneges, who comments elsewhere in this thread, is the creator of Psi [1], arguably the best XMPP-focused messaging client.
The value/burden of XML has always been a topic of debate for XMPP. In retrospect, I think it contributed to its lack of appeal, though the extensibility and readbility (ehm, arguably) it provided were unique back then.
I've long wondered about which alternative base protocols could be used in place. JSON is OK, but may be as much a fad as XML. I've wondered if ASN.1 could be used, but ProtoBufs sound like they're a better fit [2] in that they're simpler, more space-efficient, and backwards-and-forwards compatible (and thus extensible, XMPP's main feature) In fact, it's what Google already uses themselves.
What is the purpose of layering your chat protocol over another protocol at all?
SMTP has no "base protocol" in this sense. HTTP, nothing (unless you count RFC 822).
It's hard to think there protocols would have had the same life time if they were based on XML, JSON, or protobufs. (Yeah, HTTP over XML, that should be enough to give you nightmares. But welcome to DAV and XMPP.)
If you're looking for a happy medium between the readability of JSON and XML and the efficiency of ASN.1 and protobufs, take a look at canonical S-expressions[1].
There's an advanced representation, which looks like this: (message (header (sender "Billy Joe Bob") (sent "2015-03-26T12:02:00Z")) (body "Hey guys! Let's meet up for lunch!")). It's possible to encode any byte string using Base64 or hex. It's also possible to encode types with data: (message (header (sender "Billy Joe Bob") (sent "2015-03-26T12:02:00Z")) (body [text/html]"<p>Hey guys! Let's meet up for lunch!</p>"))
While there are multiple advanced encodings for the same data (e.g. foo or "foo" or |Zm9v| or #666f6f#), there is a _single_ canonical encoding for any datum: the messages above would be (7:message(6:header(6:sender13:Billy Joe Bob)(4:sent20:2015-03-26T12:02:00Z))(4:body35:Hey guys! Let's meet up for lunch!)) and (7:message(6:header(6:sender13:Billy Joe Bob)(4:sent20:2015-03-26T12:02:00Z))(4:body[9:text/html]42:<p>Hey guys! Let's meet up for lunch!</p>)).
A huge advantage of this canonical encoding is that it's amenable to cryptographic hashing and signing; a weakness of JSON is that one has to layer requirements atop JSON itself (e.g. alphabetising object properties) in order for two parties to be able to hash the same datum and get the same value.
Another advantage of canonical S-expressions is that it's straightforward to define a mapping between them and HTML: "<p class='foo'>This is a <em>nifty</em> paragraph.<br /></p>" could be represented as ((p (class foo)) "This is a " (em nifty) paragraph. (br)). There are other possible mappings between S-expressions and HTML, of course, but I like that one. Another might be (p (/ (class foo)) "This is a " (em nifty) paragraph. (br)).
> there is a _single_ canonical encoding for any datum: the messages above would be (7:message(6:header(6:sender13:Billy Joe Bob)(4:sent20:2015-03-26T12:02:00Z))(4:body35:Hey guys! Let's meet up for lunch!))
This reminds me a lot of bencode, with the advantage for bencode that it doesn't need any fiddling for non-printable characters: no more base64, no more hex.
The base64 & hex stuff is only used for the advanced, human-readable bits; on the wire it's just straight length-encoding and byte strings.
I'd say that bencode's advantage is a built-in standard for integer encoding (with canonical S-expressions one must decide between ASCII decimals or little/big-endian bit strings), and a clearer standard for a dictionary/map/hash (a canonical S-expression would probably use an alist-like structure like (map (foo bar) (baz quux)), but one could also go with (map foo bar baz quux), (map (foo bar baz quux)) or some other encoding.
* XML has a formal, class-based description language (XML Schema) with strong typing, polymorphism, and - best of all - self-descriptiveness.
* Languages like Java have a seamless, bidirectional mapping to XML Schema.
* XML has a rediculously powerful and elegant transformation language (XSLT) which makes scraping, selective data extraction and processing trivial.
The problem with XML is that people who require instant satisfaction are not willing to invest the time to understand it, and the mature tooling ecosystem around it.
The XML ecosystem solves problems, and contains solutions to problems, that the JSON / JavaScript ecosystem can only dream of, and is hell-bent on partially re-inventing.
If you need strong-typing and self-descriptiveness, you're out of luck with JSON. Binding JSON to a strong-typed language like Java or Haskell is a total ball-drag compared to XML + Schema.
As much as I can agree that XML doesn't prevent user adoption, it may very well prevent developer adoption; if developers are not willing to bother with XML or any part of the protocol, they may very well give up and develop for some other platform.
Yes, that may sound futile, but in the end the developers are the people who build everything. It is my strong belief that HTTP, IRC, SMTP and bittorrent (among others) have thrived because of their utter simplicity, to the point we're embarassed today because we've ended up with so much under-specified crap on top of them. Still, they deliver. As always "worse is better".
Wait, wait. We're talking underlying data format here.
Are you saying that serializing something to JSON (or whatever you fancy here) vs. to XML .. saves battery?
I mean, XMPP is certainly not the battery friendliest tech right now (elsewhere people discuss push extensions for example), but .. that's not related to the use of XML.
Having to support a panoply of marshaling standards would suck battery more, not less. I doubt XML vs. JSON vs. YAML per se makes any substantial difference in CPU usage. You might get a little mileage in going to a compact binary format and reducing data transmission, but is that worth it?
The funny thing is that XMPP was created when XML was the current hotness.
SMTP survived despite changing fads. If we're ever going to standardize IM (or anything), we have to accept that protocols may use older technology. Someday JSON will be old too. Let's not make these mistakes again.
At the time when XMPP was getting standardized and was still mostly known as Jabber, I started implementing a Jabber chat client with a friend.
The problem with XMPP isn't that it was based on XML. No, what made it annoying was that the dudes who made it decided that instead of basing it on exchanging individual messages, i.e. XML documents like everyone else does, everything must instead be put inside a so-called XML stream.
IIRC it basically meant that the exchange started with a start tag that wasn't terminated until the connection was closed. Since nothing at the time was designed to work with unfinished XML documents (remember the end tag doesn't come until you're done), all the convenient standard XML tools/libraries wouldn't work.
So I don't think XMPP is a stellar piece of work. But it's of course much better than some proprietary crap, and it's sad to see it lose support, although I imagine to Google and Facebook who both probably couldn't care less about interoperability, having an open XMPP interface is probably more of a liability (spammers, enables people to skip their ads) than something they get much perceived value out of.
Even though it seems like a strange decision, using XML for the stream framing made the protocol nicely pure. It theoretically meant you didn't need to write a parser (this was a rare thing for a network protocol). In practice, though, you're right, most parsers at the time didn't work well with network streams.
Of course, lack of adoption by the big providers was almost certainly political rather than technical.
Maybe we need a new standard JSON protocol, I bet part of it falling out of favor was the XML.
Messaging is one of those areas that is actually pretty simple that corporations that want to own channels have munged up pretty bad into a complex mess. Companies internally even have a couple or few.
Yeah, I don't think the issue with with the implementation, it's with the fact that it can't be controlled that companies didn't like. We either build systems to use ourselves or let private companies control our communications.
SMS? Or SMS, iChat, Hangouts, Whatsapp, and the thousands of others that use your SMS number as username? Some (iChat, Hangouts) even steal your SMSs and place them on proprietary networks; If you switch devices from iPhone to Android or vice-versa, messages get lost.
> If you switch devices from iPhone to Android or vice-versa, messages get lost.
I moved from an Android phone to an iPhone, back to an Android, and then back to an iPhone again. I never had my messages in limbo, and its easy to fix (at least, on the Apple side) if it occurs: https://support.apple.com/en-us/HT204270
Note that link also comes up as a search engine provided result by google just by googling "disable imessages". That's stupid simple.
First of all, I'll wager a supermajority of iPhone users do not understand any distinction between iMessage and SMS. Apple designs away the distinction. Secondly, when an ex-iPhone user ports away their number and is able to send SMS's without issue and receive SMS's from most of the world except for iMessage senders, how are they supposed to 1) discover they have lost messages before they lose something critical, and 2) discern that the cause of their inexplicably lost messages, is that they need to "disable iMessage", when they are not even an Apple user anymore?
I'm not an Apple hater, I use Apple products, but this is a huge fuckup and the OTT fragmentation is a real issue vis-a-vis SMS.
And SMS is not IM so your premise from the start is a nonsequitor. It's telephony, it's wildly and widely overpriced and non-open.
I think you're right about the lack of widespread distinction between SMS and an iMessage. It's sad.
Even sadder are the news articles (like ones you find in the technology section on the BBC website) where they refer to instant messaging as wonderful and then "if you're a bit old fashioned" and still use email...... At least emails can be easily retrieved and archived.
Perhaps people don't care about the transport medium (phone network or Internet) but it is an important distinction. It's even more important for Google users because Hangouts is very flaky for me, unlike SMS.
It's not about the best solution, and everyone needs to stop pretending it is. This sort of thing comes down to which solution has the most corporate backing. The only exceptions are when an open solution happens to hold on for long enough (on the order of years) for a major player to realize that its good and maybe they should give it a chance (example: OpenStack's support by PayPal right now, or when Linux finally started going someplace in the early 2000's with Canonical and RedHat). Give me an example of 'the best solution' winning despite major corporate backing of the proprietary competitor?
I don't think it's even as simple as corporate backing, though that certainly plays a part. It's significantly the arbitrary whims of the population; Whatsapp was not corporate backed, and still captured huge marketshare.
I was thinking about this recently. After having some trouble with my iPhone 5 sending SMS's last year and my Nexus 6 sending and receiving MMS's this year I feel that SMS/MMS reliability has gotten really bad. I know it's due to a cocktail of buggy OS's and the cell phone towers themselves but I never thought my old Motorola flip-phone from 10 years ago would be more reliable than this stuff.
Facebook is trying to make the platform too good for startups to resist building on. By the time something built on the platform emerges as a success, Facebook can either heavy-hand them into an acquisition, or lock them out and take away their momentum.
We need two things. The first is a piece of software or robot that can just keep browser tabs open along with iMessage/wechat clients whatever and then reads it and transfers any message that comes thru one of these locked down services to the second thing which is an open federated universal communication service/app.
This app would have a slider at the top and if the slider is all the way on the left you get 1-1 messages/mail from the most important people in your social network and all the way on the right you get 1 to many things of people you don't even know but you follow on Twitter/twitch/youtube/RSS/tv shows you watch. This app makes money because people/advertisers can pay to increase how close they are to you for one message and the money is split with the user who also sets the cost. So for a million dollars you could call Jay Z who might be sleeping but he's making 500k so what the hell, sure he'll listen to your demo.
...and fast forward few years and you have the Black-Mirror episode "Fifteen Million Merits" happening world-wide.
How long do you think it will take for advertisers to realise that people will watch "stuff" even if you don't pay them as long as they have nothing better to do. Add to this the fact that major media outlets (movie productions, tv-channels) will jump at the chance to broadcast ads as entertainment.
I would love this for Windows. I've missed a Windows client since Trillian/Pidgin couldn't keep up with proprietary features, and Facebook discontinued its own messenger application.
Unfortunately it doesn't work well on OS X and still requires me to run Chrome in background next to the Firefox leading to alot of annoying horrible window switching issues (for some reason chrome apps tend to get stuck in background when alt-tabbing, sometimes it just hangs, burns alot of memory for a really simple interface....)
All those "web apps" that were meant to be coming to the desktop and the flurry of excitement when browsers started adding the ability to add shortcuts on the desktop to a "web app" seems to have died down, and with good reason I think! Some people don't want to be sat with a browser open all day. Given that browsers are turning into mini-OSes themselves, it's irritating as they don't fit into the OS window management system easily (like awkward popups/alerts).
I saw this, but from what I understand it was only if you had an Android phone, and it needed to be beside you the whole time while it procesed the messages for you in the background?
the wave of openneness that started with the web is being extinguished everywhere.
mind you, one could improve XMPP, or come up with an open alternative. But this is no longer the focus. Short term money and numbers is/are the focus, as per pre-web companies.
This model always end up being bad for the masses of course, and only good for a few.
-supported by most VoIP servers (so we have full interoperability between vendors such as Cisco, Huawei, Siemens, Voipswitch, Mizutech, Jitsi and others)
-simple and extendable
-lots of free services, free/open source software. You can also host your own or integrate into your company PBX
In the previous years, we always see the same path for messaging applications:
1. Startup company add messaging based on open standards (SIP/IRC/XMPP/other?)
2. One the company has significant user base, switches to a non-standard / proprietary protocol
Already happened for Skype, Yahoo, Google, Facebook
It's the first time I hear anyone describe SIP as "simple". If you printed out all the SIP specs, you'd probably have a pile close to a meter high. Among the protocol crowd (including IETFers) SIP is often regarded as an example of protocol design having gone off the rails in a spectacular fashion. It has been repeatedly beat in the market by proprietary protocols that do things better (e.g., see the mess SIP NAT traversal ended up as compared to Skype).
Yes, the SIP protocol is not so simple. However a lot of well working implementations already exists (source code, libraries, ready to use software). The core messaging in SIP (RFC 3428) is extremely simple to add as it is just a single method (MESSAGE).
Adding presence and other funny things with the SIMPLE protocol family is another subject. (However the basic presence is also very simple ...the complications comes when you wish to add file transfer and other fancy things).
But these can be used as an extra so at least the for chat you are fully interoperable with all other vendors.
I've heard from people who have tried to implement it: SIMPLE (3428) is anything but simple. It is a very good example of "enterprise design." In addition, as soon as you start extending the protocol there is a very good chance that your implementation will no longer be interoperable. Take Lync (Microsoft's implementation of SIMPLE) as an example: due to the presence of custom extensions, clients have to implement specific support for it - the protocol doesn't gracefully degrade like XMPP does.
Basically, XMPP came first (first foot in the door) and is a significantly superior protocol due to its simplicity.
I only realized XMPP support was ending a month ago, I am not sure how I missed the notification but this just introduces a new way for me to miss messages.
I think the writing is on the wall for XMPP, even Cisco is now working on Project Squared/ Spark and I expect will be killing off their Jabber software (The tone from their collaboration SMEs has become quite negative). Personally I believe WebRTC based technology can provide a much better user experience and more powerful capabilities than XMPP. Further, as a front end to SIP, it could be a great thing for interoperability, especially with PSTN. However, it really looks like it is being used as an excuse to create new walled gardens.
Fortunately some carriers are migrating to IMS and provide softclients for computers, tablets and smart phones (Rogers One Number, and Telus Extend). This is the lowest common denominator, but I can chat with everyone with SMS as well as make phone calls from whatever device I choose. However, although technically possible, multiuser chat and presence is still not available.
So here we are 20 years later, and chat is more fragmented than ever, but at least unlimited SMS is now common. AT&T and Verizon are finally beginning migration to IP peering which opens the way for video calling over the PSTN. I think there is an opportunity for carriers here if they would get their act together. 6+ platforms (Skype, Hangouts, FB Messenger, iMessage, BBM, SMS) really doesn't work for me.
IRC was essentially created 25 years ago. In all that time we have still to make anything significantly better.
Why does a system with the following features not exist:
1. Requires all implementing servers and clients to support the full protocol
2. Allows users to communicate to users on other servers ( not just users within a
server )
3. Has free client open source reference implementations for native use ( C or the like ) and some web language ( Python & Dynamic JS )
3b. Has a free open source server reference implementation
4. Logging on the server indefinitely
5. Is always encrypted ( end to end via public keys, so that clear data never
reaches the servers )
6. Offline messaging
7. Large file transfer with clean re-connection and continuation ( if neither party has a publicly accessible port, payment/membership to the server would be required to facilitate the transfer... )
8. Random chat
9. Group chat
10. Utf8 for full multi-lingual use
11. Index of users for finding other users
If someone would just create such a thing it would put an end to all the stupid shifting from one system to another from year to year. I'm getting tired of switching systems and reverse engineering shitty protocols in order to continue doing the same thing with less features.
Did you just describe email? There are a couple of things that make email unattractive for chatting: 1) latency (seconds or minutes instead of sub-seconds), and 2) user habits of treating emails as something that can be responded later instead of NOW.
I grew up with IRC, but I now prefer emails to chat. It makes you think a bit more before hitting "send", and so the signal/noise ratio is higher with emails.
1. Email client have vastly different feature sets and capabilities. Most notably, the HTML support is very different from one browser to another.
5. The vast majority of email systems do not even support encryption of the message itself
7. Large file transfer via email is horrible and extremely limited
8. No random chat support
9. No group chat ( cc doesn't count as it lacks history of the group chat )
10. Have you ever received emails seemingly full of gibberish? Utf8 not supported properly in majority of implementations. ( which imo requires getting and using a font that supports the codepoints )
11. No user index ( saying that you could have an address book also doesn't count; and that is a seperate thing which also there is no one spec that is used by all people using email )
12. No real time messaging support. Inherent in the discussion is that chat software is insant, not based on server polling.
> Email client have vastly different feature sets and capabilities. Most notably, the HTML support is very different from one browser to another.
That's hardly an email issue, that's a client issue. The mail protocol doesn't care much about the content.
Also, you will find some people averse to using HTML email.
> The vast majority of email systems do not even support encryption of the message itself
Again, that's not part of the email protocol itself, and as far as email encryption goes PGP is pretty much the standard. The real issue here is whether to use the sucky PGP/inline or the proper PGP/mime
> No random chat support
You mean randomly send an email to someone, without being invited ? That's pretty much what spam is.
> No group chat ( cc doesn't count as it lacks history of the group chat )
I don't see why cc wouldn't count, when combined with the various In-Reply-To: and Refenrences: headers, you can build a very solid group chat history.
> Have you ever received emails seemingly full of gibberish? Utf8 not supported properly in majority of implementations. ( which imo requires getting and using a font that supports the codepoints )
Again, a client problem, but I'll agree that clients can lie on the actual encoding that is used in emails. Mandating UTF-8 would be such a heaven.
> No user index ( saying that you could have an address book also doesn't count; and that is a seperate thing which also there is no one spec that is used by all people using email )
I don't understand. Why couldn't a server index your emails and extract your contacts ?
> No real time messaging support.
Theoretically, you can (and should) run an MTA on your machine; you'd then receive messages in real time
> server polling
Polling sucks, don't do it. If you don't have an MTA on your machine, at least use IMAP IDLE. Disclaimer: I wrote this (https://github.com/rakoo/idlewatch) to automatically sync all my mails when there's something new.
Do you see a realistical future for the protocol? How large would the motifications have to be to reflect a "decent" feature set for the current device landscape and user's expectations?
I never even turned it on. Since they split messenger off I can no longer read read messages on my cellphone...without installing a separate app. Functionality that worked perfectly fine previously until they decided to disable to force messenger onto people.
Can't you just open facebook.com in your phone's browser? I've been doing that for a couple of years since noticing that it's both faster and more reliable than the Facebook iOS app.
If you're on Android, you should check out Tinfoil for Facebook. It's a wrapper for facebook's mobile page. I find it more useful than the regular facebook app. You can also get notifications back using IFTTT.
Thank you for the suggestion. I'll check out Tinfoil.
On the whole my FB interaction is fairly minimal and I expect social companies to push the limits so to speak. Such is life. This particular case was just so blatant that I can't help but react with "go shove it a place the sun don't shine" (colloquially speaking).
If they added new functionality & put that into a new app...cool. But to strip existing functionality, block it from existing users and add it to a new app with extended privacy intruding permission...that is simply unforgivable in my books. (FB employees reading this - and I know you are - see sun reference above for exact instructions).
I just wanted to comment on how evil facebook is, but I've decided not to. I think there are enough people here who think the same. What facebook is doing is probably just an example of "Embrace, Extend and Extinguish" [0], though, I understand that their decision is not the same what microsoft did back then.
So to my point: Do you really think facebook is doing this only out of pure 'evilness'. They were probably facing various of problems with XMPP, and already switched with their infrastructure from XMPP to their own 'inventions'. If their own development is already proven to be working, they don't have a reason to stay at the expensive XMPP protocol.
[1] & [2]: I understand why XMPP can be nice to build into your applications (there's even a social network based on XMPP), especially in the early stage, but when you go big - or mobile, I guess the 'flaws' in the protocol are just becoming annoying
(Disclaimer I've no clue what I'm writing about) I wonder why there is no better open protocol or standard for text chat, and if - how can we encourage facebook & other giants to use it. I'm curious how tox [3] is going to do in near future. At the moment, it feels like XMPP is the only open chat solution, which no-one can touch since Pidgin, Adium & Gajim are all broken (I'm still thankful for this tools!).
I read through some github discussions in the tox github page, and I can't really shake the feeling that they don't know much security. Someone had a question about the protocol design and about how secure it was, and the dev just linked to NaCl and said "read the source here and you will see that tox is secure".
It didn't really boost my confidence in their protocol design...
To play devil's advocate, what part of the XMPP protocol is dated, that doesn't allow Facebook and Google to continue using it? Maybe if there's a way to update XMPP to include features that shared amongst these services, they can fall back to using it?
A big problem for me is that there's no push notification standard. This means that a mobile device needs to keep the app running and stay awake to receive messages. This kills batteries faster than you might expect.
Probably missing the feature that requires users of external networks to register with Facebook or Google in order to send messages on the Facebook or Google network.
Just like SIP, XMPP is one thing on paper (with all extensions) and a different thing in reality, where different clients communicate through different servers with different set of extensions.
What you can always do reliably is have a buddy list with status presence, and do 1-1 chats. In my company, with all Linux clients, we couldn't even manage to send files reliably across different clients.
What Google and Facebook need across a messaging service is much more:
* sending pictures, displayed inline
* sending audio messages
* making phone and video calls
* sending money
* being battery friendly through push notifications
* having chat history reliably stored across devices
* persistent group chats with advanced client-level tuning (eg: turn off notifications), again shared through multiple devices
Notice that most of these features require implementation and design on both the server and client level; not having control over client implementations means it might take many years to get a feature standardized and adopted by the majority of clients.
I think Google really tried to make XMPP go forward, but in the end it was slowly them down too much compared to competitors going full proprietary like Apple.
Probably the part where they're not locking you in their network by way of convenience. Forcing you to use their homepage (FB) or browser (Hangounts) and preventing you form using unified messengers gives their other services exposure and makes users advertise/annoy friends to join their chat service.
Much like Apple is doing with the "green bubble" shaming on their keynotes.
You have to be an app developer for that to work: /me/threads is accessible only to developers of an app, and there is no permission that you can grant to an app to make it work. Otherwise, you get:
{
"error": {
"message": "(#298) You must be a developer of the application",
"type": "OAuthException",
"code": 298
}
}
You get this even if you try to use the Graph API Explorer tool to view /me/threads.
Somebody already said it: while using the chat through a different client than their web chat, you're not looking at their ads, you're not installing their proprietary mobile app, and so on.
Can you link to the example? I've been interested in doing something like this, but as far as I can tell, you can only read messages using the Graph API; there's no method for sending messages.
As far as I understand, no. (A request for an API to write a desktop client was the top "most-liked" comment on the Messenger-platform blog post, which is how I found out about this.)
Is there an alternative to Pidgin in this regard? I only use Facebook to chat with my friends (over Pidgin) and I don't want to touch their website if possible.
It matters in two ways: it further fragments the space (having one unified way to communicate with multiple services from multiple vendors especially such large ones is showing strong support for that unified way) and it limits access to the service through existing clients which will piss off a small but vocal (and likely early adopter so early leaver) section of the audience.
Note to those setting up new XMPP accounts: DuckDuckGo has a solid XMPP server[7] available for public use. They do their damnedest to protect privacy also, from what I understand.
If you "follow the money," then this move makes sense. This is simply a move to display ads to every person using Facebook chat. (Facebook's not happy that they couldn't show ads to those of us using pidgin et al)
Will it need the endless list of permissions like it does on Android? It seems to want access to my entire phone, life, brain patterns and toilet usage patterns.
In all seriousness, there is no indication as to what a desktop app is accessing or doing, and given the extensive "fingers in all pies" access that the Android one has, I wouldn't be quick to install a Facebook native app on my desktop!
I don't really understand why they took the XMPP API to such lengths (it even displayed OTR messages as [encrypted message], that's not really the kind of thing that comes to mind instantly when I think about an XMPP API) to finally deprecate it. Pidgin will probably see a sudden surge of bug reports.
I'm guessing it's a conflict between developers and management. Questions like "what protocol should we build our messaging system on top of" is an implementation detail decided on by the developers at the beginning of a product's lifespan. Stuff like handling encrypted messages gracefully is simply a developer doing their job thoroughly, not a directive from management to focus on the XMPP API. Then later in the product's life, when they want to build a platform and business integrations and sending money and all that other monetization stuff, restricting third party client access suddenly becomes important.
jabber.org doesn't accept new registrations since 2013.
If you're looking for a public XMPP server to register an account at there is a (no longer updated) list of Jabber servers at https://xmpp.net/directory.php and a more up to date list at https://list.jabber.at.
You can register an account any public XMPP server at https://conversejs.org (via the chat client in the bottom right).
Incidentally, I run the conversejs.org server which is open to registrations.
> I don't really understand why they took the XMPP API to such lengths (it even displayed OTR messages as [encrypted message], that's not really the kind of thing that comes to mind instantly when I think about an XMPP API) to finally deprecate it.
Business strategies and decisions shift constantly.
In my experience (as of about a year ago) the jabber.org servers are -I guess- seriously overloaded. Frequent disconnection or failures to login were the norm for my @jabber.org account. If I had to guess, I would bet that they're under frequent "attack", but I really have no idea.
Does anyone have any more recent information on the health of jabber.org's XMPP service?
Everyone who uses XMPP/iMessage/Adium to connect to Google Talk is:
1) Apparently missing some messages from Hangouts users. Haven't been able to track it down but it's gotten me in trouble with my girlfriend a few times for "ignoring her"
2) Your friends see you as "Online" on hangouts and send you messages, which often seem to relate to #1 (you never see them).
This has been a nightmare for me over the last 2 years and I can't stand how something as simple and SOLVED as chat protocol has been nuked and replaced with proprietary crap that thinks it's impressive to announce a semantic MAJOR release update that touts "Group Messaging" as a major new innovation (I'm looking at you, Apple).
Ok, rant over. Take care my friends and let's just switch everyone to IRC and be done with it.