Live data from Hacker News

Matrix 2.0: The Future of Matrix

matrix.org

11–20 of 283 posts

Re: Matrix 2.0: The Future of Matrix

#12

> Therefore to use Element X, you need to be running a homeserver with Sliding Sync support, which (for now) means running a sliding-sync proxy which bolts Sliding Sync support on to existing homeservers. I am excited to try out Element X, but I do not want to administer yet another service, namely the Sliding Sync proxy. From a practical perspective, Sliding Sync (MSC3575) is still on the level of a proposal/experim…

Matrix evolves as a protocol by folks proposing new APIs (e.g. MSC3575), implementing them, showing that they work, and making the case that they should be merged into the main spec.

Sliding Sync is an interesting case in that it clearly does work, and it kicks ass - but it turns out to be unnecessarily complicated for the subset of features that you actually need when implementing something like Element X (which is my fault entirely, fwiw). However, should we hold off on putting it in people's hands while we sort that? Nope. Is it a pain to temporarily run a proxy shim service while the protocol stabilises? Yes. It's like running a SPDY or QUIC-aware reverse proxy in front of a webapp that only speaks HTTP/1.1 while waiting for SPDY to be ratified as HTTP/2. Sure, it's another moving part to look after, but the spectacular improvement is likely worth the pain. YMMV though :)

Re: Matrix 2.0: The Future of Matrix

#13

> Therefore to use Element X, you need to be running a homeserver with Sliding Sync support, which (for now) means running a sliding-sync proxy which bolts Sliding Sync support on to existing homeservers. I am excited to try out Element X, but I do not want to administer yet another service, namely the Sliding Sync proxy. From a practical perspective, Sliding Sync (MSC3575) is still on the level of a proposal/experim…

Why is sliding sync a separate service and not just part of synapse itself?

Re: Matrix 2.0: The Future of Matrix

#14

Is Matrix simple enough now that I can invite my grandpa/grandma and they will be able to join? How does ease up sign up and use compare to discord? Assume that I make the choice of which client to direct them to.

Matrix itself is a protocol, so is as hard or easy to use as the client that you use to access it.

Matrix 2.0 is all about demonstrating that a really really fast, mainstream-grade app can be built on Matrix, in the form of Element X: https://element.io/blog/element-x-ignition/. However, right now Element X is intended for existing Matrix users - so unless you have a bleeding edge homeserver, sign-up doesn't work yet. So it's not quite in grandma/grandpa territory yet... but once you're in, it most certainly is.

Re: Matrix 2.0: The Future of Matrix

#15
Thoughts on how this will get us towards when libre software privacy&security type people are ready to advise friends to move to Matrix for personal communication?

(To be clear, the platform has to be all open source and open standards, actually decentralized, guided by those principles -- not an effectively proprietary play even if nominally open. For example, you should be able to get all the same functionality with Element, Fluffychat, Thunderbird, and other user agents, and with any home server, both now and on an ongoing basis. And the user agent implementation difficulty should become tractable enough, in terms of size&complexity and specification, that one person could write a new one -- not like Web browsers have become, where there's mainly only one, that company has been funding the runner-up, and that company can pretty much dictate 'standards'.)

Re: Matrix 2.0: The Future of Matrix

#16

> Therefore to use Element X, you need to be running a homeserver with Sliding Sync support, which (for now) means running a sliding-sync proxy which bolts Sliding Sync support on to existing homeservers. I am excited to try out Element X, but I do not want to administer yet another service, namely the Sliding Sync proxy. From a practical perspective, Sliding Sync (MSC3575) is still on the level of a proposal/experim…

Why is sliding sync a separate service and not just part of synapse itself?

It's currently still a proposal to the spec, and it is not yet part of the Matrix protocol.

Re: Matrix 2.0: The Future of Matrix

#17

> Therefore to use Element X, you need to be running a homeserver with Sliding Sync support, which (for now) means running a sliding-sync proxy which bolts Sliding Sync support on to existing homeservers. I am excited to try out Element X, but I do not want to administer yet another service, namely the Sliding Sync proxy. From a practical perspective, Sliding Sync (MSC3575) is still on the level of a proposal/experim…

Why is sliding sync a separate service and not just part of synapse itself?

Because the API is still evolving, and it's also useful that it supports other homeservers than Synapse. It's also written by an entirely different bunch of people (it's effectively written by the Dendrite team rather than the Synapse team).

Once the API is stable I'm sure all the homeservers will implement it natively. Until then, think of it like a reverse-proxy that lets an HTTP/1 webapp talk HTTP/2 to the outside world.

Re: Matrix 2.0: The Future of Matrix

#18
It's quite disappointing that there's huge ongoing work around reinventing clients from scratch where the basic functionality of not ringing all my devices while I'm using only one of them [1] is still not there (bug open for years), despite it being a pretty simple fix.

[1] https://github.com/vector-im/element-meta/issues/360

Re: Matrix 2.0: The Future of Matrix

#20
post #2

I always get so confused by the naming between Matrix and Element. I get that Element is the client, but I honestly thought that the name Matrix for the server (or is it just the standard for the protocol?) was sunset. Great service though and hope if gets UX improvements too, as Discord and Slack keep getting more clutter.

Element is to matrix what chrome is to http. The most used client for that protocol.

Element is the trading name of a company, of three clients with mostly-independent codebases written by that company (web, android, iOS; not counting the two Element X rewrites), and of a hosting service (EMS).
Post reply on HN