Comment by AceJohnny2
11 years ago
Sigh, yet another nail in the XMPP coffin, at least as far as the general public is concerned.
Remember when we had ICQ, and AIM, and MSN Messenger, and Gadu-Gadu, and we were dreaming of a unified messaging system?
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.
> ... persistent group chat, shared chat history with a search function, synchronized unread/read statuses....
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.
[0] https://jaconda.im [1] http://webcalldirect.com
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?
[1] https://github.com/majn/telegram-purple
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.
Wow, Telegram looks great! Now if I only could convince all of my friends to switch...
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.
5 replies →
1339782 add me
Now we have twice as many incompatible services. And still dreaming. :/
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. :)
> Free Software gets you nice, simple, easy to use services
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.
5 replies →
It's worse 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.
It's worth noting that XMPP was based on XML. New hotness is JSON, or maybe even compressed binary protocols.
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.
[1] http://psi-im.org/ [2] https://groups.google.com/forum/#!topic/protobuf/eNAZlnPKVW4
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)).
[1] http://people.csail.mit.edu/rivest/Sexp.txt
2 replies →
XML is horrendous. Especially to parse/scrape. JSON on the over hand is a breeze.
1 reply →
I don't see why I can't use XML, JSON, MsgPack or YAML.
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.
7 replies →
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.
1 reply →
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.
Side note: AOL/Timewarner actually owns the IM patent from ICQ (http://edition.cnn.com/2002/TECH/biztech/12/19/internet.aol....)
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.
> Remember when we had ICQ, and AIM, and MSN Messenger, and Gadu-Gadu, and we were dreaming of a unified messaging system?
We'll always have SMS.
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.
SMS, the network.
> 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.
6 replies →
Not much good for talking to people on things that aren't phones.
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.
I had a unified messaging system, it was called Trillian and Adium, and it was awesome.
Then one day, random people from Gmail started to appear in my Gtalk contact list, and the whole thing became useless and creepy.