Gchat Was the Future of Messaging, but Google Didn’t Know
slate.com
slate.com
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.
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.
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.
http://matrix.org/docs/spec/r0.0.1/client_server.html#oauth2...
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.
Did any Google engineers ever reveal Google's true intentions for shutting down their XMPP offerings?
It is definitely not a high quality XMPP experience. If you want to use XMPP, you should probably be using duckduckgo's XMPP offering.
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'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.
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?
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.
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.
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.
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.
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.
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.
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.
Build a whatsapp bridge for matrix? I mean, it's built for the exact case where people aren't "on" it.
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.
http://www.cnn.com/TECH/computing/9909/06/aol.vsms.idg/index...
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.
Today at least they are using web technologies and I get to use Facebook's Messenger, WhatsApp, Hangouts and Slack on Linux without headaches.
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.
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'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.
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.
Wouldn't this still be centralized to your home server?
It's my smartphone.
Can I just run a 'homeserver' on that and be connected?
I mean, a python app for posix systems is not really close to being run on unrooted android and iOS.
Do you think that would be possible?
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?
Heck you even had the option to federate private servers so one could address users across hosts.
If only we would've chosen the right technology, people would've used it.
> NOTICE: This document is Humorous. It MAY provide amusement but SHOULD NOT be taken seriously.
”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.”
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.
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.
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.
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/
The "standard library" of messaging has expanded a lot lately.
My experience with the matrix.org community has been very pleasant so far. Keep up the good work, folks!
> You seem to be shaking the phone in frustration. Would you like to submit a bug report?
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.
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.
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 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 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).
Not to mention that XMPP is a standard, not a competitor.
This is like saying that modern companies are monopolizing against SOAP or YAML.
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.
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.
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.
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.
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...
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).
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 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?
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?
Historically, Google drops features when they don't make financial sense or when they give leverage/advantage to competitors.
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.
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 :/
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.
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.
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.
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.
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.
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.
But then again in Europe iPhone market share is much lower.
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.
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).
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.
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.
It's got a few years yet, but POTS and mobile are already legacy, they just don't know it yet.
Better hope Apple shareholders don't find out!
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.
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.
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.
You see it today with drivers having both Uber and Lyft apps open.
In which country? Because I have tons of messengers installed and so do most people I know outside the US.
Sure, I have messenger and hangouts and telegram as well, but WhatsApp is like a primary mode of communication.
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.
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.
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.
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.
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.
AFAIK they only dropped federation and support, but I still can connect with any XMPP client.
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".
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).
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...
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.
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.
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.
https://github.com/mattermost/platform/blob/4ae72ad1a878fdf1...
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.
[0] https://github.com/thelounge/lounge/tree/packages [1] https://github.com/thelounge/lounge/wiki/Package-system-desi...
(disclosure: i work there)
Search is sorely lacking. Tab complete is buggy. But it's really great.
Really wish you'd open source it.
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.
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.
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.
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?
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.
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.
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.
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.
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 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.
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.
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.
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.
No words.
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.
The only thing that I actually liked was that by pressing backspace on an Emoji it was converted back to its text version.
Slack is better compared to a simple to use irc. In fact the only thing it really has over irc is UI/ux.
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.
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.
[1] https://client02.chat.mibbit.com/?channel=%237daystodie&serv...
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.
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 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.
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.
Even more reason to keep it compatible with XMPP so that one could use it with his favorite XMPP client.
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.
What about Google Apps for Work? It's been around for a decade.
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.
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?
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.
https://www.dropbox.com/s/55nr2tggbu9rw4q/slackingoogle.png?...
(If there's anyone from Google here that likes the idea then drop me a line at ron.reiter@gmail.com)
You can perfectly chat with emails, the problem are that all clients make you use emails as digital letters instead of chats. But you could perfectly imagine an email client doing what gchat used to do.
It's more a metter of perception. When you click on a mail, it takes a lot of time to type, then your UI have a delay to say it's sent, then you have this time taken by many clients to move your mail to the proper folder. But a proper mail-chat client would just make the message appear as sent, then to all the stuff in background, and you would just not see it slower than other chat. The time people take to answer you message is usually the bottleneck, not the network.
Users are extremely sensitive to latency. I would ditch a chat client with any real latency in a heartbeat.
https://play.google.com/store/apps/details?id=com.pingapp.ap...
Unfortunately, my colleagues insist upon using Skype instead of email, apart from the few I've persuaded to use Google hangouts instead.
Something secure, flexible, workable, and open needs to replace it.
I kinda liked what Moxie once wrote: the notification area of your mobile device is the new multi protocol client and since most IM services are using identifiers like phone number or email address instead of user names, the barrier to switch a service is lower. This is the one big advantage to use the user's address book as a social graph for IM.
Chat itself should now be viewed as a commodity, it's the features that's built on top of it that will differentiate one platform over the other.
Enterprise chat used to be a differentiator, but everyones doing that now too.
I think document sharing (Dropbox, Google Drive) and chat are basically in the same place right now in that both have been democratized and both have an over saturation of similar services.
Interestingly (to me, at least), this seemed to be pretty reasonable. No one I knew in Canada had AIM, except if they talked to Americans regularly. MSNM was very very popular, though. And ICQ before it.
I can understand why they dropped XMPP. I'm not sure if they really violated their 'don't be evil' motto as much as they recognized that other services were improving on their dime.
I like Slack for corporate environments, but IRC is still top dog when it comes to interest-based real-time communities.
One feels like IM and the other feels like IRC.
ICQ was the future of messaging
IRC was the future of messaging
Smoke signals were the future of messaging
The author's point is that Slack, Facebook chat (the dominant force nowadays), and many other such applications descend in lineage from Gchat, which preceded all of them by many years.
I thought gchat was an astonishing thing when it came out-- I couldn't believe I could just seamlessly chat with anyone through my email, and have it archivable and searchable. I spent years lamenting that very few people I knew used it. I am one of those hold-out classic style users as described by the article. I can still dream.
It might be commonplace now, but gchat was the first of its kind for an in-browser experience, and it was incredibly well-implemented given that it was 2005. Worked perfectly. Google did indeed have something big, and they never promoted it or advanced it in such a way as for it to gain popularity, despite the massive gmail userbase. The fact that even now gmail has over a billion users and still gchat is mostly overlooked and unused is just sad, a truly impressive failure.
Almost all common chat clients are based on one of these technologies.
The most straight forward protocol to implement is certainly IRC. It works very well for group chats and is used by many open source projects and in house usage. FBchat and Gchat are based on a slightly non-standard XMPP, at least started from that point and turned less and less open.
Maybe I am a forerunner, I used chat a lot more several years ago, and nowadays write a lot more (short) emails or just talk in person (or over VoIP with video). On the other side, we will chat/talk a lot with our personal software assistent in future.
Then a lot of people would be claiming Google was being dishonest and tricking its users.