Post
I haven't heard of any app being banned in the UK. AFAIK they've all rolled out changes to their ToS to cosplay compliance with the Online Surveillance Act.
(UK authoritarians euphemistically call it; "Online Safety" Act, but the name I use is more accurate.)
Where do they say that? This seems very unlikely, given that X is a *prototype*, and when the features are ready for primetime, they'll be folded back into mainline element. Just like the last ElementX.
Anyway, even if they say that, I didn't;
(1/2)
@tuxsec
> According to them, EX is production ready and people should not be using old Element anymore
Well, well. @element have made a liar of me. This is not how the last ElementX development went (as they approached Matrix 1.0), so it's the opposite of what I expected. It's absolutely not true that it's ready for production use, as it's lacking a number of major features (as identified in comments), as well as backwards compatibility with Matrix 1.0 (which we have a right to expect).
(2/2)
I'm detecting desperate attempts to satisfy VCs wanting to start seeing a return on the funding they put into Element as a startup. Which means it's more important than ever that the wider community of people using Matrix-based services takes charge of the Foundation, and ensures that it's serving our needs, rather than being beholden to Element's VCs.
I have both ElementX and SchildiChat on my Android, both logged into Matrix servers running the latest Synapse (AFAIK). ElementX opens and syncs noticeably faster, by quite a margin. Although the 2 accounts have very different numbers of public rooms open, so I guess it's not an apples with apples comparison.
> it doesn't support essential features like threads and spaces
Not essential to my use case, also;
I use ElementX almost exclusively for 1:1 DMs, and I suspect this is the market they're pivoting to. Leaving the team chat uses cases to other outfits like Gitter;
https://blog.gitter.im/2023/02/13/gitter-has-fully-migrated-to-matrix/
... ProcessOne (eJabberD);
https://www.process-one.net/blog/matrix-gateway-setup-with-ejabberd/
... RocketChat;
https://www.rocket.chat/blog/federation-at-rocket-chat-the-shift-to-a-native-solution
... and so on.
https://mastodon.nzoss.nz/@strypey/115013113977059648
> calls are complicated
I'm pretty sure it does. Matrix 2.0 definitely does, as demonstrated by;
But maybe calling on ElementX only works to client/server combo that also supports Matrix 2.0 calling?
(1/2)
@allpurposemat
> not part of Matrix standard
Not part of the Matrix 1.0 spec, no. call.element.io is a testbed for Matrix 2.0 calling. ElementX is a testbed for 2.0 features in general, which is why the OP suggests testing it as a preview of a 2.0 experience.
> other clients don't support it
... yet. They will if they implement Matrix 2.0. Any that don't do that will still work with vanilla Element for 1:1 calling using Matrix 1.0. Even when ElementX functionality is folded back in.
(2/2)
> it looks like it depends on a proprietary service
@lightweight hosts our Matrix server, and wouldn't have adopted it if there was a single proprietary dependency. I presume SFU = Selective Forwarding Unit. Maybe this one?
https://github.com/matrix-org/waterfall
> at the moment sadly not a solution
Right. It's a prototype. I'm not sure how I could have made that any clearer.
As for the SFU, I found the comment about it: https://github.com/matrix-org/matrix-spec-proposals/pull/4195#discussion_r1908722786
Looks like I was wrong about it being proprietary, rather it is an open-core project. I guess as long as the part I'm hosting is free, it should be fine...
May not be implemented yet, or exposed in the interface. ElementX
is a prototype, after all. When it's ready for production all the new hotness will be folded back into vanilla Element, and the Matrix SDK it's based on.
A space for Bonfire maintainers and contributors to communicate
