Hacker News new | past | comments | ask | show | jobs | submit login
Gchat Was the Future of Messaging, but Google Didn’t Know (slate.com)
452 points by janvdberg on May 29, 2016 | hide | past | web | favorite | 284 comments

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 enter people's consciousness as one of the most serious contenders for messaging systems.

Matrix is very usable today via the Vector client (https://vector.im/). You can connect to the public server run by matrix.org, or you can run your own server that federates with all the others if you'd like to maintain ownership of your data. Matrix can also bridge to existing systems like IRC, so there isn't necessarily the need to convince your friends and family to "switch" with you. There are interoperable clients being developed for other operating systems including mobile platforms. Even with client support not all the way there yet, the spec and the system are more promising than anything else out there today.

If you're interested in Rust, you might also want to take a look at my project, Ruma (https://www.ruma.io/), which is a Rust implementation of the Matrix system. It's in very early stages, so don't expect to use it at this point, but it's progressing steadily.

> 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 be past username / password. Support oauth2, openid connect, and for the privacy minded... keep complaining to Mozilla that they shutdown Persona.


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.

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.

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.

Sounds like a good initiative, be sure to post on HN when you reach significant milestones.

What I worry about with OpenID Connect on the open internet (as opposed to OpenID Connect used in a corporate setting, or to provide single sign-on solutions for specific partnered services) is how it almost always results in a service asking you to use Google or Facebook to authenticate, with huge coloured buttons, followed by a tiny de-emphasized grey link where you can sign up using email and a password.

Is this something we can prevent?

They only provide Google / Facebook buttons because they are by far the most popular option. In practice the vast majority of major online web services support some from of openid / oauth signon, from Github to Steam to Wordpress and more.

As a site developer, it is your job to figure out what buttons your user demographic will use. If it is all facebook / google, then provide those, and most of these sites know providing more obscure options only confuses their potential users.

I think it is, because the "Google" or "Facebook" part isn't static in OpenID Connect, they're just popular defaults. OIDC doesn't care where it goes to authenticate, you can just as well enter your email, foo@example.com and the server will try discovery and authentication against example.com (which can then be running your own OIDC provider).

What we're working on (we will definitely post about it) is basically OIDC with a nicer UX, where the user enters their email, the domain is parsed out, discovery (of OIDC or whatever other protocol) is done, and the user is redirected to either their provider, if found, or to a default method of authentication (currently a link sent over email) to log in.

So what you're saying is that username/password is still the only choice for privacy minded people.

Google Talk did have XMPP functionality, which allowed for SASL. [1] But of course, they killed this off because they wanted to dominate chat and messaging with their own proprietary protocol.

If they had not followed this strategy they would be killing in this market, even whilst supporting XMPP Federation. But they have chosen to release multiple proprietary products, so they aren't the lead in the market. Silly of them really, and it just shows you they aren't really the nimble company they once were.

1. https://developers.google.com/talk/open_communications

I doubt the decision to close up their protocols was taking lightly. You can bet that user lock-in is part of their current strategy.

Did any Google engineers ever reveal Google's true intentions for shutting down their XMPP offerings?

I'm still using XMPP to connect to GChat ... I use it every workday (via Pidgin).

Google stopped supporting XMPP in the sense that they stopped trying to change XMPP to fit their needs. They also started killing off support for arbitrary XMPP servers, e.g. you cannot run your own and expect it to work with Google Chat. (This was the most up to date link I could find.)[https://xmpp.org/2015/03/no-its-not-the-end-of-xmpp-for-goog...]

You can still somewhat use it, but it does not work well. Groupchats do not work at all anymore, and there is no message synchronization over it so any Hangouts client will populate messages an XMPP client never sees, and you cannot request chat history from the remote.

It is definitely not a high quality XMPP experience. If you want to use XMPP, you should probably be using duckduckgo's XMPP offering.

One day it will go away...

They killed it because Microsoft was leaching contact data from them without giving back.


We are pretty much past needing to remember them. Checkout password managers. There are lots of options in that space these days.

Do you mean end users, as in the type of people systems like Slack market to, or are you referring to the failures of previous systems that made open specs and interoperability a goal?

If the former, Matrix the specification and overall system is not what would be sold to the end user. Like you say, most of them don't care how it works or about the philosophical or political reasons why you might choose a system like this. They just want to be able to talk to friends, family, and coworkers and have a good user experience. That's something any company could package and sell in a way that resonated with people, using Matrix as its underlying system.

In other words, Super Awesome Chat, Inc. could create a really slick hosted Matrix service and client with great usability, and the end user wouldn't necessarily know or care about how it worked. In mentioning the open specification, it's not for the benefit of that type of user, but at the HN reader who is likely more informed or interested in the details of the technology, the philosophy, or political/sociological implications.

That was exactly the deal with the old google talk. Most of its users never knew or cared about xmpp and interserver comunication. It just worked.

Haha! I just tried Vector on iOS and apparently moved about in such a way that I accidentally triggered the greatest notification message:

> You seem to be shaking the phone in frustration. Would you like to submit a bug report?

I've seen this UI in other apps, and I absolutely fucking hate it. Google Maps was a particularly egregious offender, where rotating the device or calibrating the compass would prompt for feedback, usually in the middle of trying to use a map. And who shakes a device in annoyance anyway?!

No kidding. Especially annoying when using Google Maps and driving a stick shift.

The stick shift gesture should notify the police of your location and destination.

This is so, so dumb. Who actually shakes their phone in anger? Very few people. How many people accidentally trigger things like this in the course of everyday usage? Everyone.

Google Maps has the same thing and it just strikes me as some cutesy feature a developer thought would be funny, but is actually very annoying.

Having an app developer available to be shaken in anger was deemed impractical.

Wow. I am truly impressed.

A lot of companies use the "shake the phone hard" as a way of sending feedback.


We had jabber for a decade at least. The battle for messaging market share doesn't seem technological.

Heck you even had the option to federate private servers so one could address users across hosts.

But Jabber was XML based. Matrix is JSON Based!

If only we would've chosen the right technology, people would've used it.


edit: it's a joke. I'm an idiot.

You're missing the sarcasm.

If you believe that's the point the OP was making, you did not click the link in the post you're replying to.

Edit: still an idiot.

Please read, comprehend and then post. From the page you didn't read that was linked in the OP:

> NOTICE: This document is Humorous. It MAY provide amusement but SHOULD NOT be taken seriously.

Thank You. Brightened up my evening.

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? At least I could talk to everyone I needed to through Gaim (Pidgin) or Trillian.

Being able to use Gaim/Pidgin doesn't count as interoperability dude. Those protocols worked only because somebody bothered to reverse engineer them and this "interoperability" only worked half the time. I know because I was using Gaim/Pidgin for Yahoo! Messenger back then.

Today at least they are using web technologies and I get to use Facebook's Messenger, WhatsApp, Hangouts and Slack on Linux without headaches.

For a short period, most of those old proprietary clients started supporting XMPP. That was the golden age of instant messaging. I couldn't help but notice that somewhere around that time is also when Apple released iMessage and FaceTime. Suddenly, everybody ran back to walled gardens and we de-evolved to a point where people are suddenly okay paying for a service that they can only sort of integrate with. Thats how low the bar has gotten now.

Personally, if I were a place like Google where the content is more important than the product. I would be having very pointed discussions with the people in charge of things like Hangouts and Allo. There seems to be a lack of vision compared to what is easily doable in this space. Knowing enough of the XMPP spec to see what was never done, I have to agree that the author is right. Google never understood what they had with GChat.

To put it another way. Imagine if everybody ran around trying to make their own SMTP or HTTP protocols? Thats what everybody is trying to do with chat right now.

Oh, I totally get what you're saying, except that I don't find usage of XMPP clients to be that useful. Yes, I know that Facebook supported at some point XMPP clients. I never cared about it.

Real interoperability is federation. If we had federation, the problem of using your favorite client would be moot. My argument is that there never was a "golden age" of chat, unless you refer to IRC back in the nineties and even that would be debatable.

And out of the big boys I can only name Google's Talk as supporting federation, only to be killed and replaced by Hangouts, that doesn't support federation because, wouldn't you know, they needed to innovate and couldn't do that while supporting XMPP, allegedly. And even if Hangouts pushed WebRTC forward, I'm glad it's not used and I'm glad that it suffers a slow death, because this proves that the innovation argument is bullshit. And I'm fairly certain that Google Talk was more popular than Hangouts, even if Hangouts got pushed down the throats of every Android user.

> 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).

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.

Convince them to get Telegram. It works on most devices, and has extensibility built in:



I just installed the Telegram app. Why is it asking for my phone number?

They use phone number as account name rather than email on mobile.

What if I don't want to use it on a phone?

The web and desktop versions can send an SMS to authenticate if you don't want to or can't use the phone app.


I see. I don't really want to tie it to a phone number, though.

Already did with the in-laws. :-)

