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

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

Yes, it is just unfortunate that it is not clear enough to more people (such as the_common_man below) that Sliding Sync is only at the MSC stage at the moment and not part of the Matrix spec.

I am glad that at least Element X allows this MSC to improve and for those nits you have mentioned to be resolved.

Sliding Sync is just your old bouncer with lip service and a fancy name, because the Matrix protocol is now officially deemed hopeless to be implemented efficiently on the client side, hence the need for a proxy to maintain your "client state" i.e. your client running on the server.

I'm really tired of the litany of buzzwords and excuses that the Matrix team comes up to cover-up this large sunk cost fallacy of a protocol. Nobody needs a distributed graph database and state resolution to prop-up a chat system. It has not proven to have any real-world benefit nor served to build a niche in which Matrix is in any way better than the competition. It's been a failed experiment for about 10 years with no end in sight. At what point does the community wake up to all the nonsense?

I 100% agree with this. I wanted to like Matrix, and I ran synapse for a while, but the operational aspects of it are an order of magnitude more complex than XMPP.

Perhaps the problem they're trying to solve warrants that complexity, but my particular use case doesn't. I just run XMPP now.

This comment makes no sense. The database replication has nothing to do with sliding sync. Sliding sync is about replacing the client to server protocol, and database replication is the server to server protocol.

Its flat wrong to say that it can't be efficiently implemented on the client side, the server side of the Api is the problem, not the client.

I just set it up. Wasn't that difficult:

1. Added a new postgres db and user 2. Added a new dns name 3. Added a new cert for the new dns name 4. Added a new vhost to nginx to proxy to a new port using the new dns name and cert 5. Added a simple docker-compose to my config 6. Added a snippet to my .well-known/matrix/client

Don't imagine it will take much maintenance. Container will be updated along with the rest of my containers, and the existence of the service doesn't change anything for any existing clients that don't support sliding sync.

The most important thing is to keep it updated, as we're fairly rapidly iterating on it, and most of the Element X bugs we've seen have actually turned out to be a stale Sliding Sync proxy deployment. Glad it was fairly straightforward.

Agree... i don't think there's a time i have "docker compose pull" and a new version hasn't come up.

The fact that this is independent of any server implementation (read Synapse) means you can release much more frequent.

Choosing to use a proxy here was the right decision.

FWIW, if you use matrix-docker-ansible-deploy, enabling the Sliding Sync proxy involves just adding one line to your configuration (for the most common setup).

https://github.com/spantaleev/matrix-docker-ansible-deploy/b...

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.

> it's effectively written by the Dendrite team rather than the Synapse team

I would then ask why it isn’t integrated into Dendrite

...because then Synapse wouldn't be able to use it?

I would guess it's so the same functionality can be used with other Matrix servers without having to rewrite the whole thing

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

Well you can just wait. But the proxy is really lightweight and doesn't require maintenance.

Until there's an incompatibility, upgrade, exposure, memory overflow, or some other security issue/exploit. Unless you're saying that it's immune to everything and will never experience a change or issue.

I'm pretty sure that all those issues will affect sliding sync whether or not it's integrated in Synapse. In fact, some people might actually prefer the fact they can operate it separately and restart/maintain it separately from their homeserver :)

> I'm pretty sure that all those issues will affect sliding sync whether or not it's integrated in Synapse.

Of course.

My argument isn't that it won't happen, it's exactly the opposite, that it will. My point is that, now you need to manage 2 things vs 1.

> In fact, some people might actually prefer the fact they can operate it separately and restart/maintain it separately from their homeserver :)

Of course. But it's misleading to say that it won't require maintenance (which is what I replied to).

I'm sorry. I don't really do maintenance on my synapse either (few users, no problems), so I should have figured that usually you do, and then also for the proxy.