I'm hoping with the ousting of Vic Gundotra, Google will reenable XMPP federation with Hangouts...
For those unaware, for years GTalk supported using XMPP/Jabber to talk to other servers. A handle of [email protected] could speak through GTalk to someone using a different XMPP server with [email protected].
With the introduction of Hangouts, this is no longer possible. In order to talk to GTalk users, you might be using a Google account.
Now before there's too much confusion: yes, Hangouts/GTalk users can still use XMPP clients, like Pidgin or Adium, to talk to other Hangouts/GTalk users. But such users can no longer talk to people using the global federated XMPP network of servers that are not Google.
For years I enjoyed being able to run my own XMPP server, do some interesting things with it, and still talk to my friends and family on GTalk. Now I'm forced to use Google to maintain this.
In other words, they took a well functioning standard that was successfully decentralized, federated, and working extremely well, and deliberately neutered the decentralized aspects. Now there is the nice decentralized XMPP, and Google's XMPP, separate, distinct, broken. It's a damn shame. Gtalk federation worked great for years, and it's only been with the G+era strangulation that it's disappeared.
I don't share your hope, but oh yes. That'd be amazing. Currently it's a usability nightmare and entirely unclear who can reach you and who cannot.
As someone without Hangout or G+ people with a @gmail.com suffix might or might not be able to contact me, sometimes depending on the age of their mobile or whether they use GMail at this particular moment.
Their presence might or might not be accurate, because they are either away or use Hangout and stay 'away' forever (not offline, nooooo. They are away in G+ land..).
Using any client other than the crappy extension for Chrome, you can't do group text chats. Flamingo[0] is an amazing XMPP client for Hangouts, but is useless for work because we use group chats for everything.
Drives me crazy, and Google refuse to release an actual API for Hangouts, so it's not being fixed anytime soon. I'm trying to convince work to move to IRC or HipChat, or anything other than Hangouts (but my boss loves Google everything, so that's a losing battle).
I wish they would support open protocols too, but that just isn't Google any more. They are closing down lots of APIs besides XMPP compatibility after all.
I am confused. I use DuckDuckGo's Jabber/XMPP service (dukgo.com), and I can easily talk to Google Accounts through Bitlbee, even if they are using Pidgin, GMail's chat interface or whatever.
The only obstetrical I have encountered so far, is that it requires at least 3 or 4 tries to add a Google user. But afterwards, it's not a problem.
Edit: One of my friends using dukgo.com also confirms this behaviour.
That would be awesome, but I don't have high hopes - Google probably wants to have ability to modify protocol as they wish for new features. It seems they practically have no will to build a translation layer :/
One case I think you left out (although I may have misread what you wrote):
You can talk between GTalk and a federated XMPP server if the the GTalk user is logged in via XMPP. So if I send a message from my work XMPP server to my google address, it shows up in Adium, but not in the hangouts client.
It's almost as if Google's XMPP network is separate from hangouts, and they only allow messages directly to/from the Google XMPP to propagate between them.
For the past couple weeks I have been able to IM from inside the hangouts app to non-google XMPP users this includes the reverse, wherein I get notifications from them too.
Still wish I had an option for encryption. - certs cost money, which I (and many other people I know) CANNOT[1] afford. StartSSL won't give me a cert (they did previously, but want $$$ now).
This problem affects more people than you probably realize. Remember that 15% of the population (48 million people people)[2] in the USA are below the poverty line. The internet has already been a powerful tool, accessible in various ways even at this end of the income spectrum. Despite that, the PKI system is serving as a barrier-to-entry if you want to encrypt.
So I ask again: what is a FREE option for SSL. TCP, HTTP, DNS and most other protocols work fine once you can send packets, and do not require an extra regular fee. SSL does.
Or is the intent to have secure communication only for those that can afford it - the rest of us doomed to plaintext or rejected as "self signed" by the SSL servers of the rich and middle class? Or are we supposed to only use the internet as if it was TV, and be forced to trust our plaintext with some 3rd party?
sigh - I suspect the answer will instead be "[-1] Don't want to be reminded of the hard issues."
[1] I realize that the idea of not having an extra $15 doesn't make sense to those of you with salaried jobs. Well, lets see you come up with that extra $15 on a tiny SSDI check. Domain (3rd level) is free. Internet is very cheap and flat-rate. An extra $15 would be some new(-ish) clothes, not a SSL cert.
> StartSSL won't give me a cert (they did previously, but want $$$ now)
Do you have reference for that? I've been using their free certs for a few things for a while and a recent renewal was free. I'll be paying for one shortly, but that is only because I want a wildcard for one of my domains in order to save some faf.
I suspect your problem is the "third level domain" thing: they would effectively need to have permission from the over of the next level up to sign a cert on your behalf for one of their names (or you would need your domain provider to take part in the validation process).
> for those that can afford it - the rest of us doomed to plaintext or rejected as "self signed"
That certainly isn't the intention of the security community, but until a method is found that allows certificates to be freely produced without the security risks involved with self-signed certs that is what we (well, those in the poverty trap) are stuck with.
How StartSSL arrange their business model seems to be one solution, your current problem above not withstanding. If the depth of your free domain is the issue then perhaps the solution lies with the domain registrant taking the cost of a wildcard certificate (~$30/yr with startssl, ~$60/yr elsewhere) and so their subscribers can use it for SSL. They would have to proxy web requests to you though (with something like nginx in a reverse proxy configuration), so it would not be a zero admin option and would cost them in extra bandwidth requirements too unless they already host your content (rather than just responding to DNS requests for content hosted elsewhere), otherwise the only way you could use the cert is for you to know the private key which breaks the assurance model completely. Perhaps you could convince a provider of third level domains that taking these steps could give them with a competitive advantage over similar providers who do not.
A self-signed certificate is free, you don't need a CA-issued certificate just to use encryption.
Most XMPP servers on the internet today are forgiving of certificates they don't trust - they will encrypt the connection and then use "dialback" to authenticate you based on DNS.
Obviously falling back to DNS is not as secure, and as mentioned in the blog post - there are people working on ways to allow people to use any certificate (including self-signed) securely.
StartSSL-issued free certificates don't work reliably for XMPP in my experience anyway - some clients insist that the CN must be set to the top-level domain name and StartSSL won't issue free certificates with that configuration. I wouldn't be surprised if some XMPP servers had the same issue too.
The best option for you currently would be to pool some money from friends/family to buy SSL cert collectively. It probably makes sense anyways to share the server instead of everyone hosting their own.
FWIW, if you get a domain with gandi.net, your first year of SSL cert is free, subsequent years are no more expensive than the domain itself. This is only for the basic single-domain cert though.
Luckily they don't require "valid" certificates at this time - trying to get all XMPP server operators to agree on a set of CA providers they all trust will be a nightmare.
A nightmare? What gives you that idea? There's free as in beer certificates from StartCom, and free as in freedom certificates from CAcert. Agreeing on those would go a long way.
Well, looks like this kills off my personal XMPP server - I don't think the software I'm using (djabberd) supports encryption for s2s connections and it's not really developed anymore. That's annoying.
Its been running for a few hours now without any obvious problem. I might have made some stupid error that makes the crypto entirely useless but considering yesterday it was all in cleartext anyway I think I can live with it ;)
It's possible to achieve quite secure group chats in XMPP, as long as you have a server that you trust (emphasis on that last part). You're probably talking about OTR though, which is quite tricky for multi-party situations.
This isn't XMPP's or OTR's fault - from a high level to have a secure multi-party discussion, every participant must individually verify every other participant. This creates a lot of overhead with large groups. What you can do instead is to delegate your trust to, say, a key member of the group - if they trust every member, so do you. This is the model that XMPP supports. Set up a server that only accepts encrypted and securely-authenticated connections (using whichever mechanism you have the most faith in) and only grant access to the room to trusted individuals.
OTR only protects the text content of your messages. It doesn't protect the metadata, or many of the other features XMPP provides from status to file transfers and voice/video calls.
[+] [-] zx2c4|11 years ago|reply
For those unaware, for years GTalk supported using XMPP/Jabber to talk to other servers. A handle of [email protected] could speak through GTalk to someone using a different XMPP server with [email protected].
With the introduction of Hangouts, this is no longer possible. In order to talk to GTalk users, you might be using a Google account.
Now before there's too much confusion: yes, Hangouts/GTalk users can still use XMPP clients, like Pidgin or Adium, to talk to other Hangouts/GTalk users. But such users can no longer talk to people using the global federated XMPP network of servers that are not Google.
For years I enjoyed being able to run my own XMPP server, do some interesting things with it, and still talk to my friends and family on GTalk. Now I'm forced to use Google to maintain this.
In other words, they took a well functioning standard that was successfully decentralized, federated, and working extremely well, and deliberately neutered the decentralized aspects. Now there is the nice decentralized XMPP, and Google's XMPP, separate, distinct, broken. It's a damn shame. Gtalk federation worked great for years, and it's only been with the G+era strangulation that it's disappeared.
[+] [-] darklajid|11 years ago|reply
As someone without Hangout or G+ people with a @gmail.com suffix might or might not be able to contact me, sometimes depending on the age of their mobile or whether they use GMail at this particular moment.
Their presence might or might not be accurate, because they are either away or use Hangout and stay 'away' forever (not offline, nooooo. They are away in G+ land..).
I hope you are right and I'm wrong.
[+] [-] girvo|11 years ago|reply
Using any client other than the crappy extension for Chrome, you can't do group text chats. Flamingo[0] is an amazing XMPP client for Hangouts, but is useless for work because we use group chats for everything.
Drives me crazy, and Google refuse to release an actual API for Hangouts, so it's not being fixed anytime soon. I'm trying to convince work to move to IRC or HipChat, or anything other than Hangouts (but my boss loves Google everything, so that's a losing battle).
[0] http://flamingo.im
[+] [-] lnanek2|11 years ago|reply
[+] [-] Svip|11 years ago|reply
The only obstetrical I have encountered so far, is that it requires at least 3 or 4 tries to add a Google user. But afterwards, it's not a problem.
Edit: One of my friends using dukgo.com also confirms this behaviour.
[+] [-] pjc50|11 years ago|reply
[+] [-] grinich|11 years ago|reply
[+] [-] shmerl|11 years ago|reply
[+] [-] izacus|11 years ago|reply
[+] [-] dunham|11 years ago|reply
You can talk between GTalk and a federated XMPP server if the the GTalk user is logged in via XMPP. So if I send a message from my work XMPP server to my google address, it shows up in Adium, but not in the hangouts client.
It's almost as if Google's XMPP network is separate from hangouts, and they only allow messages directly to/from the Google XMPP to propagate between them.
[+] [-] Aloha|11 years ago|reply
[+] [-] higherpurpose|11 years ago|reply
[deleted]
[+] [-] pdkl95|11 years ago|reply
This problem affects more people than you probably realize. Remember that 15% of the population (48 million people people)[2] in the USA are below the poverty line. The internet has already been a powerful tool, accessible in various ways even at this end of the income spectrum. Despite that, the PKI system is serving as a barrier-to-entry if you want to encrypt.
So I ask again: what is a FREE option for SSL. TCP, HTTP, DNS and most other protocols work fine once you can send packets, and do not require an extra regular fee. SSL does.
Or is the intent to have secure communication only for those that can afford it - the rest of us doomed to plaintext or rejected as "self signed" by the SSL servers of the rich and middle class? Or are we supposed to only use the internet as if it was TV, and be forced to trust our plaintext with some 3rd party?
sigh - I suspect the answer will instead be "[-1] Don't want to be reminded of the hard issues."
[1] I realize that the idea of not having an extra $15 doesn't make sense to those of you with salaried jobs. Well, lets see you come up with that extra $15 on a tiny SSDI check. Domain (3rd level) is free. Internet is very cheap and flat-rate. An extra $15 would be some new(-ish) clothes, not a SSL cert.
[2] https://www.census.gov/hhes/www/poverty/about/overview/
[+] [-] dspillett|11 years ago|reply
Do you have reference for that? I've been using their free certs for a few things for a while and a recent renewal was free. I'll be paying for one shortly, but that is only because I want a wildcard for one of my domains in order to save some faf.
I suspect your problem is the "third level domain" thing: they would effectively need to have permission from the over of the next level up to sign a cert on your behalf for one of their names (or you would need your domain provider to take part in the validation process).
> for those that can afford it - the rest of us doomed to plaintext or rejected as "self signed"
That certainly isn't the intention of the security community, but until a method is found that allows certificates to be freely produced without the security risks involved with self-signed certs that is what we (well, those in the poverty trap) are stuck with.
How StartSSL arrange their business model seems to be one solution, your current problem above not withstanding. If the depth of your free domain is the issue then perhaps the solution lies with the domain registrant taking the cost of a wildcard certificate (~$30/yr with startssl, ~$60/yr elsewhere) and so their subscribers can use it for SSL. They would have to proxy web requests to you though (with something like nginx in a reverse proxy configuration), so it would not be a zero admin option and would cost them in extra bandwidth requirements too unless they already host your content (rather than just responding to DNS requests for content hosted elsewhere), otherwise the only way you could use the cert is for you to know the private key which breaks the assurance model completely. Perhaps you could convince a provider of third level domains that taking these steps could give them with a competitive advantage over similar providers who do not.
[+] [-] MattJ100|11 years ago|reply
Most XMPP servers on the internet today are forgiving of certificates they don't trust - they will encrypt the connection and then use "dialback" to authenticate you based on DNS.
Obviously falling back to DNS is not as secure, and as mentioned in the blog post - there are people working on ways to allow people to use any certificate (including self-signed) securely.
[+] [-] th0br0|11 years ago|reply
[+] [-] makomk|11 years ago|reply
[+] [-] zokier|11 years ago|reply
[+] [-] scrollaway|11 years ago|reply
[+] [-] ibotty|11 years ago|reply
[+] [-] pgeorgi|11 years ago|reply
[+] [-] andreasvc|11 years ago|reply
[+] [-] imaginator|11 years ago|reply
[+] [-] makomk|11 years ago|reply
[+] [-] robn_fastmail|11 years ago|reply
https://github.com/fastmail/DJabberd/commit/144c4431f36e5ea3...
Its been running for a few hours now without any obvious problem. I might have made some stupid error that makes the crypto entirely useless but considering yesterday it was all in cleartext anyway I think I can live with it ;)
[+] [-] Zash|11 years ago|reply
[+] [-] shmerl|11 years ago|reply
ZRTP however is still stalled: https://bugs.freedesktop.org/show_bug.cgi?id=29904
[+] [-] X4|11 years ago|reply
--
[1] http://about.psyc.eu/Jabber#Technical_Issues_in_Jabber
[2] https://news.ycombinator.com/item?id=2069810
[+] [-] wesley|11 years ago|reply
[+] [-] MattJ100|11 years ago|reply
This isn't XMPP's or OTR's fault - from a high level to have a secure multi-party discussion, every participant must individually verify every other participant. This creates a lot of overhead with large groups. What you can do instead is to delegate your trust to, say, a key member of the group - if they trust every member, so do you. This is the model that XMPP supports. Set up a server that only accepts encrypted and securely-authenticated connections (using whichever mechanism you have the most faith in) and only grant access to the room to trusted individuals.
[+] [-] daveid|11 years ago|reply
[+] [-] pgeorgi|11 years ago|reply
[+] [-] ultramancool|11 years ago|reply
Use a real end-to-end solution to this problem: OTR.
[+] [-] MattJ100|11 years ago|reply
[+] [-] ape4|11 years ago|reply
[+] [-] claudius|11 years ago|reply
What potential gain could possibly justify breaking the entire protocol and extension-ecosystem?
[+] [-] shmerl|11 years ago|reply