Comment by lewisl9029 | Hacker News Reader

Comment by lewisl9029 | Hacker News Reader

Parent Full thread

One thing I'm curious about regarding matrix.org:

As a federated protocol, is there anything at all in the spec that would discourage someone from piggy-backing on the federation to acquire initial users, goodwill and a head-start on features, and then locking users in once they've gained enough momentum by making proprietary modifications?

You know, the same tactic countless companies have pulled with XMPP?

I've been eyeing matrix.org for quite a while now, but it seems to still lack a "killer" client app. One that can at least match the features, polish, stability, usability and platform ubiquity of existing proprietary messaging apps, an app that can help matrix.org grow user mindshare and keep it.

The open source community just doesn't seem to do a very good job of churning out these kinds of consumer-oriented apps. And if some company ends up building such a "killer" app for matrix.org and gains momentum, they'd have some very sweet incentives to lock in their userbase.

Oh, in terms of the risk of federation causing lock-in: it's inevitable that folks will add domain-specific extensions to try to force people to use their platform. This is no different to me sending you an attachment over email in some proprietary vendor-specific format (e.g. .ppt) which obliges you to install PowerPoint to read it.

This can be used for both good and evil. The evil scenario is above - rather than using an open standard like ODF, it provides a route to promote vendor lock-in. The good scenario is that it provides extensibility for technology that simply isn't standardised yet, and gives vendors a way to differentiate their product. For instance, if Oculus jumped on Matrix and started using it to negotiate VR collaboration spaces, it almost certainly wouldn't work with any other vendor at first... but it's good news for end-users who get a cool feature which some day may be standardised across all of Matrix.

The bottom line is that as long as everyone implements the common base line use cases in an interoperable fashion (i.e. IM and VoIP), then vendors having freedom to put proprietary/experimental stuff on top is just a necessary evil... as long as they don't break the baseline. It's up to us as consumers to then encourage vendors to make their extensions standards rather than exploit them for vendor-lockin. It really is an identical situation to email and MIME.

The example 'Matrix Console' iOS & Android apps are aesthetically very ugly, but still very functional and usable from a geek perspective. Meanwhile we're currently replacing the example Matrix Angular webapp with a Matrix React webapp which will improve the performance enormously.

In terms of polished UI/UX, we were hoping the community would fork the example apps and put the necessary polish and usability on them. Features should (almost) all be there, and we're doing our best on platform ubiquity.

However, as ex3ndr's comment below shows, there are people still creating their own per-app proprietary protocols rather than building on something like Matrix.

So in order to help bootstrap Matrix, am sure we'll end up building a killer client app sooner or later if nobody else does :)

Thank you for the detailed reply.

Glad to hear you guys have plans to build a client app if needed.

Regarding matrix home servers, are users expected to just trust that they won't read/leak/share their private data (contacts, chat history, profile info, etc)? Or do home servers store user data in an encrypted form so users can just treat them as a zero-knowledge storage server without having to trust them at all? (I couldn't find storage encryption mentioned anywhere in the spec or anywhere on the faq, so I'm assuming it's the former)

If it is the former, are there any plans to move towards the latter? As we've seen in the case of email, even federated services tend to eventually gravitate towards a usage model where a handful of very large service providers service an overwhelming majority of users. I don't think allowing these service providers access to the private data of all of their users is in the best interest of the matrix community.

For now, it's an implementation detail (rather than specced) as to how homeservers persist their state. The synapse implementation stores all data unencrypted in sqlite or postgres - /however/ that data may be end-to-end encrypted (we are releasing our e2e support over the course of this week - the first bit of the puzzle can be seen at http://github.com/matrix-org/olm). We should probably store all data AESed in the db to avoid casual snooping too.

This doesn't obfuscate metadata like room membership or profile data however; but fixing this is Hard. For now it's just a fact of life that Matrix servers have visibility on communication metadata - i.e. the identities of who talks to who, and when, and with what kind of event. In future we may support better privacy preserving semantics by evolving the federation architecture: eg running homeservers on clients and using Pond-style hidden Tor services for message transport, or layering on GNUnet as a transport. We've tried to design Matrix to support this sort of evolution, but right now today Matrix provides the same level of metadata privacy ss (say) an IMAP or SMTP server.

Reply on news.ycombinator.com