Wasn't really a problem with ICQ, even though they had actively struggled and tried to change protocols frequently (and broke unofficial clients once in few months).

The community was large, and there was a significant demand for good clients (official one was shit). I guess now the difference must be that either official client is good enough for most users, or that users' attitude to how they want things had changed and they learned to submit to whatever service providers dictate.

So was AIM, though. That didn't stop the third party clients.

AOL worked actively to stop third-party AIM clients in the same ways as mentioned above from icq through WhatsApp -- changing protocols and central auth mechanisms.



Right, the point is "whatsapp is hostile to third-party clients" makes no sense as an explanation of why we don't have third-party clients for whatsapp, because all third-party clients for everything have had to deal with hostility from the first party.

I have had some success with getting people on signal, though now that Whatsapp is encrypted by the same technology there doesn't seem to be a big benefit anymore. Generally it seems to me people are not so adverse to having several messanging sollutions installed these days.

"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 the user I identified as during that time, until I set up my homeserver again.

For anyone else reading, it's worth noting that these issues are with Synapse, the "reference implementation" homeserver built by the team developing the Matrix spec. Performance issues are a focus for its development now. There are also other projects (like my project Ruma) that provide alternative implementations that won't necessarily have these performance issues (hopefully!) The nice part about having a spec is that anyone has the opportunity to provide a superior implementation.

That's interesting, I'll check it out!

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.

Problem is the greatest system in the world is useless unless a quorum of people in your circle are using it. I've been trying to get my friends to use Wire for a year but still have to run skype

