exciting to hear! I only wish i had more time to contribute.
Has there been any movement on migrating away from long polling (#475)? I didn't see anything about it in the announcements or comments despite such a big milestone
Matrix 2.0: The Future of Matrix
141–150 of 283 posts
Re: Matrix 2.0: The Future of Matrix
#142> 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…
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.
Re: Matrix 2.0: The Future of Matrix
#143Earlier quoted context omitted.
Yeah, that's great for me, but doesn't help me when everyone else is using the hosted stuff :)
Ok, I'll bite, what even could be the alternative here then? You want something without big funders, totally OSS, and extremely friendly for grandmas? Feels like one of those "you can only pick two" type things to me, but would love to learn that's not the case.
Its fashionable in the leftist world to compete to take the most radical position you can.
You described the goal, yeah, that would be pretty wonderful, like unicorns, flying pixie dust and other things that don't seem to exist as of yet.
Re: Matrix 2.0: The Future of Matrix
#144Earlier quoted context omitted.
https://thomask.sdf.org/blog/2016/12/11/riots-magical-push-n... is a great blog (back when Element was called Riot) explaining how it works :)
The gist of it seems to be that Synapse/Dendrite calls home to the Matrix Company, which in turn pays Google to send a notification. That's awfully nice of them, but does not really leave any room for success. I take it larger clients with security requirements roll their own clients, and this is part of the business case?
It’s more that “whoever built your client has the keys to send push to it, so your synapse calls home to them.” And yes, that means that paranoid types need their own clients, and that is indeed a service that Element offers.
Re: Matrix 2.0: The Future of Matrix
#145Re: Matrix 2.0: The Future of Matrix
#146exciting to hear! I only wish i had more time to contribute. Has there been any movement on migrating away from long polling (#475)? I didn't see anything about it in the announcements or comments despite such a big milestone
Low Bandwidth Matrix is the answer to that, and it’s currently on hold unless it gets funded: https://matrix.org/blog/2021/06/10/low-bandwidth-matrix-an-i...
It might also get changed as part of Sliding Sync refinement.
Re: Matrix 2.0: The Future of Matrix
#147Earlier quoted context omitted.
One of the big problems as I see it is that all notifications on iOS must be proxied via APNS and those can only be sent by the app publisher, so all home servers must send their iOS notifications to Vector (the Element publishers) to be sent to APNS and on to an iPhone or iPad. This is a centralized point for surveillance of metadata. I also do not know how much information is actually contained in the notification…
Then everyone should just roll out their own app… this seems like an EU-regulation-needed situation.
This requires paying about $10/month to Apple and doxxing yourself with a lot of PII.
It also requires that you as a homeserver sysadmin a) have a Mac, b) install Xcode, c) know how to modify and compile iOS applications, d) want to deal with rebuilding and reuploading and re-seeking app approval on major API changes because long-un-updated apps are not allowed in the App Store, etc...
Re: Matrix 2.0: The Future of Matrix
#148There's no web version of element X though? It's what I use most of the time. I'll try the Android app anyway, I've been having a really annoying bug with the normal one anyway that hasn't been fixed for a year. So perhaps X doesn't have it.
Element X works pretty well on macOS as a desktop client if you have an Apple Silicon Mac. Otherwise, the big Element Web rework is yet to happen. On Android, I can almost guarantee your bug will be fixed: Element X Android doesn’t share any code with Element Android at all, as far as I know (given the former is mainly written in Rust, and the latter is all Kotlin)
Ah ok no I don't have a Mac, I use FreeBSD :)
And thanks I'll try that out!! I really hope it fixes that sync bug. Thanks for all your work on it. It's a great platform.
Re: Matrix 2.0: The Future of Matrix
#149Looks like there's an open protocol and an open source client implementation for video calls. https://github.com/vector-im/element-call
This is great! Jitsi has never clicked for me. I tried it a few times, and read about it, and was never excited about it. I just tried Element Call, albeit an empty room, and the UI feels right.
Re: Matrix 2.0: The Future of Matrix
#150How Matrix decentralisation is an improvement over Jabber's decentralisation? (disclaimer: I have no knowledge about neither spec, I'm not suggesting Jabber was better)
Jabber core protocol (XMPP) is kinda like SMTP. It deals with transmission of messages between two peers. Just like with SMTP, you can federate servers, so they can exchange messages between each other. And the similarities don't end here. XMPP doesn't have built-in support for encryption (apart from the basic TLS encryption for the transport layer), it doesn't have support for message archiving and chat history sync…
Most of criticism of XMPP with regards to fragmentation and extensions can be applied to Matrix as well. In fact, the sliding sync itself already fragments the ecosystem by not being supported out of the box by many server implementations and therefore homeservers. Encryption often has to be enabled with some machinations as well if we're talking about clients other than Element (and electron-based).
On the other hand, XMPP desktop clients certainly work better and faster than Element, although some of them look quite old, which doesn't take away from their functionality.
IMO it's being heavily overstated how Matrix is better than XMPP.
Also a nice read: https://telegra.ph/why-not-matrix-08-07
And the answer https://lobste.rs/s/wvi9xw/why_not_matrix#c_erbsnb