Facebook Messenger XMPP is going away
developers.facebook.com
developers.facebook.com
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.
i'm sure there's valid business reasons to kill xmpp, not just total information awareness pressures from above.
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'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.
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.
nod nod
I mention in another thread that if Signal (nee TextSecure) doesn't take off, perhaps what we need is a super-sexy frontend on top of SMTP and IMAP.
> ...Do you have WhatsApp?...
The thing that really gets me going is the folks who will only send pictures with MMS.
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)
It should be in prosody 0.10 [1] (not stable yet) but I did not yet have a change to test it.
(And XEP-0313 is still quite new and experimental)
Not something you can expect all your friends to set up.
MongooseIM doesn't support it either, although there is talk of it being implemented [1]
To be fair though, it was only accepted on the 18th March 2015.
[0] - https://www.ejabberd.im/protocols [1] - https://github.com/esl/MongooseIM/issues/405
FWIW, somebody is working on an ejabberd module [1], and there's some discussion [2] on the <standards@xmpp.org> mailing list.
(And ejabberd's community edition supports the XEPs that are relevant to mobile clients too, BTW.)
[1] - https://github.com/royneary/mod_push [2] - http://mail.jabber.org/pipermail/standards/2015-March/thread...
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.
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.
[0] Looks like we were concurrently writing up our experiences: https://news.ycombinator.com/item?id=9267147
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.
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!)
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.
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.
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.
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.
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]
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.
Remember when we had ICQ, and AIM, and MSN Messenger, and Gadu-Gadu, and we were dreaming of a unified messaging system?
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. :)
While there are many upsides to free software, usability and user friendliness were never one of them.
Hackability, sure. But most people don't care, let's be frank. I will use Hacker News because it works despite being proprietary software.
Some of us do care.
Where is the source code?
Source code https://github.com/arclanguage/anarki/
But it's better than nothing.
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.
We'll always have SMS.
> 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.
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.
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.
> We'll always have SMS.
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.
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.
Of course, lack of adoption by the big providers was almost certainly political rather than technical.
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.
Side note: AOL/Timewarner actually owns the IM patent from ICQ (http://edition.cnn.com/2002/TECH/biztech/12/19/internet.aol....)
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.
[1] http://psi-im.org/ [2] https://groups.google.com/forum/#!topic/protobuf/eNAZlnPKVW4
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.)
* 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.
Couldn't the parsing be a pluggable component? Just set a standard on how data is structured and let third-parties figure out how data is parsed.
Are you saying mom and dad aren't using XMPP because the message is sent using XML based stanzas? Facebook is ditching XMPP because of the X?
It doesn't matter?
Saving battery on mobile devices for one.
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.
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".
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)).
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.
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.
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.
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.
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).
http://stackoverflow.com/questions/25982426/persistent-xmpp-...
There are implementations for servers, e.g https://code.google.com/p/prosody-modules/wiki/mod_mam_muc, but I have yet to see a client reliably supporting this.
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.
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.
The only thing that's missing, is end-to-end encryption.
Across all my devices - Web, Linux, Android and FirefoxOS. No advertising.
Telegram - http://telegram.org
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.
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.
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.
> Developers please use our platform!
> Developers we are now going to obsolete any work you've done with the XMPP front-end.
Demonstrating a clear moving target is not how you attract developers, Facebook.
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.
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.
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.
A very dark future awaits us...
On April 30, 2014, we announced the deprecation of the XMPP Chat API
as part of the release of Platform API v2.0.Now I'd wish someone would do the same for Gmail chat / Hangouts, or maybe a way to combine all the webviews into one ;)
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.
https://www.ietf.org/rfc/rfc3428.txt
-based on open standards (SIP)
-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).
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.
Basically, XMPP came first (first foot in the door) and is a significantly superior protocol due to its simplicity.
http://hnrankings.info/9266769/
Is there something particularly un-newsworthy about this change?
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.
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.
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.
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).
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!).
[0]: https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
[1]: https://news.ycombinator.com/item?id=2069810
It didn't really boost my confidence in their protocol design...
Not as bad as I remembered, but still... meh.
Read through this (with showdead on) for a bunch of links about tox and the pro/contra tox trolling that happened...
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.
Much like Apple is doing with the "green bubble" shaming on their keynotes.
Someone recently posted a graph api chat example.
I echo other sentiments here: what exactly is broken about XMPP that companies keep moving away?
{
"error": {
"message": "(#298) You must be a developer of the application",
"type": "OAuthException",
"code": 298
}
}
https://github.com/jgeboski/bitlbee-facebook
I think this one already uses the Graph API directly.
Thanks.
That'll be all.
--
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.
Business strategies and decisions shift constantly.
Does anyone have any more recent information on the health of jabber.org's XMPP service?
See my answer to the GP about available servers.
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.