That's where bridging with other services comes in, e.g. using Matrix on your side to talk to contacts on IRC or whatever else without the people on the other side having to change what system or software they use.

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 synced to each other, e.g. (#matrix on Freenode is the same thing as #matrix:matrix.org on matrix.org.)

I'm not sure how this works for non-public communication, like private messages on IRC or services like Facebook where it wouldn't be safe for the Matrix homeserver to have access to a user's Facebook account.

At this point I'm not super well-versed on the details of application services so hopefully one of the Matrix team members will reply to you directly.

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.

> 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

Wouldn't this still be centralized to your home server?

Wasn't open chat already solved by Jabber decades ago?

Moxie Marlinspike recently published an interesting essay that adressed this question.

”XMPP is an example of a federated protocol that advertises itself as a ’living standard.’ Despite its capacity for protocol ’extensions,’ however, it's undeniable that XMPP still largely resembles a synchronous protocol with limited support for rich media, which can't realistically be deployed on mobile devices. If XMPP is so extensible, why haven't those extensions quickly brought it up to speed with the modern world?

Like any federated protocol, extensions don't mean much unless everyone applies them, and that's an almost impossible task in a truly federated landscape. What we have instead is a complicated morass of XEPs that aren't consistently applied anywhere. The implications of that are severe, because someone's choice to use an XMPP client or server that doesn't support video or some other arbitrary feature doesn't only effect them, it effects everyone who tries to communicate with them. It creates a climate of uncertainty, never knowing whether things will work or not. In the consumer space, fractured client support is often worse than no client support at all, because consistency is incredibly important for creating a compelling user experience.”


I am hoping the Matrix team will write a blog post about their viewpoint on Moxie's post, given that they are out to do something Moxie doesn't believe can succeed. I'm also curious to hear how they respond to the specific section you quoted: how is Matrix going to avoid the same fate XMPP suffered here?

We haven't had a chance to write a formal response yet; too busy getting Matrix out of beta. I responded at the time at https://news.ycombinator.com/item?id=11669681 though.

A quick specific answer w.r.t. XMPP is that Matrix aims for a very coarser granularity of modularity, published as a single consistent spec, and mandates feature profiles to determine which modules should get used where. In other words, there is only one official set of endpoints specified for Matrix for a given use case (e.g. mobile IM+VoIP). So it ends up being under tighter control (whilst still very much taking proposals and PRs from the overall community), and is easier to swap out the higher level layers to rapidly evolve functionality - rather than suffering the proliferation of XEPs which is XMPP's double-edged sword.

This is always going to move slower than a centralised service, but we think the freedom of being able to select your clients/servers/services is well worth that cost in agility - and does not have to compromise privacy if engineered correctly.

Thanks for the response and the link to the previous response. I'd missed that! Both are great answers. :}

> Like any federated protocol, extensions don't mean much unless everyone applies them, and that's an almost impossible task in a truly federated landscape. What we have instead is a complicated morass of XEPs that aren't consistently applied anywhere.

The problem is, without actual numbers - how many clients support what - this statement is just a personal opinion, not a rule.

We can say exactly the same about the web. It's also federated, it also has fractured client support (although, sadly, core engines can be counted on fingers) and it's also full of extensions. While I won't praise the web, and I'll surely admit that the trends for siloing are strong (for many, a single big social network site of their choice is the "web"), it still manages to provide somehow decent user experience.

There is the w3 and other standards comitties joined by industrie leaders and a lot of experts and public eyeballs. Chat hardly compares. Perhaps the W3 should concern itself with chat. The IETF released SIP. The w3c offers IRC channels.

A broken browser is a pain, new standars improve the user experience (e.g. html video). For the public user there is no discernable difference in any basic chat's protocol and implemetation.

IETF has also standartized XMPP.

Jabber/XMPP has a number of problems that make it unsuitable for modern chat environments where clients (read: smartphones) have poor connections and frequently want to sleep to conserve power.

For example, XMPP wants an always-on TCP connection between the client and the server for the client to appear "online". There's an extension which allows for sleeping, but having async mobile connections in an extension means that you need the right pair of server and client to enable this feature. Plus, there's no handling of syncing messages between multiple clients. If you've got a smartphone and a desktop client, to compete with Facebook Messenger you need detailed conversation transcripts on both clients -- and an intelligent way to ping your clients and tell which should receive sound notifications.

see more at https://op-co.de/blog/posts/mobile_xmpp_in_2014/

Emphasis on in 2014, that was forever ago in Internet time. XMPP is steadily moving forward and the things mentioned in that post have improved a lot. Check out https://conversations.im/ for example.

That was not only XMPPs problem. It is what sunk most of the desktop IM systems, making way for the mobile ones.

Jabber doesn't do offline messaging well at all, nor push particularly well (not out of the box, so to speak).

The "standard library" of messaging has expanded a lot lately.

This is cool. But IMHO the point of the article is about Google losing its first-mover advantage in chat apps due to wrong branding and prediction for GChat, not interoperability.

I force my friends to use Gchat when the chat is turning into long conversation and I want to type on my PC keyboard instead of my cell.

But I'm not sad Google missed out with Gchat. One less product Google dominates with means some other company can innovate in that area and compete.

True. My comment is not a response to the particulars of this article, but more about the area of software of which GChat was a member. Apologies for turning it into my own soapbox.

I have a computer which is always on and always connected.

It's my smartphone.

Can I just run a 'homeserver' on that and be connected?

Sure. Homeserver software doesn't care where it's hosted. If you want it to federate with other homeservers on the Internet, it will need to be accessible from outside your local network, of course.

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...

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.

I somehow didn't process the "it's a smartphone part" and completely misunderstood his question as a result. I'll edit my original reply to correct that. Edit: Apparently I can't edit it anymore. :{

That's fine. I am really interested in the possibility of running a 'homeserver' directly on a phone.

Do you think that would be possible?

Yes, it is possible. Ultimately, a homeserver is just a program that implements the client-server, and optionally the federation, APIs. The only feature-complete homeserver right now is Synapse, which is written in Python, and as of this moment has performance issues even running on a server, so it's not realistic that it could be modified to run on a phone. My homeserver Ruma is written in Rust, which is a systems language that actually is suited for mobile and embedded systems development, although I am currently not targeting that use case, nor is Ruma mature enough to be practically useful yet. If you're interested in the possibility of developing your own homeserver implementation specifically targeting your use case, you should take a look through the Matrix specification documents: https://matrix.org/docs/spec/

It was a "sure, in principle".

Always connected? I really envy you.

I mean, can you even take the subway or go on an overseas travel and still be sure that your smartphone is your single point of failure?

If you are on Android or iOS, it’s not always connected – and you can’t actually run things in background all the time anymore either.

I really like the ideas behind Matrix. Sure, the existing (open) clients aren't all that sexy, and synapse can be a bit slow sometimes. But implementing your own client is a breeze and bridging other networks through application services makes it incredibly powerful.

My experience with the matrix.org community has been very pleasant so far. Keep up the good work, folks!

Matrix looks interesting. But, damn, that animation on the homepage slows my browser to a crawl!

How is the feature set any different than XMPP?

They have a good explanation of how Matrix compares to XMPP in their FAQ: https://matrix.org/docs/guides/faq.html#what-is-the-differen...

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 the ground" going on there. Nothing they do in this space makes sense to me at all.

What Google failed to realize is that people want chat that's connected to other services they frequently use. I'm already browsing FB so it's easy to chat with my FB friends using Messenger rather than both pop over to another service. The same reason why MSFT has tried (much less successfully) to incorporate its chat offerings into Office365 and the reason it bought Skype.

Google was in a position to capture the chat market by tying it to an email service that everyone was using - GMail. But it had two problems: 1. Email is an open service that doesn't lock users in meaning people using Yahoo Mail can still communicate with people using GMail (unlike Facebook where the only place to interact with FB users in is FB). 2. Google didn't lock its users in with GChat, so users could drift away to other services while still communicating with GChat users if need be.

Due to its very nature, FB was destined to win the messenger wars; if all your friends are already on FB then most people will default to what's easiest--the chat functionality that's already there and all your contacts are connected to. But since FB tends to be your personal circle rather than work circle, this left the work circle open, which Google could have captured if it hadn't screwed up on Hangouts leaving the door open for Slack.

Back in the day, it was normal for everyone to have some sort of multi-protocol chat client like Trillian or Adium or Pidgin, and everyone had multiple accounts too, MSN, ICQ, AIM etc some people even had Yahoo. You wouldn't care which one one of your contacts was online with, you could just chat. The "stickiness" of an individual chat system was very, very low, and the network effects didn't work like any of those companies expected them to.

You see it today with drivers having both Uber and Lyft apps open.

Great theory. Except that outside the US people who are FB friends tell each other "I want to chat, give me your number so I can add you on WhatsApp". Outside the US, WhatsApp is winning because of network effects.

WhatsApp came to Europe at a time when there was a strong need to replace badly overpriced SMS. In the US most telco's offered subscriptions with free, unlimited SMS and WhatsApp didn't provide any immediate benefit. Facebook Messenger came later, but had the ability to send messages without contact information, giving people in the US a reason to adopt it.

By now, most people in Europe also have Messenger, but still mainly use WhatsApp (slightly generalising). I think that primarily comes down to WhatsApp being a much better messenging app. It's quick, reliable, easy to use, power-efficient, small, well-integrated into the OS, secure, and most importantly: media sharing just works.

I think this theory is quite solid. For some reason denmark has always (or at least for a very long time) had unlimited sms/mms in most subscriptions.

We also have a low WhatsApp adoption rate. Lately fb-messenger is winning territority (and so is snapchat, but for other reasons), since it offers good group chat on top of a service that already covers north of 80% of the entire population.

In Germany, the mobile plans are extremely stingy with minutes, SMS and data for some reason. I personally use Telegram (trying to convert friends to it), WhatsApp (everyone is on it), FB Messenger (everyone is there), iMessage occasionally, Skype for Voip, and I've stopped using Viber as no one seems to use it anymore (it was extremely popular about 2-3 years ago though).

> Outside the US, WhatsApp is winning because of network effects.

In which country? Because I have tons of messengers installed and so do most people I know outside the US.

Literally most countries in the world: http://www.techtimes.com/articles/160897/20160525/top-messag...

Sure, I have messenger and hangouts and telegram as well, but WhatsApp is like a primary mode of communication.

I know that WhatsApp is immensely popular in Germany. Most of my friends (me too) don't even have Facebook, and those who do, don't even use it regularly.

WhatsApp on the other hand, is more trusted than Email - When some friend sends me an email, he asks me via WhatsApp if I revived it.

Group Chats, especially with younger folks, are numerous and used for anything, even though the technology is obviously lacking, when compared to other platforms.

But most people either don't care, or perceive these benefits as less important compared to the network effect that WhatsApp has - "I don't want to switch between [random messaging app] and WhatsApp, why don't you just accept what everyone uses".

It's practically the same as with Facebook in the US, and just as bad.

Sample size of one for me....

I was in Germany two weeks ago and I tried to get my colleagues on chat...any chat...when I mentioned WhatsApp, they all looked at me like I had a unicorn horn growing out of my forehead. So far I have been unsuccessful in getting any of my team on a chat platform on a regular basis. My company supposedly endorses Lync 2010 (yeah, I know), but probably less than 10% of my coworkers use it and the entire division in Germany doesn't even have it installed on their PC's. Our Lync is also broken by the fact that corporate IT doesn't allow it on mobile platforms.

That's funny, because all people I know that use Whatsapp have moved to Germany.

But this mostly shows that the popularity debate is moot - you tend to know/use what your circle of friends does disregarding of statistics of this article posted.

I love WhatsApp, but I can't imagine handing out my phone # the way I hand out my email or irc nickname.

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:


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.

> […] in a world where clients are all free and the identifier of choice is the phone number […]

To me this translates to:

“Please run our proprietary software to participate and use a high-value nearly unique identifier to identify yourself — we really like to know that john.doe@gmail.com is the same person as feetfetish33 so we can better quantify you for targeted advertising.”

I am willing to entertain the notion that federation is not a solution, but seeing how you now either place yourself in this panopticon or you don't and 'miss out' on things makes me feel that we should at least attempt to figure out a way to put communication back in the hands of the people.

For all its warts and issues, email is still effectively federated, and will stay like that for quite a while due to the needs of many (not all, I certainly grant you that) businesses and local, regional, and national governments to control their own email infrastructure (mainly due to legislation and control).

I have yet to encounter a chat network that uses targeted advertising, so you're well off into the realm of conspiracy theories there.

Chat networks are all moving to the use of phone numbers because users mobile phonebooks are a vendor neutral, open access social network of high value contacts that almost everyone has and for which there are simple APIs available.

Phone numbers have other advantages. They are difficult to register in bulk (it can be done but it costs a lot more than bulk registering web accounts protected only by a CAPTCHA). Regulations in many part of the world enforce the ability to do number porting which makes mobile numbers truly user owned - unlike email or jabber ids which are ultimately owned by the organisation after the @ symbol. There is a simple remote attestation protocol: you can prove you own the identifier by simply providing a challenge code. Everyone understands them. And it outsources identity management costs to the telcos who have large branch/shop networks to help people who e.g. lose their device/SIM. Building out and staffing account recovery infrastructures is a significant driver of costs for large web platforms. For instance if you have a contract then you can recover your identity by physically walking into a local telco shop with your passport, you will walk out with a replacement SIM (and the prior SIM remotely deactivated) a few minuets later. It's partly by shifting these costs to the telco networks that WhatsApp was able to scale to hundreds of millions of users with only 50 employees.

When I look at how things work done this way vs a traditional internet federated network like email, Jabber, IRC etc, I have to agree with Moxie - it's not so bad, actually. I'm not normally a big supporter of government regulations, but making number porting obligatory is a relatively low cost rule that makes the use of phone numbers as the universal id a lot more palatable, because it's truly user owned at that point. Switching mobile networks and switching chat networks is a lot easier than switching email/xmpp providers because forwarding has always been an afterthought in such protocols, is legally optional, and at any rate is always going to be more complicated than just re-assigning ownership of a truly provider independent code.

Phones are dying. Too inconvenient, too much spam, pants vendors, pervasive surveillance, pants call and voice quality, and a phone is too small for a tablet.

It's got a few years yet, but POTS and mobile are already legacy, they just don't know it yet.

I don't see any replacement for a pocket-size, one-hand-operated device. Using a table while walking down a street or riding a subway car is pretty inconvenient at best.

Phones are dying?

Better hope Apple shareholders don't find out!

Apple is in a position to make the transition.

It's not the _devices_, per se. It's the network. The infrastructure. And the ability for Google to rely on a phone number per person. It's an invalid model.

And voice comms are occasionally useful, though I make them rarely -- it could easily be months.

The idea of carrying a bundle of angry that can start sounding at any time, anywhere, is a turn-off. Especially if I've no control of who's at the other end.

Two of the primary reasons people carry phones are because others demand that they be reachable, and secondarily, so that the phone holder can reach others. The second I don't mind as much though it's also a crutch.

A device with good text capabilities, that can also optionally receive voice inputs and convert that to text, allows a very* limited whitelist set of calls, and otherwis directs all incoming traffic to a wait or prove your worth queue, would start to approach reason.

I remember the days of five-line dial phones and office receptionists, pre voicemail. It sucked for the receptionist, but coming back or into the office and being handed a stack of message slips was vastly preferable to bouncing through voicemail and having to do the transcriptions yourself.

Skype shows advertisement in the chat window, most likely targeted.

> I have yet to encounter a chat network that uses targeted advertising, so you're well off into the realm of conspiracy theories there.

You won't see that because that is not what makes the phone number so useful. Its biggest benefit is being able to correlate all those separate data profiles via one unique key. This makes these profiles more valuable to advertisers. You won't see advertisements in most of these apps (it would drive users to the competition) but they don't have to; they just show them in the browser. They already know it is you thanks to the ubiquitous social media buttons and tracking going on.

This is largely conjecture, sure, but the fact that using your phone number is a requirement rather than an option makes me suspicious.

Sometimes I don't mind if two services know that I am the same person, but I would like to be able to choose for myself. Sometimes I do like to use a throw-away email address and a VPN to use some service, simply because I care about my privacy. Often I don't feel that a service needs to know who I am beyond an alias.

> we should at least attempt to figure out a way to put communication back in the hands of the people.

What to do if people (majority) don't care ?

Because that's the side result of bringing uneducated (regarding IT) masses online. They sell on instant gratification, cute shit (emojis, gifs galore) and hype. In return they don't hesitate to give their data and conversations.

No wonder everyone want's their own silo.

> It already happened for personal correspondence (facebook) and I'm sure at some point it'll happen for work correspondence too.

I don't know the numbers but I'm part of the population that never used Facebook, so I'm unconvinced you can generalize like that.

> 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.

I didn't really understand Moxie's arguments, but he may know more due to the projects he's involved in.

But how is interoperability achieved? The beauty of HTTP, NNTP and SMTP are that you're not bound to one (or maybe two) client experiences or server implementations. I don't understand the desire to leave achievements like that on the floor just for temporary comfort. It's a slippery slope and will lead us into a long time of silo'd communication.

To me the current proposals look like if I had to use 4 different post offices depending on whom I want to send a package to. There's a reason addresses are universal.

Moxie's argument is that interop takes place at the level of the operating system's notification tray.

If you want to make a better WhatsApp, all you have to do is ... build a better app. The traditional obstacles are largely gone in the mobile world:

• You can access the same social graph just by requesting the contacts permission on your mobile phone: it's not like Facebook where the social network is locked away.

• You don't have to go through some slow moving standards process which takes years to get the features into the most widely used clients like you would if trying to improve XMPP.

• There's no cost to the user having multiple messaging apps installed thanks to Google/Apple's push networks: it's not like Windows/MacOS/Linux where having an app running in the background uses resources and requires permanent on-screen reminders of the resource wastage. So it's easy to get the user to set up your app.

• Notifications will appear in the same place the user is looking for them no matter what.

• You can (on Android) register for the right intents and whenever a friends phone number is invoked, your app will be offered as an option, so there's no lockin there either.

These things together mean the traditional reasons for pursuing federated networks for chat (the avoidance of lockin) are largely irrelevant.

It's still federated identity. Phone numbers are a federated structure, but the federation occurs at the level of telcos and nations; you are denied the opportunity of self-management. They also predate the domain name system, making them the "traditional" format, an anachronism rather than the future.

I'm looking to wearables and low-power IoT devices, and for those we may need a new federated identity/discovery scheme. The DNS is practically ancient now, but has served email, web and XMPP and many other protocols besides surprisingly well for decades. I doubt it is sophisticated enough for global-scale wearables and ubiquitous sensors. We could never have built anything so sophisticated on phone numbers.

Most of your remarks seem to align with the preferences of chat app developers. But actually there's no group I'd trust less, today, to determine the future trajectory of communication. Interoperability, federation and end-to-end behaviour is the open architecture of the Internet, and I believe anything that undermines that triad should be met with contempt and resistance.

That makes more sense, thanks.

Re sharing contacts by replacing User@Domain with numbers:

Yes, this solves some of it because everyone agreed to use phone numbers, but phone numbers are a thing of the past and you don't always want to share your phone number just for messaging.

Re notification overhead:

If you have a system-wide notification display system, then of course the resources it requires are limited but you still have to have it running in the background in some form. Granted, it's probably easier to optimize it with everyone using the same notification system. This is just consolidation of a popular feature into system-provided functionality.

Re lockin:

But lockin still exists because you are the whim of centrally managed for-profit messaging backends, operated by entities whose intentions may not necessarily align with yours.

I'm not aware of cross-app synchronization of messages and even less so a common message format (feature) set supported by all that provides a rich experience.

I don't disagree with the cited shortcomings of XMPP, though you can always find a flaw in something which wasn't explicitly designed for the current use case, so ignoring that, the basic premise of XMPP is still sound and needed. Implementation details are something else, and honestly I don't agree that replacing XML with JSON (as in some of the proposals) gains anything in terms of efficiency, which it probably wasn't intended to anyway.

My impression is that building a messaging system is simple enough that many variants pop pup, but almost all of them get interoperability, synchronization, mobility, and security wrong. It's unsurprising because the simplicity attracts implementers of all domain experience levels.

Android notifications do not require any app to be running in order for them to be displayed.

lockin still exists because you are the whim of centrally managed for-profit messaging backends

Given that 99.99% of people will never run their own servers, this is irrelevant: someone will be managing the infrastructure and those people will be motivated by profit. Welcome to capitalism: it works better than the alternatives despite its flaws.

Things like WhatsApp or GChat do not simply replace XML with JSON. They tend to use binary protocols designed for low power consumption and ease of parsing. Arguably, if any protocol gets it wrong, it's XMPP ... I used to like it back when it was called Jabber, heck, I even hung out with a few Jabber developers back in the day. But Jabber's design goal was instant messaging and it's no longer useful for that. It just couldn't adapt to even quite small changes in circumstances.

> Android notifications do not require any app to be running in order for them to be displayed.

I didn't say there has to be. What I said is there's a single notification service which is reused by everyone. If you're saying that there's no daemon of sorts for notifications, then I'm curious where it's implemented.

> Given 99.99% of people will never run their own servers, this is irrelevant

It doesn't matter that someone won't run their own server. What matters is that you can, which means someone you know or trust can and give you access. These days it's much, much easier to run simple services like messaging if you consider the proliferation of remote accessible NAS boxes and such in households. Adding a messaging service to that is easy. Other than that you can use Sandstorm too if you don't want to operate a server.

> Things like WhatsApp or GChat do not simply replace XML with JSON

I'm sorry you thought I said WhatsApp or GChat use JSON. I mentioned it in reference to other messaging services.

But interop doesn’t fix the issue of federation.

If I want to chat with person X, I either have to use the same client as them, or I can’t do it.

I can’t write my own, better client, either.

That’s the big issue.

The big issue for you, perhaps - but the reality is that most users simply don't care about that.

Most users don't care because there is no way and they're not technically minded enough to complain about it. They would use it if available. I can cite many examples of non-technical users who had conversations like "do you have whatsapp", "do you have viber", "do you have X". From that it's safe to say there's a need for interoperability, and to be honest, if messengers get more important, some regulatory body will force it like they did with other things in the past.

All those are true, but still iMessage is an important reason for many to pay more for an iPhone. So still it's pretty hard to create an attractive alternative, wouldn't you say ?

I've heard that WhatsApp isn't used as much in America. I live in Europe and do not believe I have any friends who use iMessage, or if they do, they are all on WhatsApp as well, which would seem to prove Moxie's point.

But then again in Europe iPhone market share is much lower.

I may live in a nerd specific environment but gchat was our goto product for a long while. We had our notifications build in trough XMPP just like people do with slack now. Some of us used their own XMPP servers, and pretty much everyone was reachable trough it beeing google and everybody having a gmail and/or android phone at least. There were also several cool mobile and web apps that worked very well for XMPP, though not with high load thats true.

When you removed XMPP and forced to hangout it died off pretty fast, no API and the Hangout thingy was not even working on Linux (not sure if it does these days, i never tried).

I see your points, but i cant stop to think about this as the probably most evil step google did to my workflow.

Edit:// I use hangout now to transport links from phone to desktop and the other way around. It totally lost its purpose :/

Larry Page spelled it out in his Google I/O q&a. Google tried for years and years to get interoperability but Facebook, Microsoft, and Yahoo would never do anything more than 1-way interop sucking users out of xmpp into their proprietary system. Gchat didn't have many active users, meanwhile the closed systems were getting hundreds of millions of daily actives.

I think mobile chat taught Google a lesson: the cultural Dna that "open always wins" pretty much leads to losing and having to play catch up.

I think at this point the biggest hope is that something like telegram can become the defacto new xmpp.

What, people started using msn instead of gchat because those chats weren't on xmpp?

Why would gchat have as many users as facebook anyway? It's not like gmail was a community like facebook was. MSN meanwhile basically started as a chat client, there where ads for it on tv in Sweden...

People on MSN could chat with people on GChat, but people on GChat couldn't chat with people on MSN.

Since a critical feature of a messaging app is "my friends are on it", that gave MSN/FB/AIM a huge advantage over GChat, and had they not turned off XMPP integration, they would have bled off users until it was only used by small pockets of people, all of whom were on GChat (eg. Googlers).

> People on MSN could chat with people on GChat, but people on GChat couldn't chat with people on MSN.

How this had worked?

I mean, in XMPP both parties need a JID, so MSN users must have had theirs.

Had MSN had generated random non-discoverable JIDs for their users, blocked any incoming messages unless there were prior outgoing communications, made GChat interop opt-in or what?

I'm also confused by that statement, especially as I was using msn over xmpp up until that died two years ago or however much it was.

I think maybe the grandparent was saying that you couldn't add msn friends to your contact in gtalk, but you could add gtalk friends to your msn. Or maybe its something to do with emoticons?

How does removing support for XMPP alleviate the issue?

Found the quote from Larry about XMPP: https://m.youtube.com/watch?v=9pmPa_KxsAM&t=2h54m20s

Personally,I had that moment when Google bought my favorite interoperable chat app so they could kill it: https://en.wikipedia.org/wiki/Meebo

YES! Meebo was the best. I used to use it on both the web and mobile, all the time. I was extremely disappointed when Google bought them and shut them down just like that.

Yeah, this was the beginning of the end of my support for things done by Google.

When it was coined "Don't Be Evil" was a reference to Microsoft, who at the time was an especially bad actor in the industry, even for them. Dropping support for a protocol is one thing, but actively sabotaging open protocols like MS did is quite another.

You're absolutely right except for limiting the bad actor qualities of MS to just at that time. While they have made inroads to more open systems, they continue to do heavy handed things, e.g. the misleading and intrusive Windows 10 upgrades.

"was the real moment Google gave up on team communications" I believe so too and Wave might have failed because Google said "this is instead of email". Had they markeded Wave as a "team communications suite" like Microsoft is doing today with their team communication tools, and all the aother players too (we're getting used to hearing about communications suites especially at work, right?). But the world was probably not ready to hear about communication suites until maybe 2010, så Wave was also too early. And it definetly wasn't a email replacement.

Maybe this high-lights the drawbacks of being too focused on your core business, so focused that you cut of an arm (gchat) because it wasn't in line with your philosophy of having a totally open, standardized protocol that you (Google) hoped everyone eventually would be using. The players of today do not care about these things, they care about getting traction and a massive user-base and about encryption and privacy and claim their place in the spot-light because users love them.

Google knew we loved gchat. They must have know why. Google Drive + gmail + gchat, tailored towards businesses: good bye Office 356, see you never. Microsoft would be limping without Office... how could Google fail to make this happen?

Yeah, it didn't make any sense.

It also didn't make any sense they dropped XMPP in favour of Hangouts. XMPP has its share of problems, but it's designed as an extensible protocol. Google's Jingle addon to XMPP was actually quite nice, although it took quite some time to get polished.

Once they had it right and it was gaining some traction, they drop it in favour of a proprietary solution...

> It also didn't make any sense they dropped XMPP in favour of Hangouts.

It makes perfect sense. Forcing out competitors (XMPP) with leverage from dominance in a neighboring market (gmail, which was the common interface for GTalk) is a textbook example of monopolization.

If we lived in a world that actually cared about the rule of law, Google would be charged for violating the Sherman Antitrust Act (and/or related antitrust acts).

Wait are you saying that XMPP was forced out (solely) by Google, and that Google at some point monopolized the "instant messenger" market?

Not to mention that XMPP is a standard, not a competitor.

This is like saying that modern companies are monopolizing against SOAP or YAML.

> (solely) by Google

I didn't say anything about other players in the "chat" market.

> Google at some point monopolized the "instant messenger"

No, the have dominance in the email market (I mentioned gmail). They used the position of power in the email market to limit XMPP and support their new Hangouts service.

Just like Microsoft used to do, Google broke their support of the protocol. While most of the protocol still worked, they started dropping auth requests on the floor. This wasn't an error message or missing feature; their S2S protocol simply dropped auth requests so it looked from the outside that the request was delivered, but the person on the other end never responded. Outgoing (from gmail) auth requests were removed entirely. From the perspective of gmail users, XMPP popularity simply faded and Hangouts took over as a replacement.

Using one market (gmail) as leverage in another market (chat) is basically the definition of monopolization. Note that this doesn't require a perfect monopoly in the first market; ability to force/manipulate the market is sufficient. Additionally, the Sherman Antitrust Act also criminalizes the attempt to monopolize.

> Not to mention that XMPP is a standard

Obviously. I've been following the development from the beginning (before it was called "jabber"; the name "XMPP" happened many years later).

> not a competitor.

An open (federated) protocol is the most dangerous kind of competitor to a big company like Google. Deals/contracts can can be made with a company, but a federated protocol by definition cannot be controlled by a single entity.

> This is like saying that modern companies are monopolizing against SOAP or YAML.

I think you need to re-read what I said. Or maybe read more about how antitrust law works.

In the timeframe you're talking of, Gmail was a distant third in webmail and even further down the list if you considered all email clients. I don't know where the threshold of "dominance" is, but I refuse to believe it's at 5% market share.

>Using one market (gmail) as leverage in another market (chat) is basically the definition of monopolization

No its not. Unless you're claiming that this is a form of product tying, but that would require that

1. Gmail held a monopoly or near monopoly over the email market at the time 2. hangouts was a service that people needed (or that to use gmail, you also were forced to use hangouts)

Neither of those were the case.

> note that this doesn't require a perfect monopoly in the first market

There's no such thing, that's a strawman to permit calling things monopolies when they aren't. Given that Google allegedly tried to act like a monopoly and totally failed, I suggest that you rethink your view.

> An open (federated) protocol is the most dangerous kind of competitor to a big company like Google.

You mean protocols like SMTP and HTTPS, protocols which are core to Google's business? This was not a company with a monopoly in one area leveraging it to gain advantage in another. Google was not even close to a monopoly (or even a plurality) in email; Yahoo for one had more users at the time than Gmail.

This was Google admitting that open wasn't working and going private to try and retain existing users. Which, not having anything close to a monopoly, was perfectly legal. One could even argue it was their fiduciary responsibility to their shareholders to try and grow the user base.

The "Don't be Evil" is so vague that it was obviously just for show right from the start.

Reflecting on it led me to use 'be nice' as our company policy. It's vague too but it has been a useful guide towards doing the right thing on occasions. Mottoes are necessarily vague.

I knew Google was "evil" long before then, but the biggest middle finger to me as a customer was dropping ActiveSync. Seriously, try to get Outlook to work with Gmail, it's a totally nightmare. Absolutely unnecessary in its complexity to get it to work (lots of buried settings in Gmail, lots of blocking your sign-ins, Calendar syncs only work one way.) I deplore Google Apps for Business, just a complete nightmare, unfortunately I'm stuck with it.

That's not much different than dropping xmpp federation: Microsoft was charging them for the patent license on ActiveSync, AND attacking android at the same time. So Google dropped ActiveSync at the point in time when it hurt Microsoft most - WP8 release. Microsoft's response was "no no no, don't pay for ActiveSync but please keep it up"

Historically, Google drops features when they don't make financial sense or when they give leverage/advantage to competitors.

Right, now try setting up Outlook 2016 with Gmail. It has nothing to do with financial sense, they intentionally broke the functionality. That's anti-competitive. You can search for the various people having problems with it. If Microsoft had done what Google did, they'd have made the front news of major publications for being anti-competitive. Google is a darling, so they get away with murder. This is just a minor example.

My guess is that it has to do with compatibility with XMPP, but I've never worked with the technology myself so I haven't got a clue. If it is compatibility, then both companies likely continued forward after their products had matured to a certain degree. Perhaps they wanted to go forward, but were constrained by XMPP.

XMPP is a poor protocol. I can completely understand why they would want to break compatibility.

Is there anything particular about XMPP that is poor?

Right before Slack started getting traction I had though of building a Chrome extension/app on top of Gmail and Gchat that did similar things. Sometimes I still think about it, but I think Slack has started to dominate.

> When Google dropped XMPP

AFAIK they only dropped federation and support, but I still can connect with any XMPP client.

They really just dropped support and left it a broken mess. It kinda looks like you can federate with them if you disable TLS, but messages are apparently just dropped. This is worse than if they just killed it, as people tend to blame XMPP instead of Google.


The current state of chat is depressing. The trend on the Internet today seems to be centralize everything. I think it's because centralized systems are easy to understand, maintain and take advantage of. Why maintain a library of media when you can let Netflix/Spotify/Steam etc. do it?

Unfortunately chat is no different. There seems to be a modest swingback with things like Conversations/Signal/ChatSecure, but that has more to do with Snowden than interoperability. I use Conversations on my phone, Gajim on the desktop, Prosody on the server with OMEMO over XMPP on everything, but the average user is going to make an account on Facebook and be done with it.

I think I'd even be happier if chat went the way of Email whereby everyone chooses between three or four big players that interop on a standard. The status quo is the same as any digital storefront. I can't watch a Netflix movie I paid for on an unaffiliated desktop client, I can't chat with a Facebook friend on an unaffiliated desktop client. Maybe we should start demanding DRM-FREE social relationships.

Edit: Enterprise was the last hold-out for this kind of thing. It seems like more and more companies are trusting Google with their email, Github with their code, Slack with their communication etc. "Embrace the cloud" ~== "Cede control of all facets of your business to third-parties".

Yeah, it'd be nice if IM just settled on some interoperable basis. I think there is an eternal need for a new chat app (as each new generation of school children create their first accounts on some service their parents aren't already on, and someone will fill that gap) but I liked the years when I could just add another account to adium and manage it that way. These last years it just been accounts dying off, and the new smartphone apps not really working well in my desktop client :(

> Yeah, it'd be nice if IM just settled on some interoperable basis.

And critically: that standard needs to not be XMPP. It's a mess of a protocol that's difficult to implement, and which fails to adequately support many common use cases (e.g, mobile clients, file transfer, and group chats).

I think we should coalesce around a clean modern modular standard that's not XMPP for the perfect world scenario. It's not perfect, but I think you overstate how bad it is. Conversations (a mobile client) allows pictures and (file transfers) and with multi-user-chats MUC (group chats). It takes implementing some XEP's on the client and the server in order for everything to play nice. Implementation is a bear and some XEPs are simply too complicated for their footprint. However, if no one is interested in the open federated standard communication protocol we have, even less are interested in adopting another one we haven't written a line of spec for yet.

As mentioned elsewhere in the comments here, Matrix is seeing quite a lot of adoption as an attempt at a clean modular federated standard (albeit very different in philosophy to XMPP) - there are around 30 clients, lots of bridges, services and bots, and multiple servers in development. There is very much an appetite and interest in open comms still, as the popularity of articles like these attests!

Matrix is interesting. I like where they're going and once their encryption-layer gets out of beta, I'll take a harder look.

Right now there seems to be a significant Axolotl/PEP/ratchet/OMEMO/olm schism[0] that I hope doesn't fracture decentralized IM any more than it is. App-store DRM v. Copy-left purism (not being derogatory) seem to be at the root. At least multiple parties are trying to work together here instead of forging ahead alone. I'm hopeful.

[0] https://github.com/anurodhp/Monal/issues/9#issuecomment-2080...

The point of Olm as an independent Apache-licensed double ratchet is absolutely not to fragment E2E, but just provide an alternative clean-room implementation for those who want it (and to be one that we can easily audit and build on for Matrix). We will do everything we can to ensure that Olm directly interops with whatever the OMEMO team ends up doing. Given Olm is written to be compatible with TextSecure this shouldn't be an issue.

Just to be clear: mismatched E2E is obviously the mortal enemy of interoperability. Which is why it's really exciting that so many systems are using Axolotl derivatives, and it's absolutely critical to ensure they can interwork.

Gchat was (and is) wonderful -- minimal and elegant. I never understood why Google was so hell bent upon trying to move the users from Gchat to Hangout. They would have enough data to know the number of times users clicked 'no' to moving to the new interface!

Hangout might work fine, but I don't like the brand. A "GChat" mobile App would have signified a fast minimal interface to me. "Hangout" just sounds like such a loaded word/service; I rarely open the app for regular chat.

In a rough string of events, at first Google changed the look and functionality of the way Chat contacts were displayed in the left pane of Gmail. Then came the constant bickering to move to the 'new' Hangout interface (from inside Gmail), which, for text chat users, was just a superficial and useless change. I liked the simple old look back then, and still do. After that came Google+, and more irritating notifications to 'update'. In the meantime a huge project Google Wave came and was taken down.

GMail and Google are still amazing, and I respect them. But somehow, few years back, these changes took away my confidence in Google that they always know the pulse of the market. I think it was a mix of overuse of data science and marketing speak that hurt Gchat the most.

I thought Google Wave had huge potential but the rollout was so poorly handled. It was a group app that only called people in by invitation, so I couldn't add my team members without them having to go through a signup and wait for approval process, killing all momentum.

Yeah, Wave created quite a buzz, at least within developers/early-adopters. It was complicated and heavy though. I didn't get fond of its features, for the few weeks that it existed.

I still click that button regularly. The "Google Talk" Gmail plugin still works better than the "Google Hangouts" one.

Who is building the open-source Slack? Four things are needed:

1. Good support for multiple active clients, including mobile. If I see a message on desktop, I shouldn't get notified on mobile. If I read on one client, when I reconnect on another, it should show me the convo starting where I left off. Etc etc.

2. Eternal history (ideally configurable by users/channels) with decent search.

3. A few basic bells-and-whistles over IRC: preview images, allow file uploading, snippets, emoticons, profile images for users.

4. Multiple "team" / server support in the client.

I had high hopes for http://shout-irc.com/, but it ended up falling short in a number of areas. Notibly, its plugin support is not very good, so it's quite hard to add the sorts of features that I mentioned.

There's a community forked version with more active developers, features, etc here: https://github.com/thelounge/lounge. Plugin support is still sparse, but there is a packages[0] POC branch, along with a wiki page detailing the ideal plugin/extension/package system[1]

[0] https://github.com/thelounge/lounge/tree/packages [1] https://github.com/thelounge/lounge/wiki/Package-system-desi...

Technically Mattermost is very interesting. Unfortunately I cannot figure out their licensing scheme and business model. The license file mentions several licenses: AGPL, Apache 2, and the MIT license. They seem to apply separate licenses to binaries that they publish vs the open source repository. Is there an implied open core business model somewhere? How do I know when Mattermost Inc will show up and demand money for a proprietary license because I've misinterpreted what parts of the mattermost software is AGPL licensed?


Why not ask them to clarify?

Mattermost is explicitly a self-hosted solution. Their license does not appear strange to me; you can either use their builds, or build from source and adhere to the AGPL.

The android client is very annoying to use as it doesn't follow the standard android UI guide lines. Can't swipe in the menu etc.

Yup, been looking into it the last couple of days because Slack is devilishly slow in China, and it seems to cover most of the stuff you'd want from slack plus the things GP mentioned. Really cool stuff.

Rocket chat is awesome. It even has giphy integration!

Well it would need a good design too. Let's not say that just piling on features would lead to success. Too many open source projects have already had that perspective... It needs to be fun to use with no learning curve and continue to be fun months down the road.

Although it's not open sourced, you should check out discord (https://discordapp.com/). Although our niche is gamers, lots of people use Discord for tons of other things. We've got all those things except search (but we're working on it!)

(disclosure: i work there)

It'd be nice if you all had a stronger story for how you're going to stay afloat long term. "Stickers, lol" isn't very much of one.

Exactly, a bunch of friends tried to move a chatroom from Skype to Discord, and I blew them off, because I didn't want to move my communication to an app from a company just hoping to get bought out by Twitch probably and shut down within a year. A closed source service with no business model isn't something anyone should even try, much less use.

Discord is great. We use it at my company.

Search is sorely lacking. Tab complete is buggy. But it's really great.

Really wish you'd open source it.

When Slack first came out, and everyone got all excited about it, I was quite skeptical. I've been using Skype (and lots of other IM systems) for years; do I really want or need something new?

The answer, for me at least, was yes: Slack is new, different, and better. And nearly all of that difference is because of a vastly better UI, on my desktop, in my browser, and on my phone.

So, did Google Chat work? Sure. Did it do the right things in a narrow technical sense? Absolutely. But without the slick, inviting, easy-to-use UI, it wasn't going to go anywhere. And now that Slack has critical mass, it's hard to imagine Google catching up.

Ultimately slack is just a proprietary IRC, with a solution for message persistence falling out its centralized design. IRCCloud and ZNC both solve the same problem. Its slick as hell, but still a walled garden.

Yes, this is my greatest regret and problem with Slack: Someone could have made amazing IRC clients (and servers), and kept it open to the world. It's a shame that a solved problem with open-source tools has been turned into a billion-dollar proprietary company.

I love Gmail and wish Hangouts got more love. Obviously Gmail is hugely successful in email, and an email address is identity for most services. On the other hand, mobile is where the puck is going, and the base identity for mobile is phone number. Hence, Allo and Duo.

I am loyal to Hangouts because everything I read and write becomes easily searchable. I don't want to lose all that history. And it also sounds like an interesting corpus for Google to do the machine learning thing. Obviously, it's also simultaneously terrifying.

Allo and Duo being new apps not only means shedding the extremely unrewarding work of migration / SMS integration / normal legacy from Gchat/Gvoice/etc, but also users immediately understand the Google Assistant is present in their non-incognito conversations. Google might sometimes be creepy, but more often than not Google will be helpful in the chat. I was wondering when I could have my search history be viewed as chat history, and I predict I'll use the chat interface more than google.com.

> On the other hand, mobile is where the puck is going, and the base identity for mobile is phone number.

I don't get this. Just because you're using a device that has historically been tied to a specific method of identification doesn't mean that you have to limit yourself to that? Should desktop chat clients start only identifying people by IP addresses?

Indeed. Nearly all phone-number-as-identity services fail at allowing multiple clients (Whatsapp and Signal have at least something, but not perfect either), which is probably the biggest issue I have with newer messengers.

And it makes changing my phone number more annoying, for IMHO no good reason. Allow people to configure their phone number for discovery if they want, but don't make it the primary identifier.

+1 to this. I have never wanted to bind my identity to my phone number and never will. This is an anti-feature to me.

> I was wondering when I could have my search history be viewed as chat history, and I predict I'll use the chat interface more than google.com.

I've started using the Skype Summarize bot in the Outlook website and it's pretty cool. Rather than going to a separate site and deal with subpar UI/UX you just paste the article URL in and you get your summary via the chat window. I was skeptical of all of Google's messaging platforms but if they can come close to providing me this functionality I'm on board. Getting things done via bots vs going to a website IMO is the future.

A really big fan of Gchat here. What I was amazed at in the software was, how reliably it worked no matter how less your internet bandwidth is.

The desktop GTalk app was tiny, handy and powerful. Back when I couldn't afford a wired internet connection in my home, I used to bridge my phone's 2G data to my computer and when nothing else worked with that tiny bandwidth, GTalk did.

Hangouts - is just sad. It loads visibly delayed. Every conversation you click at, again takes milliseconds/seconds to load. Never had this cognitive delay in GTalk. I miss it.

Before you dismiss XMPP and seek for alternatives that need at least another 5-10 years to be actually usable (looking at you [matrix]) you might want to take a look at how far XMPP has come in the last 2-3 years. The Android client Conversations (https://Conversations.im) is a prime example on what can be achieved with XMPP today. In band images, emojis, End-to-end encryption, group chats…

inputmice: I hear your Conversations app is really nice, and it's great to see XMPP is evolving well. Rather than being defensive about XMPP and badmouthing matrix, perhaps we can just bridge both ecosystems and both sides and clients benefit from wider reach? Especially when some tech like interoperable E2E ratchet implementations is of direct use for both ecosystems.

The two protocols have entirely different designs and philosophies and do different things. It's like claiming that NNTP competes with SMTP because you can uses them both to hold conversations. Please can we both just get along? :)

In terms of matrix's usability: i'd say it's been very usable for the last 6 months or so - and given the size and activity visible to the matrix.org homeserver, others seem to concur.

I'm not bad mouthing anything. It's just that Matrix doesn't solve any problems XMPP hasn't already solved or could have solved with an extension. Matrix is basically a pointer to a stream of messages. You could have easily made this into a XEP. In fact there have been ideas in the XMPP community called MAM subscriptions that are basically the same thing. Even if that extension would have been a radical change in C2S communication as long as S2S stays the same you could have built your protocol on an existing infrastructure.

I mean I rather have people use matrix than a closed system like WhatsApp or Signal. But I honestly don't see the point for developing a new protocol other than JSON over HTTP fits better into the zeitgeist and NIH syndrome.

Claiming that matrix needs 5-10 years to be 'usable' seemed to be unnecessarily and unproductively negative, hence my objection to badmouthing when we could instead be working together productively :) The last thing decentralised comms needs is in-fighting.

I think the root of the contention here is that you don't seem to understand what Matrix does - this is probably my fault for failing to explain it better to you in person at FOSDEM. It is not a pointer to a stream of messages. The whole point is to store arbitrary data (e.g. room history and state) as a directed acyclic graph shared over all the participating servers. It's a big distributed datastructure with eventual consistency semantics which happens to be usable for chat. Or any other kind of real-time requirements.

If you wanted to compare it to a XEP, then FMUC would be a better comparison than MAM subscriptions. And yes, you're right that one could have built it on top of the XEP stack of standards, just like FMUC did. We could also have layered it on top of IRC. Or IMAP. Or NNTP. Or ZMQ. Or MSRP. Or Psyc etc.

Instead, we chose to layer on HTTP in order to keep it as simple as possible - we simply don't need most of the abstractions that XMPP provides. And we believe it's easier for a protocol to get traction if it has a single monolithic spec which defines feature compatibility profiles for interop than if it's a huge collection of optional extensions.

In the end, these are both subjective opinions, but I see no harm in there being two different philosophies out there for solving the problem of interoperable communication. Especially as it's not a competition, given both can 'win' by bridging together.

I'm just wondering what makes someone look at an XMPP client like Conversations and say: "This is fundamental flawed let's completely reinvent the wheel. There is no way we can ever get a good UX out of this" Matrix might not be a bad protocol for Instant Messaging. But neither is XMPP. And XMPP already has an established infrastructure of public servers and a fairly large user base which will take Matrix at least 5-10 years to build up (That's were the 5-10 years were coming from).

So from 2012-2013 we maintained a service that ran on XMPP. It wasn't a fun experience. Had Conversations existed back then it might how shown us the light of how to build create a good and modern experience on top of XMPP. Instead, we swapped it out for a proprietary HTTP-based precursor to Matrix (called Glow), which worked astonishingly well for what we needed. So in 2014 we decided to build Matrix with the primary goals of:

1. decentralising the conversation so no single entity owns or controls it: being a federated communication database rather than a messaging platform. 2. making bridging a first class citizen (hence the name Matrix; it's designed to matrix together other conversations) 3. providing a deliberately monolithic spec to try to avoid fragmentation and help us evolve it relatively rapidly.

Now, I have huge respect for you in showing that it's possible to build a good UX on top of XMPP. And we don't think XMPP is fundamentally flawed. But we wanted to try a completely different architecture and design and see if it flies. As per the earlier comment I see it very similar to NNTP and SMTP. They can be both used to power conversations, but architecturally they couldn't be more different, and the world is big enough for both.

Genuine question: any idea how big the public XMPP federation is in terms of active servers and active users? Would be interested to know how Matrix compares.

conversations is really nice. thanks for making it. one problem i have with it, that gchat solves really well, is how it behaves when you have a desktop client and conversations open at the same time.

when someone using conversations writes to me, what i expect is that i get the message on my desktop, as well as on my mobile client. but conversations will ALWAYS ask the user where he wants to send the message, if on my phone or on my desktop client. this should not happen. it should just send it without the resource set, and let the xmpp server figure it out.

This is a confinement of OTR. OTR was never made for modern day instant messaging. Use OMEMO or send unencrypted messages and you won't have this problem.

> but conversations will ALWAYS ask the user where he wants to send the message

Must be a bug (or OTR requirement, as OTR doesn't work with multiple devices). XMPP clients shouldn't require sender to choose the recipient's resource, unless sender is explicit that they want to target a specific device.

Hangouts was horrible to me for just one reason - on the smartphone, it hid info on who is online right now.. perhaps this was designed to motivate us to send more messages, but it meant i could no longer easily know if someone might answer now, or if i better try sms/call/.. and then as of recently, Hangouts just fails to notify me of messages, or keeps re-notifying me of old ones, and now i barely use it any more.

Google+ had a similar design decision, when it showed (don't know if this changed) friend suggestions without indicating if those people actually use Google+, or if your adding them to a circle will just spam them to join a social network they don't (want to) use. it's understandable that Google might want to do these things to grow their platforms, but without tact and understanding for what the users really want, they're achieving the opposite.

At least now they've sort of restored the online presence indicators with the "last seen XXX ago", but I still don't understand what can be so hard about searching hangouts conversations on the phone. I can search through emails and through SMS. Why not hangouts?

Oh wow, we'll be adding three more services to this -- https://sameroom.io/chat-timeline.pdf

No words.

I may be a resistant one, but I prefer and still use gtalk/gchat/hangouts over slack or any other tool. Slack requires either another tab, a new mobile app or a desktop app, which isn't that great when switching between organisations. At least on my Ubuntu Linux.

Gtalk on the other hand, although searchable, it's not that easy to find what you want. Usually the search result points you into the middle of the conversation and you need to use the damn infinite scroll. And chats in hangouts (video/audio) aren't stored.

If Gtalk could evolve to get the benefits of Slack while keeping it simple, that would be great IMHO.

To this day, ICQ is still the best messenger I've used.

May I ask what made it the best messenger for you? I hated every second I spent on ICQ. The ad-infested client, the fact that if someone else thought 24px purple comic-sans was their identity, I would have to deal with it..

The only thing that I actually liked was that by pressing backspace on an Emoji it was converted back to its text version.

I mean pre-ad days.

I think gchat had a horrible ux.

Slack is better compared to a simple to use irc. In fact the only thing it really has over irc is UI/ux.

What do you think made it horrible?

I think it had a simple UI, which for many things worked very well. When I managed the Technical Support for a university using Google Apps for Education, gchat's simple interface was kind of a blessing in that everyone on the campus had it, it was unobtrusive, automatically saved and searchable (though the search could have used some improvements), and you could make calls/video calls without leaving your email.

When it switched to hangouts, a lot of the simplicity left with it in favor of a more social experience; large user-pics on by default (at the beginning I don't think you could customize this either), the windows were significantly bigger, and the text box lost space to the emoji/add picture buttons.

It was a pretty simple, out of the way, and concise chat option with, as far as I could tell, nothing really hidden. What you saw is what you got.

Because this is how hangouts looks on a 4k monitor: https://imgur.com/lPkNnhR

This is its default size and behavior when in a browser: https://imgur.com/bXL1Ezn

This. Is. Horrible.

I have some very, very unkind words for the person or team or manager who decided to make hangouts show as few lines as possible. It didn't used to be this way.

You're mixing GChat with Hangout. GChat was(is) minimal and very useful.

You're right. Point still stands that google's design choices are god awful these days, though.

People complain about that with Apple too 'these days'. So if the biggest mobile players and one of the biggest web players are bad at design/ux is it just the few people in the world who care about this kind of thing all being on HN or is there some objective measure for this? I'm asking because I don't see it and I know almost no-one who does, then again I am and know mostly hardcore techies (who prefer text only interfaces) or people who do not work in IT and both really do not see it.

I just give the conversation its own browser window, then I resize at will. Sure the defaults could be better, but it makes more sense to use the window manager anyway.

The only thing Slack has over IRC is a better web client and history.

It really makes me sad that it's 2016 and we haven't just updated IRC. Text is cheap: storing every byte every written on an IRC server would cost, essentially, nothing.

Slack makes mobile work in a way that IRC didn't. IRC axiomatically assumes you're on a stable connection. There weren't any widely deployed solutions that allowed you to intermittently connect and see the conversation that passed while you were gone inline.

> The only thing Slack has over IRC is a better web client and history.

I'd say that there's a lot more to it than that. IRC isn't intuitive for new, modern users. Take login and password recognition using one of the many NickServ options, for example.

But you can abstract that stuff in the client with a few lines of code and the user never needs to know! All the IRC web clients do it. mibbit used to be great, and then they mysteriously disappeared...

Mysteriously disappeared? I don't know anything about it's history but I happen to use something that, at least, goes by that name [1].

[1] https://client02.chat.mibbit.com/?channel=%237daystodie&serv...

What? For irc you can connect without an account, how is that harder than forcing people to register on github first?

Oh, you mean its easier for people who already have github account? Who are these people that create accounts on a hosting service for one of the more complicated version control systems but find connecting to ftp servers and entering cli commands too daunting?

If you want to talk about confusing, in gitter I can navigate to a room and see what happens in it but I need to press an extra button to actually be able to talk in it? What? Rooms, private chats and /me? Many parts of gitter doesn't make sense if you don't know the whole chat paradigm that irc created.

Gitter derives it utility purely in the better web client and its custom built integration with github.

botbot.me does just that (store every byte that goes over the IRC server).

I agree -- I was extremely happy with my all-in-one IRC / XMPP app many years ago. Now everything is fragmented to the point of uselessness in the name of a few bells and whistles. Or maybe it's corporate greed. Either way, it's infuriating.

> I think gchat had a horrible ux

Even more reason to keep it compatible with XMPP so that one could use it with his favorite XMPP client.

XMPP is a zombie protocol. Yes, it has clients that have better implementation of instant messaging and presence than any other, but it falls apart with real time communication such as voice and video (lol jingle) and there is no practical way of iteroperating with the PSTN. Further, federation of plain text and basic presence worked, but rarely anything more. Connecting with federated users makes no sense to end users, first they have to know it is possible, then they have to figure out how it works and then they learn most features don't work. Even if that wasn't awful enough, it was all dropped by the providers and no longer works. All commercial platforms are moving away from the protocol, and SIP is now the standard. Problem is that it isn't a great chat protocol for end devices (no standard concept for buddy lists being stored on a server or mobile clients, but many proprietary extensions work well). As for slack, it is a group chat with slick interface, other than the bizarre account/domain design. It has no encryption of data at rest, and I really wouldn't use it for confidential data. If you are going to use a proprietary closed source solution, at least consider using Cisco Spark. Now Matrix, it is almost too good to be true, grass roots open standards, federation that makes sense, encryption by design and doesn't lock users into yet another captive island (YACI?). It is also built with the concepts of accounts/SSO, true federation, real time communications in mind. I dream of the day we can kill the PSTN, but with something even more open... Sadly none of the commercial players today are interested. Any one company that thinks they will do it on their own has fallen for their own delusions. Microsoft Skype, Whatsapp and a hapless Google Hangouts... What a mess.

Nope, totally wrong. Slack moved in at the exact right time for Slack to have moved in. The world needed a chat app that was easy to jump into and could be separate from their private world. Gchat was not and could never be that, because Gchat was associated with personal accounts.

It's been a while since we've had a decent chat client that we could use for work (no, you would not get designers, marketing and sales to use IRC), and Slack came up at just the right moment to make the rounds, and they know it. You can see it in the enormous marketing push they're making. They want to seal the deal and seal it quick, because, damn, it's not that hard to replicate that platform.

No, Gchat was not Slack before Slack. It was just another chat client that was limited by its auth scope.

Gchat was not and could never be that, because Gchat was associated with personal accounts.

What about Google Apps for Work? It's been around for a decade.

Keeping a separate work account is easy. Just create one. I don't understand why people just don't do this more often.

> And there are even still some holdout users on old-style Gchat.

I'm not sure if I'm one of those holdouts? I've been using gchat, mostly over XMPP (using adium), and sometimes in Gmail. I frequently search chat history in Gmail.

I didn't realize that gchat had such a tumultuous history.

Yeah I still use it daily, and now I'm worried it's going away. I wonder how many holdouts there are out there?

I rely extensively on Gchat via Adium.

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

Google nows that, but improvements upon Gchat is not best fit for OKRs and Googler's future resumes. Why not invent another wheel so you can show off next GoogleIO?

Slack nailed it with the notion of teams. You invite someone into a team and there's an instant tachonomy of conversation to join. The ability to be in multiple teams at once is hugely helpful as well.

Yes but each requires its own username/password combo!

This. Hideous and awful.

Tachonomy isn't the word you meant to use there. In fact, it's not a word.


I remember Gchat as a constant struggle to try and turn off unwanted functionality in Gmail.

I also remember Gchat as being one of a a number of a number of instant messaging options from Google that had very unclear market position and operability (I honestly didn't know that gChat was talking with Google Talk, I thought those where different)

At least now, it is only Hangouts I can't log out of, and at least it doesn't show up in gmail.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact