91–100 of 150 posts
Earlier quoted context omitted.
Is that the case? If so, this makes it look worse: Pure tech guys should be able to make a performant application.
This implies developers care about performance.
We had a variation on this discussion a few days ago here https://news.ycombinator.com/item?id=44591820 I discussed that their primary server had a child porn/child sex assault imagery problem. Others who had similar concerns were completely dismissed and attacked by the Element/Matrix admins. I have to agree with this article. Matrix is basically dead, and not worth keeping around. And it starves the open source eco…
youtube has this problem, discord has this problem and many other platforms what do those platforms do to combat child stuff? i don't like to dismiss anything but it is something all platforms and even multi billion dollar ones struggle with eu tries to decrypt e2e chats while you can see this stuff everywhere without encryption and nothing is being done to combat this on these major platforms as discord and whatsapp…
Not just anyone can access all of the SaaS databases and it's approved on a case-by-case basis. Obviously not all CSAM is in these databases, and gen AI output adds another hurdle to preventing this kind of malicious behaviour.
Personally, I feel a potential solution could be that user clients could opt into referencing hashes of media before it is downloaded, and that could either be handled by their home server, or a third-party. However, something like that is really idealism and not realistic at this point, despite being a great solution in a perfect world where people maintain encryption, yet don't expose themselves to CSAM inadvertently.
In terms of the Matrix.org homeserver, perhaps an alternative (though would prove unpopular) is only allowing Matrix.org users to upload media if they're a paying supporter of the Matrix.org homeserver with a valid payment method on their account, thus obviously linking their identity to their account.
https://matrix.org/membership/
The knock-on effect would be that it may offload some users onto their own infrastructure and alleviate the moneypit of a public instance, or directly fund the public instance itself if they do choose to support it financially. The Matrix.org instance doesn't support users adding bridges, so it isn't that much of a stretch to forbid media uploads from non-supporters. Portable identities would make this a no-brainer, but even without them, I still feel as if the public instance is largely an incredibly generous demo to help folks take Matrix for a spin. Decentralisation is such a major selling point that's vastly underutilized.
I do think that people should at least attempt to become decentralized and manage their own community by themselves, be it public or private. Large public homeservers are always going to be considerable targets for this kind of problem. It's a lot of digital eggs in one digital basket for a lot of reasons.
Nothing stopping people uploading images onto a third-party file storage system and providing the URL if they absolutely need to share a screenshot or similar on the public Matrix.org instance. Anyway, fleeting thoughts.
the amount of spec change proposals over the years is wild: https://0x0.st/H8h-.png
Is there a graph for post-2022 data? I wonder if it kept its trajectory.
The trajectory is the same, although obviously it's not ideal that the backlog grows at roughly the same rate as we merge/close them. Perhaps some day the Foundation will have enough $ to actually fund the spec core team to work on MSC review as their dayjob; meanwhile it's done in spare time or smuggled in as part of their dayjob.
Meanwhile, the fact that MSCs are being opened as fast as ever shows that folks are trying to nudge the protocol along as much as ever.
I said most of the same things in the Matrix foundation's server. The general response from the team was: "Pay money or shut up and accept what we give you". The number of gigantic changes in direction this project has had in the past couple of years is enough to sink any project. Jitsi to Webrtc, complete change in auth system, Element to Element X. There's two clients. One that's fast, and one that's full featured.…
I think you may be unfairly paraphrasing "we don't have enough funding to be able to work on both Element & Element X, or Synapse & Dendrite, or to have landed Threads/Spaces in Element X yet, or ".
> The number of gigantic changes in direction this project has had in the past couple of years is enough to sink any project. Jitsi to Webrtc, complete change in auth system, Element to Element X.
It feels ironic that our attempts to improve the project are characterised as "gigantic changes in direction which are enough to sink any project".
* Jitsi is unencrypted by default, and doesn't synchronise identity, access control, or cryptographic identity with Matrix, and uses XMPP (Prosody) for signalling. Moving to MatrixRTC (i.e. WebRTC signalled over Matrix) gives proper end-to-end-encryption with verified identity and access control managed by Matrix. Surely this is a good thing?
* "Complete change in the auth system" is a massive improvement, in that one of the main drivers for doing it was to now be able to use any OIDC identity provider to add 2FA/MFA/Passkeys or whatever fancy auth you like (despite the OP's assertion otherwise).
* "Element to Element X. There's two clients. One that's fast, and one that's full featured". Well, that's true, but most people seem to feel Element X's improvements outweigh the fact it doesn't have threads/spaces yet (although they are both in dev currently).
> but my experience with these guys is that they're incredibly arrogant.
For what it's worth, I think i've made some spectacular mistakes in running Matrix, as well as bunch of good stuff). This came up in the TWIM offtopic room a few weeks ago at https://matrix.to/#/!xALORqBdeiSfgdrmUb:bpulse.org/$4bGbRTxN.... I've reproduced it (lightly updated) at https://gist.github.com/ara4n/8422ae8eae68a8993a5e831691b441... for ease of reference. I'll let you decide whether that sounds like arrogance or a BDFL who's too smart for his own good.
> P.S I suspect the organization is being led by Architecture Astronauts
On the Element side: does https://youtu.be/IwZ4rE_Pt64 feel like an org led by architecture astronauts?
Firstly, I'm sorry they had such a bad time, and as per https://news.ycombinator.com/item?id=44621077 there's a tonne of things we've (i've) done wrong.
That said, there's a bunch of points raised here which aren't fully accurate. So for the sake of completeness:
> The official Matrix homeserver, Synapse, was built with a tech stack ill-suited for its long-term goals and scale
These days Synapse is hybrid Rust for the fast paths (https://github.com/element-hq/synapse/tree/develop/rust) and Python 3 + mypy for the rest. Huge servers like matrix.org (150K concurrent users) run fine on it. I'm not convinced the "ill-suited tech stack" crit holds.
> Community projects like Dendrite emerged to rewrite the homeserver more sensibly
Dendrite is not a community project and never has been; it was written by the core Matrix team, and then when we realised Synapse had critical mass we backported most of its architectural improvements to Synapse.
> New Vector seems to be chasing too many goals simultaneously, with no clear direction
No? we killed all the sidequests in order to just do Element Web, Element X, Element Call and Synapse.
> Just a few months ago, they migrated to the Matrix Authentication Service (MAS), which was supposed to be a leap forward, yet lacks even essential security features like 2FA/MFA.
No? the whole point of MAS is that it lets you delegate straight through to a proper IDP which provides 2FA/MFA/Passkeys etc.
> Launching the app requires network synchronization that hampers responsiveness
No? Turn off your network, launch Element X, and see that it launches fine? Obviously it does need to talk to the server to retrieve new data. I guess there was the https://github.com/element-hq/element-x-ios/issues/4102 issue, but that was fixed 3 weeks ago.
> The Matrix.org service, especially its matrix.org homeserver, is also slow
matrix.org feels pretty good to me these days, even on my mammoth account (other than when talking in Matrix HQ)
> On my laptop, I’ve been using iamb, a TUI Matrix client, and even there I experience delays of tens of seconds when launching it, and a lag of several seconds between pressing Enter and seeing the message actually appear in the chat room.
I'm assuming that's because iamb hasn't enabled sliding sync, and/or hasn't implemented local echo, or has some other perf bug. Or perhaps you're on an old build. Given it's using the same matrix-rust-sdk as Element X it should in theory be instant.
> And that’s certainly not iamb’s fault, because it’s written in Rust, btw™.
...
> the lack of proper first-party libraries for 3rd-party developers to build on top of, it became visible that the once-vibrant ecosystem, does no longer look so healthy
This is really weird. It's not clear that the Matrix Foundation should publish software at all, to be honest - it's effectively a standards body. W3C doesn't write browsers or web servers any more, for instance.
As it happens, we have invested a huge amount of effort into publishing a flagship first-party client SDK anyway: matrix-rust-sdk. And matrix-js-sdk is still there too. We very deliberately have handed off other SDKs to the broader community to maintain, which they do a great job of. Surely the fact that go-matrix got surpassed by Tulir's superior go-mautrix fork is a good thing, not a bad thing?
> Development on Synapse alternatives has stagnated
The conduits seem as active as ever, from what I can see, even if there's been forking.
Dendrite development has stalled, but this reflects lack of funding rather than the ecosystem failing, and the core team at Element having to put all its effort it into one server (Synapse) rather than splitting between two.
> Other clients like SchildiChat are faced with the dilemma of continuing their existing work or starting over by forking Element X
That's just false? SchildiChat seems to have quite happily forked EX into SchildiChat Next years ago and looks to be doing a great job of it; ahead of EX itself with many features (e.g. it already has spaces!)
> Speaking of SDKs, New Vector appears to lack a coherent technology strategy. They’ve built infrastructure in Python and Node.js/TypeScript, moved into Go for the Synapse replacement, and now maintain a Rust-based client SDK, while abandoning their Go client library (which is now community-maintained).
NV's stack is Python+Rust and Node/TS on the serverside, and Rust + (TS/Swift/Kotlin) on the clientside. It's true that over 11 years of work we've also sprouted a few Go projects (e.g. complement), and there's even some Perl (sytest), but that is very much the minority.
> Especially for an organization that appears perpetually cash-strapped. New Vector’s approach feels more like indecisiveness than the right tool for the right job when looking through their repositories on GitHub.
It feels unfortunate that the OP is complaining that NV doesn't provide enough 1st party implementations in different languages any more, while also complaining NV has too many languages in use.
> Matthew, if you’re reading this: We both know that naming things is one of the hardest problems in computer science, right after cache invalidation. I totally get the geeky, 31337 thrill a name like Matrix might evoke, but believe me when I say that using generic names is a bad idea. Things would have been a lot easier for everyone involved if you had at least rebranded Riot to something more distinctive. For future rebrandings, I highly recommend using the Synthwave Band Name Generator and some good old human creativity. :-)
Honestly Matrix & Element seem to get quite a lot of traction and successful press despite the generic names. For instance, I just spun up Tor and googled the word Element, and Element.io came up as the 2nd hit after the skateboard brand (and the whole sidebar). The data just doesn't back up this particular criticism.
Overall, though, I get why the OP is frustrated and has given up. All I can say is that we're working away on getting Element X to parity with Element as fast as we can so we can retire the 'classic' app, at which point I think much of the pain people are experiencing will go away. It's taking longer than I'd like given the work is entangled with building and deploying government messaging systems as a way to keep the lights on, but if anything all the negativity here makes me more determined and stubborn to keep plugging away to dig out of the transitional period we're in, and get back on track.
Earlier quoted context omitted.
The last statement is totally uncalled for. Yes, matrix is not convenient and given it's far from ideal chat experience but that doesn't mean you are allowed to spread FUD. Matrix spec, clients, homeservers, etc are fully open source. No one is "scamming" anyone
Matrix community scam everyone when claim a matrix is a privacy-focused. And you are part of this community who deceive people. The fact that anything is open source is not make it "privacy focused". Literally everything in Matrix is designed against privacy and security. Check issue I mention above. The product that is "privacy focused" would never have such type of problems that will force developers to say that la…
Earlier quoted context omitted.
Matrix is not a some sort of volunteer project. It is used by NATO as their NI2CE, as well as by many other governmental entities. Matrix runs on European taxpayer's money.
The Matrix Foundation is currently massively underfunded (contributing significantly to many of the complaints in this thread, especially around Trust & Safety) and even then losing money. It gets no money from folks like France or NATO despite their use of Matrix. You can see the list of financially contributing projects at https://matrix.org/support - there are only two governmental entities who support Matrix dire…
Are they contributing code? Money (explicitly to a single specific entity, especially) is hardly the only way to support something.
Earlier quoted context omitted.
Wait, did anyone investigate on why messages were not stored by other homeservers? That's rather odd, given the selling point of matrix is federation
I've heard that messages not getting through federation in some cases is just a thing that can happen. How that's compatible with calling matrix as having good federation, I don't know.
Earlier quoted context omitted.
It’s depressing to hear that you’ve given up on Element X, given that’s where all the work has been going, including ensuring the encryption is rock solid. Element Call is still webrtc; the fact it’s direct calling to a SFU rather than needing TURN for firewall traversal should be a good thing. How did you try to set it up? I did a basic walk through at https://github.com/element-hq/element-docker-demo in case that h…
Element X is (e)xcellent. Just wanted to share that. Been using Matrix via Synapse since ~2019 and all the Matrix odds and ends require the least maintenance out of anything in the stack. Any uptime issues I've experienced have been my own silly fault with incorrect configurations. Even Element as it stands without the X builds is leaps and bounds ahead of anything else I've tried (and I have and continue to try a lo…
It will be nice once all the features are in, but experience seems to indicate that I can live with better performance and fewer features.
