Live data from Hacker News

Gchat Was the Future of Messaging, but Google Didn’t Know

slate.com

141–150 of 295 posts

Re: Gchat Was the Future of Messaging, but Google Didn’t Know

#141
post #58
post #54

Earlier quoted context omitted.

> a system with an open specification that checks all the boxes in terms of features (not quite end-to-end encryption yet, but it's being worked on) and is not controlled by a company Half of the people reading tune out very quickly around this point. Most people want something that solves 80% of their problems with 20% reduction in headaches.

The only major problem I still have with Vector is that despite Matrix the protocol specifying ways to register and authenticate accounts using various web apis like oauth[1] Vector is always pushed as the premium Matrix webclient but it doesn't support anything but username / password. You would be amazed how many people simply refuse to create new username / password pairs in 2016. And its a good thing. We should b…

Actually, Vector does support alternative auth mechanisms (although it's quite buried) - it implements the web fallback mechanism, both on web, iOS & Android, such that any unrecognised auth mechanisms can be handled by whatever webpage fragment hosted by the server, as per: https://matrix.org/docs/spec/r0.0.1/client_server.html#fallb...

For instance, we have a workplace deployment of Vector knocking around that uses CAS for auth, and the whole CAS flow is handled by the fallback mechanism. (This CAS happens to be user/pass, but it could easily be 2FA or whatever instead).

That said, it's still beta, and not super-documented.

Re: Gchat Was the Future of Messaging, but Google Didn’t Know

#142
post #6

We had a clean, functional chat app in Gchat that supported XMPP federation, a reasonably good file transfer protocol (IIRC it could be implemented by others) and a even emoji. When Google dropped XMPP, it was pretty much the death knell for interoperability. Facebook followed suit. I don't get the politics that drives the internal chat product development, but it feels like there's a lot of NIH-related "burn it to t…

The removal of XMPP interoperability was the moment I realised "Don't Be Evil" was just another marketing puff, and not actually a statement of values. But I think the termination of Google Wave (which was also federated and built with XMPP) was the real moment Google gave up on team communications.

It amazes me how many people think that ending GChat/XMPP federation was the result of some kind of cigar smoking, moustache-twirling "evil".

I worked at Google at the time. It was killed for engineering reasons, that boiled down to:

1. Nobody used federation.

2. Except spammers. They used it a lot. Trying to keep federation alive whilst fighting spammers took a lot of effort.

3. It complicated the code a lot. Features that existed in GChat but didn't map well to XMPP were harder to implement.

4. The XMPP protocol sucked on mobile and sucked in web clients, and therefore Google's own clients were not using it any more. New extensions like Jingle were more like entirely separate protocols than small upgrades.

Federated chat protocols are the sort of thing that intuitively sound nice, but networks that implement them inevitably end up being killed off by closed, proprietary competitors that are simply a whole lot better. Email hangs on, kinda, but I passively await the day that the email system is killed off by a closed network. It already happened for personal correspondence (facebook) and I'm sure at some point it'll happen for work correspondence too.

Moxie Marlinspike has written some thoughts on why federated protocols are yesterday's solution here:

https://whispersystems.org/blog/the-ecosystem-is-moving/

Put simply, in a world where clients are all free and the identifier of choice is the phone number, federation doesn't add much value.

Re: Gchat Was the Future of Messaging, but Google Didn’t Know

#143
post #67

Earlier quoted context omitted.

I really really like the ideas of Matrix, but the problem is none of my friends are on it. I had the same problem when I started to use Signal. WhatsApp actually seems like the lesser of two evils right now - even though it's controlled by Facebook, they've added encryption and some of my friends are on it. Who'd have thought we'd look back on the days of MSN, AIM and ICQ as the golden age of interoperable messaging?…

> I really really like the ideas of Matrix, but the problem is none of my friends are on it. Build a whatsapp bridge for matrix? I mean, it's built for the exact case where people aren't "on" it.

Precisely. There's already the beginnings of a WhatsApp bridge for Matrix (and indeed anything that libpurple can speak) at https://github.com/matrix-org/node-purple/tree/master/appser.... It just needs tuits for people to work on and finish off. Meanwhile, the IRC & Slack bridges are live and work relatively well today (although a lot more work still to be done).

Re: Gchat Was the Future of Messaging, but Google Didn’t Know

#144
post #63

Just about every week now there is a top story on HN about the disastrous state of interoperable messaging in the digital world. Every time it comes up, I implore people to look into Matrix ( https://matrix.org ), a system with an open specification that checks all the boxes in terms of features (not quite end-to-end encryption yet, but it's being worked on) and is not controlled by a company. I really hope to see it…

"Decentralized persistent communication", as long as you either use a centralized homeserver you don't control, or run a hugely resource-hungry and crash-prone homeserver yourself. I tried running my own for a few months, and resource demands for even a single user in a few moderately popular channels brought down my small ec2 instance. Eventually I had to shut it down, but now I've lost my ability to authenticate as…

Yup. the Synapse server implementation is still beta, and we are working away on the performance issues (yay, Python/Twisted). In the last few months we've reduced the memory footprint by about 2-3x (by string interning, better caching, and letting the cache size be configurable). The only stability issue we're aware of currently is the risk of being OOMed on small VPSes.

That said, we're really hoping that having almost finished fleshing out the whole ecosystem now, the future will be much tighter and svelter homeservers like Perceptes' ruma implementation.

Re: Gchat Was the Future of Messaging, but Google Didn’t Know

#145

Earlier quoted context omitted.

Does this require control of the server being bridged to implement, or could I do something like, say, set up an instance that lets me be on both Rizon and Freenode at the same time on one client connection?

My understanding is that bridges are implemented via application services (the Matrix term for privileged plugins that extend the capability of the server,) so a user's ability to communicate over non-Matrix protocols is dependent on the homeserver where their user account is based. The best known example of this is that the public matrix.org homeserver is bridged to the Freenode IRC network, and certain channels are…

It generally doesn't require input from the target network being bridged, unless you're running a large public bridge like the ones we host on matrix.org. You do however currently have to run your own homeserver in order to run your own bridge (although in future we're looking at ways of getting around this for 'personal' bridging purposes).

If you run your own homeserver, and your own bridge to Rhizome/wherever, you can think of the end result being a bit like bitlbee or a pidgin-in-the-cloud... but decentralised, and with the richness of Matrix's conversation semantics (e.g. arbitrary data types) rather than being limited to IRC.

Re: Gchat Was the Future of Messaging, but Google Didn’t Know

#146
post #88

Earlier quoted context omitted.

Is anyone working on it that I could help?

I'm not sure exactly what you're asking. The only practically usable homeserver software right now is Synapse ( https://github.com/matrix-org/synapse ), an implementation in Python built by the Matrix core developer team.

Synapse only runs serverside. In future we'd love to evolve things to be able to run clientside - e.g. our P2P Matrix GSoC project: https://github.com/matrix-org/GSoC/blob/master/IDEAS.md#peer...

Re: Gchat Was the Future of Messaging, but Google Didn’t Know

#147

Earlier quoted context omitted.

The problem is Whatsapp is actively hostile to any kind of attempts to creating 3rd party clients or APIs.

Exactly, and this is the problem with the state of messaging in 2016. The companies have built their walled gardens and are now actively defending them against "outsiders". It's to the point where I've considered buying an iDevice just to communicate with a few friends on iMessage.

Strange thing is this was always the case and just recently started to change. MSN API was a joke, you needed a desktop environment on the server to run the actual client to use SOME of the functionality. Nearly the same with Skype. Gchat removed Jabber pretty fast. Facebook chat also removed the outside functionality of their XMPP clone. Whatsapp is not even able to provide a web client, but only a weired bridge because they crippled to xmpp they are using way to much. No experience with the Apple services but i assume they are similar.

Next to that we always had open protocols, that worked perfectly, had plenty of clients and apps and nobody used them.

It is a stupid market.

Re: Gchat Was the Future of Messaging, but Google Didn’t Know

#148
post #58
post #54

Earlier quoted context omitted.

> a system with an open specification that checks all the boxes in terms of features (not quite end-to-end encryption yet, but it's being worked on) and is not controlled by a company Half of the people reading tune out very quickly around this point. Most people want something that solves 80% of their problems with 20% reduction in headaches.

The only major problem I still have with Vector is that despite Matrix the protocol specifying ways to register and authenticate accounts using various web apis like oauth[1] Vector is always pushed as the premium Matrix webclient but it doesn't support anything but username / password. You would be amazed how many people simply refuse to create new username / password pairs in 2016. And its a good thing. We should b…

I have no qualms about OpenID Connect itself — it is a sound standard, using JSON Web Tokens is a particularly nice feature — but I dislike encouraging users to identify themselves for every service they use with Facebook or Google accounts. Way too much information about your digital life centralised with a single commercial party.

I'd much rather see the use of password managers become more common, or even better, stimulate user-friendly two-factor authentication standards such as FIDO U2F.

Re: Gchat Was the Future of Messaging, but Google Didn’t Know

#149
post #88

Earlier quoted context omitted.

Is anyone working on it that I could help?

I'm not sure exactly what you're asking. The only practically usable homeserver software right now is Synapse ( https://github.com/matrix-org/synapse ), an implementation in Python built by the Matrix core developer team.

So, why did you answer "Sure" to his question if the answer is actually "No, you can not run a homeserver right now on your smartphone" ?

I mean, a python app for posix systems is not really close to being run on unrooted android and iOS.

Re: Gchat Was the Future of Messaging, but Google Didn’t Know

#150
post #58

Earlier quoted context omitted.

The only major problem I still have with Vector is that despite Matrix the protocol specifying ways to register and authenticate accounts using various web apis like oauth[1] Vector is always pushed as the premium Matrix webclient but it doesn't support anything but username / password. You would be amazed how many people simply refuse to create new username / password pairs in 2016. And its a good thing. We should b…

I have no qualms about OpenID Connect itself — it is a sound standard, using JSON Web Tokens is a particularly nice feature — but I dislike encouraging users to identify themselves for every service they use with Facebook or Google accounts. Way too much information about your digital life centralised with a single commercial party. I'd much rather see the use of password managers become more common, or even better,…

OpenID Connect supports discoverability, which enables a protocol like Mozilla Persona to work over it. That's exactly what some others and I are working on, hopefully we will make some headway and greatly increase the usability of authentication again.
Post reply on HN