points by mike_hearn 10 years ago

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

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

1. Nobody used federation.

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

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

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

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

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

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

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

Freak_NL 10 years ago

> […] 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).

  • tdkl 10 years ago

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

  • mike_hearn 10 years ago

    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.

    • dredmorbius 10 years ago

      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.

      • nine_k 10 years ago

        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.

      • mike_hearn 10 years ago

        Phones are dying?

        Better hope Apple shareholders don't find out!

        • dredmorbius 10 years ago

          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.

    • 0x006A 10 years ago

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

    • Freak_NL 10 years ago

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

cm3 10 years ago

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

  • mike_hearn 10 years ago

    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.

    • cm3 10 years ago

      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.

      • mike_hearn 10 years ago

        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.

        • cm3 10 years ago

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

    • kuschku 10 years ago

      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.

      • aiiane 10 years ago

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

        • cm3 10 years ago

          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.

    • petra 10 years ago

      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 ?

      • mike_hearn 10 years ago

        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.

    • inopinatus 10 years ago

      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.

herbst 10 years ago

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 :/