Hacker News Reader

Comment by Arathorn | Hacker News Reader

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

View on HN

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