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 :)
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.
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.
I would then ask why it isn’t integrated into Dendrite
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).
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 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.
https://github.com/spantaleev/matrix-docker-ansible-deploy/b...
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?
Perhaps the problem they're trying to solve warrants that complexity, but my particular use case doesn't. I just run XMPP now.
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 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/experiment and I wish that we would be having this conversation about Element X after it becomes usable with any spec-compliant server.