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...
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 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.
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.
> 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.
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.
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.
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.
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.
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.
http://www.cnn.com/TECH/computing/9909/06/aol.vsms.idg/index...
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.
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?
”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.
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.
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?
My experience with the matrix.org community has been very pleasant so far. Keep up the good work, folks!
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.