6 ms·

> 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

by weisser 10y ago

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

zanny 10y ago
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. http://matrix.org/docs/spec/r0.0.1/client_server.html#oauth2-based http://matrix.org/docs/spec/r0.0.1/client_server.html#oauth2...
- Arathorn 10y ago
  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#fallback 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.
- Freak_NL 10y ago
  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.
  - StavrosK 10y ago
    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.
    - Freak_NL 10y ago
      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?
      - zanny 10y ago
        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.
      - StavrosK 10y ago
        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.
- lqdc13 10y ago
  So what you're saying is that username/password is still the only choice for privacy minded people.
  - chris_wot 10y ago
    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 https://developers.google.com/talk/open_communications
    - Freak_NL 10y ago
      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?
    - smoyer 10y ago
      I'm still using XMPP to connect to GChat ... I use it every workday (via Pidgin).
      - chris_wot 10y ago
        One day it will go away...
      - forand 10y ago
        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-google-talk/ https://xmpp.org/2015/03/no-its-not-the-end-of-xmpp-for-goog...]
- JupiterMoon 10y ago
  We are pretty much past needing to remember them. Checkout password managers. There are lots of options in that space these days.
Perceptes 10y ago
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.
- ucy 10y ago
  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.

by weisser 10y ago

zanny 10y ago

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. http://matrix.org/docs/spec/r0.0.1/client_server.html#oauth2-based http://matrix.org/docs/spec/r0.0.1/client_server.html#oauth2...

Arathorn 10y ago
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#fallback 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.
Freak_NL 10y ago
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.
- StavrosK 10y ago
  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.
  - Freak_NL 10y ago
    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?
    - zanny 10y ago
      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.
    - StavrosK 10y ago
      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.
lqdc13 10y ago
So what you're saying is that username/password is still the only choice for privacy minded people.
- chris_wot 10y ago
  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 https://developers.google.com/talk/open_communications
  - Freak_NL 10y ago
    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?
  - smoyer 10y ago
    I'm still using XMPP to connect to GChat ... I use it every workday (via Pidgin).
    - chris_wot 10y ago
      One day it will go away...
    - forand 10y ago
      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-google-talk/ https://xmpp.org/2015/03/no-its-not-the-end-of-xmpp-for-goog...]
JupiterMoon 10y ago
We are pretty much past needing to remember them. Checkout password managers. There are lots of options in that space these days.

Perceptes 10y ago

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.

ucy 10y ago
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.