Nemeth: How Google pulled the plug on the public Jabber Network [LWN.net]

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 6:55 UTC (Sat) by maxiaojun (guest, #91482) [Link] (46 responses)

Regardless of some unconfirmed criticism over XMPP protocol itself, I see no XMPP clients offering user experience remotely close to proprietary alternatives (alphabetical order):
LINE -- http://line.naver.jp/en/
QQ -- http://www.imqq.com/
Skype -- http://www.skype.com/en/
WeChat -- http://www.wechat.com/en/
WhatsApp -- http://www.whatsapp.com/

XMPP can be geeks' great toy, though.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 9:13 UTC (Sat) by wertigon (guest, #42963) [Link] (18 responses)

This is unfortunately XMPP-IM (aka Jabber) biggest flaw.

XMPP in and of itself is great. Most IM systems have switched over to it, and there are only two main competitors that aren't XMPP-based today; Skype and QQ.

It is entirerly possible to build a great IM-client with XMPP that is both easy to use and has most if not all of the functionality to rival the rest. The problem is mainly when you need to set up a Jingle* channel, which requires manually finding a STUN/TURN server (or a VPN). Until someone invents auto-discovery of those, and such a mechanism is widely deployed on servers, XMPP will remain a geeks toy, unfortunately. :(

Another big problem is that there is no decent way to have a three-way Jingle conversation. I'm personally convinced that the way forward here is to develop a protocol which builds on the Multi User Chat protocol, having the signalling done in MUC but the actual streams go between the clients.

One third problem is that the internet is moving away from IM - in a way, Facebook is the successor of ICQ. Today, text messages aren't important, Social networks are. Today I know many people doing all their IM needs on Facebook and FB alone, since "everyone else is on it". There, atleast, I'm expecting great things to come from <a href="http://buddycloud.com/">BuddyCloud</a> in a few years...

However, should BC fail, then XMPP dies with it, I'm afraid. In that respect Nemeth is correct; Google opting to remove S2S more or less killed XMPP-IM, and that makes me a bit sad... :/

Oh well. I'm still hoping for a positive future, but no longer holding my breath for it, like I used to.

*Jingle is XMPPs bidirectional P2P data streams, enabling fancy stuff such as voice, video, speedy file transfers and similar

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 13:56 UTC (Sat) by HelloWorld (guest, #56129) [Link] (16 responses)

> The problem is mainly when you need to set up a Jingle* channel, which requires manually finding a STUN/TURN server (or a VPN). Until someone invents auto-discovery of those, and such a mechanism is widely deployed on servers, XMPP will remain a geeks toy, unfortunately. :(
Isn't that what DNS SRV records are for? For example, "dig SRV _stun._udp.jabber.org" will yield a STUN server.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 23:44 UTC (Sat) by wertigon (guest, #42963) [Link] (1 responses)

It's possible that I'm just behind on that, I'm not an XMPP developer or anything, merely an "informed user"... But I'm reporting from what I've seen on the client perspective, and there, it seems to me that Jingle still won't work out of the box. Might just be me though.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 5, 2013 18:37 UTC (Fri) by The_Barbarian (guest, #48152) [Link]

Works fine with Jitsi, in my (limited) experience

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 7:41 UTC (Sun) by drag (guest, #31333) [Link] (13 responses)

Applications must support the SRV records. I doubt most technical people/programmers are aware that such things even exist or how to use them.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 9:11 UTC (Mon) by dps (guest, #5725) [Link] (12 responses)

I know what SRV records do and definitely don't want to put them in public DNS information. Telling you exactly which hosts provide which services on which ports, so you know exactly how to attack my network, is a really *bad* idea. Trusting SRV records to be a guide to honest servers, despite the inherent unreliability of DNS, is an even worse idea only implemented by M$.

At least some versions of IM where never implemented: RFC 821 supports sending in addition to mailing and supporting both is mandatory. I don't think any SMTP server ever supported sending or the associated commands. RFC 2821 only supports mailing.

I have to admit to never finding either instant messaging or social networking compelling, period. Quite a few people apparently like it.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 10:24 UTC (Mon) by Corkscrew (guest, #65853) [Link] (1 responses)

Try spending six months on an unusually boring client contract, in a team of one, many miles from the nearest major population centre. Add to this that everyone in the company and/or living nearby is:
a) at least ten years older than you and
b) totally uninterested in anything but football, celebrity gossip, and their favourite psychic.

Trust me, you'll soon see the value of IM and social networking.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 20:54 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Eh, not everyone wants to be social with their fellow humans, some people are just misanthropic by nature <grr> 8-)

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 20:53 UTC (Mon) by raven667 (subscriber, #5198) [Link] (7 responses)

> Telling you exactly which hosts provide which services on which ports, so you know exactly how to attack my network, is a really *bad* idea

... w h a t ? ... <quizzical head-tilt>

How exactly to you propose to connect to services, if they don't listen on the network or if people don't know how to find them? Your mail server has MX records that point to it, your web server uses the well-known hostname of www. If you are worried about the "bad guys" finding your publicly available services you should be aware that all IPv4 address space is being constantly scanned by malware several times daily everywhere in the world all the time.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 21:08 UTC (Mon) by dark (guest, #8483) [Link] (6 responses)

Not all the address space, just the IP numbers. They don't try all the ports. I know this because I moved my sshd to a non-default port and they stopped knocking.

I don't need a record to point at it because everyone who needs to use it knows the port :)

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 21:48 UTC (Mon) by raven667 (subscriber, #5198) [Link] (4 responses)

That will keep the really unsophisticated automation from causing login-denied messages but anything using NMAP to check all the ports will still find it.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 9, 2013 19:07 UTC (Tue) by pj (subscriber, #4506) [Link] (3 responses)

To be fair, this is a "you don't have to outrun the bear" kind of situation, so changing ports is fine against random attackers. Targeted attacks are a different story.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 9, 2013 21:10 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

I've seen attacks on non-default SSH ports. Many attackers now first try to portscan for SSH and only then start attacking.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 10, 2013 12:22 UTC (Wed) by gioele (subscriber, #61675) [Link] (1 responses)

I my personal experience the number of attacks to SSH on a non-standard port is two orders of magnitude smaller than the number of attacks on port 22.

But I agree that the attacks that are able to find SSH daemons waiting on non-standard ports are also more sophisticated than the common ones.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 10, 2013 12:36 UTC (Wed) by pizza (subscriber, #46) [Link]

I just take care of two birds with one stone and use an IDS (eg denyhosts or fail2ban) that automatically bans hosts that repeatedly fail login attempts.

Granted that won't handle a truly distributed ssh breakin attempt, but if someone is specifically targetting my systems with an attack of that sophistication, I have bigger problems to worry about.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 13:44 UTC (Tue) by njwhite (guest, #51848) [Link]

It is really amazing how much of a difference this makes. I'm all for not relying on security by obscurity, but it's shocking how naive most of the SSH bruteforce scripts seem to be (mind you, they still got into my first Linux box many moons ago, before I truly appreciated that having a username/password pair that were the same common english name was a really bad idea).

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 23:17 UTC (Mon) by pizza (subscriber, #46) [Link]

>I know what SRV records do and definitely don't want to put them in public DNS information. Telling you exactly which hosts provide which services on which ports, so you know exactly how to attack my network, is a really *bad* idea. Trusting SRV records to be a guide to honest servers, despite the inherent unreliability of DNS, is an even worse idea only implemented by M$.

Um, no.

SRV records are a generic replacement for the mail-specific MX entries and the need to use predefined, fixed ports for a given service.

In other words, the raison d'etre of SRV records is to inform interested parties that a given public service for a given domain is running on a given host and a given port.

So if you don't want operate a public service (or as you call it, "an attack vector") then don't run a public service.

Meanwhile, if you don't trust DNS to return an accurate SRV record, then I hope you have something else in mind to return the A record as well. If someone has the capability to redirect one DNS entry in your domain, they can do it for any. (Have you deployed DNSSEC yet?)

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 5, 2013 18:45 UTC (Fri) by The_Barbarian (guest, #48152) [Link]

You trust DNS to be an honest guide to servers every day, for at least web, dns and mx lookups. Likely others as well. And hiding that kind of info is the poorest kind of security through obscurity.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 10:47 UTC (Mon) by sorpigal (subscriber, #36106) [Link]

> Today I know many people doing all their IM needs on Facebook and FB alone, since "everyone else is on it".
Everything old is new again; that used to be the excuse for using AOL and AIM. If I've learned anything it's that this wheel will turn again.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 10:47 UTC (Sat) by wertigon (guest, #42963) [Link] (18 responses)

Also FTR, while the IM clients you mention are surely great in their own respect, WeChat, QQ and Skype are the only ones offering Voice/Video - the others only offer voice and video messages (e.g. MMS), and therefore not in direct competition to the other three. Nitpicking, I know, just want to point out that commercial offerings also do take shortcuts. :)

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 11:46 UTC (Sat) by maxiaojun (guest, #91482) [Link] (17 responses)

Maybe I should state clear what do I mean by user experience.

When Gtalk is still considered as XMPP supporter, I performed some experiments between Gtalk accounts.

I find that interoperability between Adium, Empathy, Gtalk Windows client and Pidgin is kind of poor. File transfer and A/V calls just don't work between certain pairs. I forgot the exact result though.

I'd point out that Pidgin is not an all-OS solution given its lack of OSX binary and Pidgin on Windows doesn't support A/V calls. Adium doesn't have as many features as Pidgin also.

The real all-OS solution I found was Jitsi, even though it may be impossible to ask all users to switch to Jitsi.

The good part of QQ is its sophisticated support to custom smiley and group chatting. QQ also have handy built-in screenshot feature, which allows a quite convenient workflow in some cases.

For XMPP. Custom smiley is supported primitively between Pidgin clients. Group chatting is possible using some XMPP bots, but it is as user friendly as IRC. Pidgin also have a dead plugin which allows a similar screenshot workflow, https://code.google.com/p/pidgin-sendscreenshot/ But it requires the user to upload her screenshot to some public imagebin.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 13:05 UTC (Sat) by tao (subscriber, #17563) [Link] (2 responses)

"I find that interoperability between Adium, Empathy, Gtalk Windows client and Pidgin is kind of poor. File transfer and A/V calls just don't work between certain pairs. I forgot the exact result though."

True, it's sometimes a bit poor. OTOH the interoperability between QQ, Skype, Whatsapp, etc. is completely non-existent, so...

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 14:28 UTC (Sat) by maxiaojun (guest, #91482) [Link] (1 responses)

But QQ and Skype do provide decent client software across multiple platforms except Linux.

If you count XMPP clients on the mobile platforms then I guess the situation would be almost the same, only plain text is truly reliable.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 23:51 UTC (Sat) by wertigon (guest, #42963) [Link]

except Linux

And therein lie the rub - many LWN readers happen to be Linux Desktop users, so if it doesn't exist on Linux, it may as well not exist at all. I do agree many of these services have managed to create a seamless experience however, and there XMPP-clients would do well to learn from...

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 11:37 UTC (Sun) by krake (guest, #55996) [Link] (12 responses)

"When Gtalk is still considered as XMPP supporter, I performed some experiments between Gtalk accounts.

I find that interoperability between Adium, Empathy, Gtalk Windows client and Pidgin is kind of poor. File transfer and A/V calls just don't work between certain pairs. I forgot the exact result though."

While this is an interesting experiement, I am unsure on what it would demonstrate as it seems to test things not available (to my knowledge) in any other solution.

Did you also conduct the experiment with different clients on any of the other networks? E.g. using clients of different vendors on the Skype network or different clients with Google Hangout?

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 13:34 UTC (Sun) by maxiaojun (guest, #91482) [Link] (11 responses)

What I want is a working IM solution (more than just text) across Linux, Mac OS X and Windows, given the fact that some proprietary alternatives already working well across Mac OS X and Windows.

I understand XMPP's big dream. But in reality, XMPP network is closed ecosystem by its own. (Some niche proprietary IM may integrate Facebook and/or Gtalk through XMPP) And the ecosystem is further divided by not-100%-compatible clients.

Yes, I discovered a good client Jitsi. But asking every buddy to use Jitsi is both unpractical and against the point of XMPP.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 15:31 UTC (Sun) by krake (guest, #55996) [Link] (10 responses)

"What I want is a working IM solution (more than just text) across Linux, Mac OS X and Windows, given the fact that some proprietary alternatives already working well across Mac OS X and Windows."

Ok, but then the previous comment does make even less sense. It was about testing interoperability between client solutions of different vendors on the same server.

And in that context I would be surprised to find any solution, proprietary or otherwise, which comes even close to that.

So in this new context, single vendor solution across platforms, your finding where that GTalk clients of different platforms did not work well together? Do you think it more a weakness in the vendor's client or server implementation?

"Yes, I discovered a good client Jitsi. But asking every buddy to use Jitsi is both unpractical and against the point of XMPP. "

How is having the same client of vendor A different than all parties all having the client of vendor B?

Wouldn't it client of vendor A which can at least interoperate wit h vendor C's client on text level be better than vendor B's client which cannot?

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 17:14 UTC (Sun) by maxiaojun (guest, #91482) [Link] (9 responses)

> So in this new context, single vendor solution across platforms, your finding where that GTalk clients of different platforms did not work well together?

Let's consider Gtalk as a vendor of an IM solution.

In old Gtalk page, users get the download of unmaintained official Windows client and a bunch of XMPP clients listed.

But the clients' interoperability is text level, some doesn't support A/V calls at all.

In particular, I'm not aware of any clients working across big-three-OS (support file transfer and A/V calls) except Jitsi.

If consider xmpp.org as a vendor then the situation is similar: http://xmpp.org/xmpp-software/clients/

Maybe we can also consider Jitsi as a vendor, then it works pretty nice but unfortunately the ecosystem is too small.

> Do you think it more a weakness in the vendor's client or server implementation?

I see no public vendors of XMPP offering a single, multi-platform, beyond text, client unless you count Jitsi.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 21:24 UTC (Sun) by raven667 (subscriber, #5198) [Link] (2 responses)

Why do you need to use the same client, each OS or desktop can and does provide its own native client. I agree that only a few clients support video to any degree but why is that? Is it that text chat solves 90% of the problem for most people so there just isn't enough pressure to implement video chat or other advanced features? Are these kind of features difficult to implement across different OS environments, are the tools not there to make this work, for example a lack of standard royalty-free codecs, similar to the HTML5 video situation?

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 0:12 UTC (Mon) by Kit (guest, #55925) [Link]

Because voice/video are far harder than text. Text is absurdly easy to do, while V&V both are very latency sensitive and require a large amount of bandwidth, in addition to needing to integrate with a large variety of low quality hardware (webcams for video). In addition, you also have to defeat NAT firewalls if you want it to be usable for the average user... since the more technical users could reconfigure their router by hand, often it's just left as an exercise to the user.

With the rise of Skype several years ago, I think it's very safe to say that voice/video calls are by no means a niche in the mainstream.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 1:54 UTC (Mon) by maxiaojun (guest, #91482) [Link]

Is it that CLI solves 90% of the problem for most people so there just isn't enough pressure to implement GUI or other advanced features? Are these kind of features difficult to implement across different OS environments, are the tools not there to make this work, for example a lack of standard cross-platform GUI toolkits, similar to the HTML5 video situation?

For QQ, in particular, users use images extensively in addition to text. Check:
http://comic.qq.com/z/qqface/
http://im.qq.com/face2/

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 18:00 UTC (Mon) by krake (guest, #55996) [Link] (5 responses)

"In old Gtalk page, users get the download of unmaintained official Windows client and a bunch of XMPP clients listed."

So they failed as a client provider and now they want people to switch to a system where they are the only client provider. Oh dear!

"Maybe we can also consider Jitsi as a vendor, then it works pretty nice but unfortunately the ecosystem is too small."

What do you mean with ecosystem here? Services or products sold with or in addition to the IM service?

"I see no public vendors of XMPP offering a single, multi-platform, beyond text, client unless you count Jitsi."

What do you mean with "unless"? My understanding from the rest of your comment is that it provides a multi platform solution and, additionally, also provides interoperability with clients of other vendors at least for text chat and even other servers.

I have yet to see any other system as capable as that.

For example I heard that Google Hangout even fails to interoperate with their own GTalk client on their own servers, not even talking about other vendors' clients or server. Reminds me of the Wave disaster: all the features in the world are not going to help you if your users can not reach the people they are used to be in contact with

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 18:18 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

>For example I heard that Google Hangout even fails to interoperate with their own GTalk client on their own servers, not even talking about other vendors' clients or server. Reminds me of the Wave disaster: all the features in the world are not going to help you if your users can not reach the people they are used to be in contact with

I wish this was just "something you heard" -- Google has two mutually incompatible IM solutions that share the same address/namespace. and there's no way of knowing which side of the wall the person you want to contact is on, because it's based on which client they happened to use to sign in with.

Users of Google Apps within the same organization may suddenly find themselves unable to communicate with each other because some users on android switched to Hangouts, but the GApps admin left things set to Talk for the web users.

If this sounds absolutely ludicrous, it's because it is.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 23:51 UTC (Tue) by beagnach (guest, #32987) [Link]

so this is actually real? Damn.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 3, 2013 5:16 UTC (Wed) by bjencks (subscriber, #80303) [Link]

Odd, I just switched to new-Hangouts and I'm still talking to users without either new-Hangouts or G+. I can't talk to external XMPP servers, but I didn't have any contacts like that. As has been alluded to, I can still use an XMPP client to connect to Google.

Pretty sure it's text-only, but it's been pretty hard to get to GTalk's jingle-based video calls for a while. (This is on an apps domain).

I've considered running my own XMPP server, but (a) the integration between email/calendar/chat/everything else is too useful, so I'd have to migrate everything off, and (b) there wouldn't be anyone to talk to now that Google's turning off federation.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 19:36 UTC (Mon) by khim (subscriber, #9252) [Link]

What do you mean with ecosystem here? Services or products sold with or in addition to the IM service?

I think the sheer number of users is the most important metric. Metcalfe's law is just a rough approximation (when your network is too big some potential connections are not worth all that much), but it's still a good approximation.

Bigger networks can be displaced (hey, people switched from AIM and MSN Messenger to Skype and from BBM to WhatsApp, right?), but this is not an easy to do and I don't see when and how Jitsi will get it's billion of users.

For example I heard that Google Hangout even fails to interoperate with their own GTalk client on their own servers, not even talking about other vendors' clients or server.

Well, yeah, Google Hangout is pretty poor IM network right now (exactly because they decided to shoot not for the perfect interoperability with GTalk and other XMPP servers but for different things instead) but I can imagine the future where it'll take hold and will get this billion of users. I could not imagine such fate for the Jitsi-based network (a lot of vendors use XMPP for their own solutions but it does not help all that much if they also use proprietary undocumented extensions which are actively used by users of their networks).

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 5:03 UTC (Tue) by maxiaojun (guest, #91482) [Link]

I have no intention defend Google's current decision. I just state the facts about Gtalk in old days.

> My understanding from the rest of your comment is that it provides a multi platform solution and, additionally, also provides interoperability with clients of other vendors at least for text chat and even other servers.

Multi-platform solution is much more important. Proprietary alternatives are quite successful on this side except they do not bother supporting Linux desktop well ( but how many people really care? isn't some Linux guy argue that text is enough? ).

For interoperability, again, who cares? In China, everyone is on QQ, and some business leaves QQ number as contact but provides no Email address. For Skype, even if it is not that popular, I see nothing stop people from getting a Skype account when they need to. In university, for example, people use Skype to perform remote interview. The niche between E-mail and multipurpose IM isn't that interesting.

BTW, to run Gtalk and Hangouts at the same time, I open Gmail without Hangouts enabled and Google+, then I get both. Again, I have no intention defend Google.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 5, 2013 18:49 UTC (Fri) by The_Barbarian (guest, #48152) [Link]

>The good part of QQ is its sophisticated support to custom smiley

Awesome. Glad we have that.

Jitsi

Posted Jun 29, 2013 11:42 UTC (Sat) by fmyhr (subscriber, #14803) [Link] (1 responses)

https://jitsi.org/Main/Features

Viable XMPP alternative?
(So far I've only toyed around with its SIP capabilities.)

Jitsi

Posted Jun 29, 2013 11:48 UTC (Sat) by maxiaojun (guest, #91482) [Link]

Yes, Jitsi is a good one. I also discovered it (see my above comment).

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 15:07 UTC (Sat) by Zack (guest, #37335) [Link] (2 responses)

I'm fairly sure those proprietary alternatives can pay for and manage their own advertising. Thanks.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 16:36 UTC (Sat) by maxiaojun (guest, #91482) [Link] (1 responses)

I honestly didn't get what you are trying to say.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 14:29 UTC (Mon) by Lukehasnoname (guest, #65152) [Link]

He's rejecting the idea that one should discuss the merits of closed source technologies, or conversely, to lament the shortcomings of OSS.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 7:26 UTC (Sun) by Seegras (guest, #20463) [Link] (2 responses)

Regardless of some unconfirmed criticism over XMPP protocol itself, I see no proprietary alternative offering security remotely close to XMPP, namely:
- open source server and client
- distributed, run your own server
- enforce encrypted connections
- OTR

LINE, QQ, Skype, WeChat, WhatsApp can be home users great toy, tough. For everything that is the slightest bit confidential, these are unusable.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 8:00 UTC (Sun) by maxiaojun (guest, #91482) [Link] (1 responses)

Interesting response.

> - open source server and client

As I mentioned, at the clients do not work that well. And for security concern, I don't think Firefox is much safer than Opera.

On the server side, well, open source or not doesn't make any visible difference for users.

> - distributed, run your own server
> - enforce encrypted connections
> - OTR

You should be right. I did not deny XMPP as a good potential protocol for site deployment or small-scale use.

If home users have strong security concerns, should they really trust http://www.jabber.org/ more than the proprietary vendors? Is there a scheme which can ensure users' security even if the server is compromised?

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 11:13 UTC (Sun) by krake (guest, #55996) [Link]

I think the main advantage is that you as a group can decide which level of protection you would like to have.

As a company you can run your own Jabber server, allow logins only through VPN, etc.

As an interest group, e.g. a union or political party, you could run your own server and allow only SSL secured logins, etc.

People belonging to multiple such groups can most likely use the same interface/client across all those offerings, e.g. allowing for global presence/status, etc.,instead of having to toggle those in several places manually.

Very Simplistic view that buys into Google's "Reasons"

Posted Jun 29, 2013 12:02 UTC (Sat) by pizza (subscriber, #46) [Link] (4 responses)

Google's public reasons for saying XMPP was "insufficient" are pretty flimsy, given inherently extensible (ie the 'X' in XMPP') nature of the protocol.

If Google wanted to add anti-spam features? Propose an extension. Improve Video/Voice? propose an extenstion. Or perhaps, improve the extenstion they already proposed and implemented!

Andreas Proschofsky summarized this pretty effectively:

https://plus.google.com/+AndreasProschofsky/posts/cs4BnDF...

Very Simplistic view that buys into Google's "Reasons"

Posted Jun 29, 2013 12:19 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

About 4 years ago I looked at XMPP audio and video support. It was a total unholy mess - lots of clients that can't interoperate with each other.

And the main XMPP protocol is also not that good. For instance, true HTTP tunneling only became available about 5 years ago. The system with associations is also a bit cumbersome to use.

Very Simplistic view that buys into Google's "Reasons"

Posted Jun 29, 2013 13:14 UTC (Sat) by pizza (subscriber, #46) [Link] (2 responses)

>About 4 years ago I looked at XMPP audio and video support. It was a total unholy mess - lots of clients that can't interoperate with each other.

A good part of that "unholy mess" is due to the inherent nature of audio+video (and the joys of dealing with end-user NAT), but the article I linked specifically mentioned how Google didn't actually adhere to the standards they helped create, further exacerbating that "unholy mess".

But going back to the original point -- the 'X' in XMPP means 'eXtensible'. Something is insufficiently defined? Define it more clearly via the XEP. Need to do something new? Again, XEP.

Very Simplistic view that buys into Google's "Reasons"

Posted Jun 29, 2013 19:39 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

There are tons of XEP that were never implemented properly. I believe that Google really tried to work with the community on XMPP - they've release Jingle, for example.

But it turns out that community itself was not really interested in XMPP.

Very Simplistic view that buys into Google's "Reasons"

Posted Jul 1, 2013 18:32 UTC (Mon) by pizza (subscriber, #46) [Link]

> There are tons of XEP that were never implemented properly. I believe that Google really tried to work with the community on XMPP - they've release Jingle, for example.

Actually, you have it backwards. Google submitted Jingle for standardization, but never actually implemented the standardized version.

"The Community" did a great job with XMPP, but they can't do much when the 800lb gorilla in the room doesn't participate.

Considering that Google is (was?) the single largest XMPP operator (probably larger than everyone else combined) their "community outreach" was pretty abysmal.

In some ways, Google getting out of the XMPP game is actually an improvement since "the community" can now ignore the nonstandard stuff Google is up to.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 13:46 UTC (Sat) by ledow (guest, #11753) [Link] (8 responses)

I waited years for an open-source client to support decent video/audio live comms with someone else, no matter the OS in use.

It doesn't sound that heard but it must be, Pidgin has supported MSN for years but still no sight of video over it using Pidgin. XMPP was designed with this sort of thing in mind and Google Talk managed to work all sorts of wonders - never really got it to work once you put an open-source client into the mix.

I never really got why this is. I mean, even if it was just an open-source client and you had to use JUST that client with all your friends, I spent years looking and couldn't find anything as simple and as reliable as Skype became. That was kind of grating for an open-source enthusiast.

It was also of the FSF's top-ten needed apps or something, wasn't it? What's happened to it?

All I want to do is send a video/audio stream to someone, and see their video/audio stream back. I can't believe that with something like VLC and FFMPEG it could really be that difficult. I don't want to have to set up a server, I want it to work cross-platform and - if possible - I don't want to open network ports etc. so a P2P network to organise the initial connection would be great. (Middle-man server? Sure... I'll set up my own, just let me configure it and use it and DON'T relay every byte of video through it because that's an instant bottleneck).

But then, when I tried to get VLC to record a Windows desktop and stream it to the local network as a stream compatible with its own client, I spent two hours on the CLI, after an hour on the GUI, and still never managed to get it to work. I know it's *possible* but there were just far too many options in the way and half of them just made VLC do nothing or even crash. I'm not even sure how people can TEST that part of VLC at all.

It's one of those tasks that various projects take up and then you don't hear from them for ten years, and then the project dies. And although they get all the parts together, they never seem to actually make it work. Pidgin has been waiting for a video client to work for Windows for how long now? Yet the MSN streams etc. have been documented since the days of Windows 98.

XMPP was just another casualty of the same problem. Set up the text messaging, prove that video / file transfer "could work", and then die a death through not having a complete or portable implementation in OS code anywhere so people are stuck on proprietary services and then - well, what's the point of hacking on the OS version when it'll take years to get working properly?

By the time we get it, we'll have moved onto the next technology. I can honestly remember wanting this from Trillian also back in... what... 2000? God, that's a long time to wait in software.

Is it a case of standards over functionality again? Because, honestly, I'd rather have a horrible mess of a protocol that works in this area, without needing to suffer all the numerous trials of software and various network settings to make them work that I have had to.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 14:33 UTC (Sat) by maxiaojun (guest, #91482) [Link] (3 responses)

Have you checked Jitsi?
https://jitsi.org/

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 9:17 UTC (Mon) by Quazatron (guest, #4368) [Link] (2 responses)

I'm sure I'm not the only one that instinctively avoids applications that start with a 'J'.

I know that Java is very fast nowadays, but I still remember the bad old days when you had to wait for the JVM to slowly crawl its way into memory, kicking all the other programs to swap.

Modern machines are much faster, and have larger memories, but guess that kind of continued pain can still trigger a Pavlovian response.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 10:32 UTC (Mon) by maxiaojun (guest, #91482) [Link] (1 responses)

I don't like Java-based desktop applications either; for various reasons.

But I'm not aware of any other XMPP client that:

1. Works consistently on all big-three OS
2. Supports A/V calls
3. Supports file transfer

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 12:36 UTC (Mon) by njwhite (guest, #51848) [Link]

You can add SRTP/ZRTP call encryption as well.

I too instinctively avoid Java applications, but it does seem like Jitsi works very well in a space where nothing else does.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 29, 2013 17:26 UTC (Sat) by danielbaumann (subscriber, #38804) [Link] (2 responses)

I haven't looked into it but I suppose WebRTC is considered the cross-plattform IM future for text, audio/video, and maybe even sharing files at some point.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 9:13 UTC (Sun) by justincormack (subscriber, #70439) [Link]

Yes thats true. File sharing is in development already https://webrtc-experiment.appspot.com/docs/how-file-broad...

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 19:18 UTC (Mon) by clopez (guest, #66009) [Link]

For file sharing, check http://filetea.me you only need a modern browser

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 5, 2013 19:02 UTC (Fri) by The_Barbarian (guest, #48152) [Link]

>It was also of the FSF's top-ten needed apps or something, wasn't it? What's happened to it?

The FSF High Priority list means jack. They themselves don't seem to actually put any heavy effort or backing into any of them, and no one else does either.

Open alternatives to XMPP?

Posted Jun 29, 2013 14:59 UTC (Sat) by tau (subscriber, #79651) [Link] (3 responses)

Has there ever been any serious examination of, say, SIMPLE as an alternative open IM protocol, instead of defaulting to XMPP? Or is SIMPLE a design-by-committee boondoggle created in the interests of placing a "standards-compliant" bullet point on VoIP equipment marketing glossies?

Honestly I've never been a great fan of XMPP. Its entire design just smells wrong. It's not a presence system or an IM system, it's an "XML message switch", which just screams architecture astronauts to me, and it was created at the peak of the industry's drunken XML-everywhere frenzy. Human-to-human and computer-to-computer realtime messaging share some superficial similarities, but not enough that lumping them into some universal message routing protocol is worthwhile.

There are valid technical criticisms of the protocol as well, nicely summarised in [1] [2] (cited from here). Bear in mind that an XMPP session is one big long unbroken XML document, the intent being that the peers on each end of this conversation use an event-driven XML parser connected that drives an XMPP protocol state machine. One of the biggest criticisms is that it looks somewhat like XML, but it isn't quite XML, or even a subset of XML; certain XML constructions are not valid in XMPP sessions, and an in-session switch to a compressed or encrypted transport results in an aborted XML document whose context is resumed mid-document within a different transport layer. As a result, the XML parser has to be specially adapted to accommodate XMPP's quirks, or the server has to implement its own XMPP-flavoured XML parser instead of re-using an existing one.

XML is also a lousy fit for this particular use case as well; we'll ignore the fact that most of the protocol content isn't a heterogeneous mix of text and markup, because this is true of virtually every application XML is (ab)used for. Binary content such as end-to-end encrypted messages must be base64 escaped, which adds processing and transmission overhead. There is no payload length encoding in the message headers, so the message content has to be parsed by the server, and a complete XML DOM fragment must be re-constituted and serialised out to the destination. Also, though I have no basis for making this claim, I imagine that XML namespaces must complicate all of this processing tremendously, so again, the protocol has high overheads. The fact that not a single major IM network with an external XMPP interface uses XMPP internally for server-to-server routing is also particularly telling. Nor does Google consider XMPP to be practical for mobile clients, which I think is the point where they decided that XMPP wasn't going to work as an interface to Google Talk.

XMPP, by all indications, is a fundamentally bad protocol that is over-designed and over-ambitious, and is a poor fit for the Internet today. It does not do one specific thing, and what it does attempt to do it does not do well. As a community we need to learn from its mistakes and move on, instead of trying to keep pushing this overburdened and impractical standard. Given its provenance I seriously doubt that SIMPLE is a better solution in any way, but we should probably at least look beyond XMPP to begin with.

Open alternatives to XMPP?

Posted Jun 29, 2013 16:43 UTC (Sat) by pboddie (guest, #50784) [Link] (1 responses)

Your comment brings back some unpleasant recollections of reading the XMPP specifications (yet more overly verbose pseudo-standards aiming for the lowest justifiable density of information, spread over as many documents as possible) and working out all the edge cases. It really is something that was inspired by XML rather than being genuine XML, seemingly stemming from the "cool idea" that start tags mark the start of messages and end tags mark the end of messages, meaning that what the authors really have in mind is some kind of event-oriented processing model (and not necessarily one that works nicely with event-oriented parsers, either, as you point out).

Of course, XML should offer some benefits or guide the design of such technologies. For example, having a coherent policy for encoding special characters is far better than putting special cases in obscure places (and, even worse, in connection with certain semantic constructs), but if something looks like XML then it had better be very close to XML; otherwise, the surprise at any differences undermines the familiarity with the similarities, and people start to lose trust in the illusion that has been created.

Open alternatives to XMPP?

Posted Jul 1, 2013 12:56 UTC (Mon) by pboddie (guest, #50784) [Link]

I actually remembered what the best way is of considering XMPP's XML-like syntax: it's like a "cute" way of doing remote procedure calls. So, when you see a start tag, it's like you are declaring that you are making a call, and then if any start tags appear inside the currently open element, then they may just be describing structures or they could be considered as calls of their own. Remembering that XMPP is from an era when XML-RPC and SOAP had more enthusiasm around them, this almost makes sense.

Open alternatives to XMPP?

Posted Jun 29, 2013 21:33 UTC (Sat) by wertigon (guest, #42963) [Link]

From what I gathered from the discussions way back, there were two reasons SIMPLE didn't gain traction;

1. If you wished to write something using plain-text and presence and nothing else, it was extremely complicated compared to XMPP
2. SIMPLE was backed by Microsoft, and they had back then (and still do) a reputation for making every protocol they touched - and I do mean EVERYTHING - to a convoluted mess, and then promptly remove support once the complexity made the project implode on itself (aka Embrace, Extend, Extinguish). Therefore being wary of the HTML and office formats, many developers did not wish to become trapped in yet another extinguished protocol...

XMPP does have it's warts, but like PHP and JavaScript it also has many versatile uses. There are clearly places where it's not appropriate, but most criticism directed to it are in areas that matter little - such as the infamous "XML is bloody inefficient to parse".

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 2:40 UTC (Sun) by wahern (subscriber, #37304) [Link] (23 responses)

XMPP isn't going away. And if more of us ran our own XMPP servers, then companies will have to come to us. When Microsoft and Google seriously begin competing over IM users, then they'll begin courting the XMPP network. It is, after all, why Google made GTalk interoperate with XMPP in the first place--as an easy way to differentiate themselves from AIM.

XMPP is not a very nice protocol from an engineering standpoint. At least, it's XML transport is downright evil, although I suppose I could live with _discrete_ XML messages sent over a real transport layer.

But at this point it's irrelevant, the way the warts of SMTP are irrelevant. XMPP has been around for well over 10 years, and it'll be around 10 years from now. And while XMPP is ugly, all the supposed technical limitations are, at their worst, superficial. The real issue isn't the technology, it's about about companies, developers, and administrators _choosing_ to cooperate and further interoperability, and there is no technical fix to that, although the simplest answer is... XMPP.

I run my own server, and I'm _pleading_ with other LWN users to start running your own server, too.

Your choice to not run your own messaging services will, in the end, destroy my freedom to do that. You can lease a VPS instance for the price of a few cups of coffee. And if you choose a conservative platform, such as Debian or OpenBSD, the maintenance time is slim to none.

Freedom isn't free, but it's not all that expensive, either. It just takes less talk and more walk.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 11:51 UTC (Mon) by pizza (subscriber, #46) [Link] (22 responses)

> The real issue isn't the technology, it's about about companies, developers, and administrators _choosing_ to cooperate and further interoperability, and there is no technical fix to that, although the simplest answer is... XMPP.

This is the point I was trying to make. Unfortunately, none of the big players have the political will to foster interoperation. Google was the only one (Emphasis on was) though ironically it looks like Microsoft may be the next front runner (via Lync; Skype is as closed as ever)

> I run my own server, and I'm _pleading_ with other LWN users to start running your own server, too.

I've run my own XMPP server for the better part of a decade as well. Then again, I'm one of the rare folks that self-hosts their entire online presence, which is pretty rare these days..

- Solomon

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 14:30 UTC (Mon) by maxiaojun (guest, #91482) [Link] (21 responses)

What XMPP client do you use, then?

> Then again, I'm one of the rare folks that self-hosts their entire online presence, which is pretty rare these days..

With the rise of VPS, I feel quite opposite.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 16:35 UTC (Mon) by khim (subscriber, #9252) [Link] (14 responses)

With the rise of VPS, I feel quite opposite.

What difference does it make? There are billions of the people on the internet, most of them have no idea what these three letters (VPS) mean and most will never be able to run their own servers. Which means that any solution which only works for people who are willing to use their own servers is DOA: it may work as some kind of niche solution (larger or smaller) but it'll not work as general-purpose solution no matter what.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 17:53 UTC (Mon) by niner (guest, #26151) [Link] (11 responses)

Yet those billions of people are able to pick one of the 12,773 ISPs worldwide to get their internet connection and one or many of the millions of email providers. It seems strange to assume that for IM they wouldn't be able to do that.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 18:10 UTC (Mon) by pizza (subscriber, #46) [Link] (10 responses)

> Yet those billions of people are able to pick one of the 12,773 ISPs worldwide to get their internet connection and one or many of the millions of email providers. It seems strange to assume that for IM they wouldn't be able to do that.

(For what it's worth, since the decline of dialup few people have a meaningful choice of ISPs. But I digress)

In an ideal world, they *should* be able to pick a random IM provider and have it interoperate with everyone (much like email). I don't think anyone is saying otherwise.

Meanwhile, in the real world, Now that Google has seen fit to take their toys and go home, those of us using an interoperable IM service are little more than rounding errors compared to the user count of the big boys.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 4:42 UTC (Tue) by maxiaojun (guest, #91482) [Link] (9 responses)

Even if I subscribe to many mailing lists and cannot live without Email. I still find Email sucks.

Email is interoperable to an extent that one cannot send Linux kernel patch through MSFT Exchange server. Yes, it must be MSFT's fault.

I never understand the quirks of mailing list thread handling; web forum is much more intuitive.

Email still suffers from encoding issues for languages require non-ASCII encoding.

The endless plain text VS HTML debate.

The endless spams, might not be a big problem today.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 11:46 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

> mail is interoperable to an extent that one cannot send Linux kernel patch through MSFT Exchange server. Yes, it must be MSFT's fault.

Actually, it is, because MSFT didn't follow the well-established standards relating to, oh, not mangling email that passes through their systems.

For example, just yesterday I read a knowledgebase article that how if you didn't want Exchange to sometimes (not always!) replace some (not necessarily all) tabs in an email with spaces, you had to ensure you were using Exchange 2007 Service Release 2 or newer.

How is that anything but MSFT's fault?

Meanwhile, If you think webforums are "intuititve" you should try a real usenet client sometime; nothing else comes close to keeping track of large, complex discussions. (And this very reason is why the likes of gmane run an NNTP server that aggregates mailing list traffic)

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 14:23 UTC (Tue) by maxiaojun (guest, #91482) [Link]

> How is that anything but MSFT's fault?

I know it must be MSFT's fault.

But just like Web designers have to deal with browser quirks, it may not be something Email users can simply ignore.

> Meanwhile, If you think webforums are "intuititve" you should try a real usenet client sometime;

Can you name one "real usenet client"?

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 23:31 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Anyone who thinks that Usenet is a nice thing, should try to write a Usenet client. NNTP is a PITA and it's no wonder Usenet had died at the earliest opportunity.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 4, 2013 2:30 UTC (Thu) by wahern (subscriber, #37304) [Link] (1 responses)

Unfortunately, not dead enough. People of the "usenet is dead" ilk keep visting in waves every now and then, pulling down the quality of discussion.

If anything will kill Usenet, it'll be the fact that Google destroyed Deja News. It was a slow process, but the last year or so it's become a downright maddening experience to try to search the Usenet archives.

Anyhow, if you think NNTP is bad, you should try to hack the Stack Exchange protocol...

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 4, 2013 4:18 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, I know people who still use FIDO. So Usenet will definitely continue to live for some time.

But most of its users jumped ship at the first opportunity.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 5, 2013 19:12 UTC (Fri) by The_Barbarian (guest, #48152) [Link] (3 responses)

>I never understand the quirks of mailing list thread handling; web forum is much more intuitive.

Web forums are a huge misstep. They are fundamentally inferior to email/newsgroups, and the actual implementation has completely stagnated for, what, at least a decade and a half?

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 5, 2013 19:59 UTC (Fri) by renox (guest, #23785) [Link] (2 responses)

>Web forums are a huge misstep. They are fundamentally inferior to email/newsgroups,

In almost all properties, you're right except for one killer flaw of newsgroups: spam.

>and the actual implementation has completely stagnated for, what, at least a decade and a half?

Who care about this? Email or newsgroups hasn't evolved much either..

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 5, 2013 22:22 UTC (Fri) by The_Barbarian (guest, #48152) [Link] (1 responses)

>>and the actual implementation has completely stagnated for, what, at least a decade and a half?

>Who care about this? Email or newsgroups hasn't evolved much either..

There are really easily fixable UI flaws in the majority of web forums. For example most of them look like phpBB/vBulletin, and by default have teeny tiny little back and forward arrows for navigation, along with teeny tiny little page number boxes to jump to a page. The usability could be greatly improved simply by making these elements bigger (although you could probably think more interesting and powerful changes to the navigation pretty easily as well). But in all the years they have been around they have not done this simple change. The UI was designed in the 90s and it really shows (and hurts).

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 6, 2013 12:13 UTC (Sat) by anselm (subscriber, #2796) [Link]

The problem with web forums is that usually I need to actively go to the forum to see what is new, and that every web forum has its own UI and user credentials (more or less, anyway). Tweaking an individual web forum's UI doesn't really help with this.

The nice thing about mailing lists or Usenet is that I get everything that interests me in one place and with one UI. Also it is usually possible to arrange things such that all the new stuff is downloaded in one big batch, and any answers that one writes are uploaded in one big batch, too, which helps when one is on the go with only intermittent connectivity.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 5:14 UTC (Tue) by maxiaojun (guest, #91482) [Link] (1 responses)

I see zero problem in the facts you stated; the world is always like that.

If you believe your solution is fancy, why don't you build your own large-scale network?

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 20:40 UTC (Tue) by khim (subscriber, #9252) [Link]

I see zero problem in the facts you stated

Really? You have already forgotten context, right? I mean:

I run my own server, and I'm _pleading_ with other LWN users to start running your own server, too.

Your choice to not run your own messaging services will, in the end, destroy my freedom to do that.

In a world where most users use something "big boys" are offering it's pretty pointless to try to fight the common trend by asking LWN users to start running your own server.

P.S. So much for web forum is much more intuitive.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 1, 2013 17:59 UTC (Mon) by pizza (subscriber, #46) [Link] (5 responses)

> What XMPP client do you use, then?

Psi on the (GUI) desktop, Freetalk on the command line, and Xabber on Android. All work great for what I need -- presence notification and textual communications.

For voice, I use the telephone, via PoTS (or SIP where appropriate).

For file transfers, I use HTTP or SCP/SFTP.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 4:03 UTC (Tue) by maxiaojun (guest, #91482) [Link] (4 responses)

> All work great for what I need -- presence notification and textual communications.

Don't you use a text-based Web also?

> For voice, I use the telephone, via PoTS (or SIP where appropriate).

Can you name an advantage of PoTS over Skype and/or Google Talk? Maybe, circuit switching is more reliable?

> For file transfers, I use HTTP or SCP/SFTP.

Well, I guess either you use your own server or you never behind NAT.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 11:41 UTC (Tue) by pizza (subscriber, #46) [Link] (3 responses)

>> All work great for what I need -- presence notification and textual communications.
> Don't you use a text-based Web also?

I'm sorry, I'm not sure what you're asking here. If you're referring to a "web-based IM client" than no, I don't personally use one because I have no need of one. (FWIW I try to avoid "access service X via a browser" wherever possible)

>> For voice, I use the telephone, via PoTS (or SIP where appropriate).
>Can you name an advantage of PoTS over Skype and/or Google Talk? Maybe, circuit switching is more reliable?

Aside from yes, PoTS being far more reliable, it's also the the least common denominator (ie the 'phone' in 'smartphone', and the cost is close enough to free for it to not matter (I can make calls to US numbers for $0.005 a minute, for example. Without PoTS termination it would literally be free (and self-hosted too))

>> For file transfers, I use HTTP or SCP/SFTP.
>Well, I guess either you use your own server or you never behind NAT.

Yup, I have my own public-facing server so there's never any problem reaching it. Don't get me wrong, I'm definitely paying for that privilege, but thanks to it I'm far, far less reliant on third parties for essential services.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 14:14 UTC (Tue) by maxiaojun (guest, #91482) [Link] (2 responses)

> I'm sorry, I'm not sure what you're asking here.

Images in IM chatting is as important as images in Web browsing.

> I can make calls to US numbers for $0.005 a minute, for example.

Does it involve some SIP here?

BTW, aren't US phone plans generally include unlimited text? If so SMS seems to be better than XMPP according to "least common denominator" principle.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 2, 2013 15:51 UTC (Tue) by pizza (subscriber, #46) [Link]

> Images in IM chatting is as important as images in Web browsing.

I'd disagree with that assertion, but I see "images" as a special case of "arbitrary file transfer" -- I have an HTTP server for that.

> Does it involve some SIP here?

Yep, fully open, standardized, federated SIP. (as opposed to the likes of Google Talk/Hangouts or especially Skype -- no interoperability whatsoever there!)

> BTW, aren't US phone plans generally include unlimited text? If so SMS seems to be better than XMPP according to "least common denominator" principle.

SMS doesn't give you presence notifications, which I'd consider one of the cruicial features of IM in general. Combined with SMS making no reliability guarantees at all..

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jul 3, 2013 1:11 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> BTW, aren't US phone plans generally include unlimited text?

Verizon is ~$10 for 1000 a month. Unlimited is…well I barely use enough to justify the package as I hover just around the "a la carte is cheaper line" and 1000 is the smallest they offer these days.

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 12:47 UTC (Sun) by tonyblackwell (guest, #43641) [Link] (1 responses)

What about the latest firefox?
Video support sounds interesting, (especially if peer-to-peer at some point??)

Nemeth: How Google pulled the plug on the public Jabber Network

Posted Jun 30, 2013 16:30 UTC (Sun) by shmerl (guest, #65921) [Link]

So far I didn't see practical examples of Jingle working over WebRTC. Here is one project: https://github.com/ESTOS/strophe.jingle