Thanks for mentioning it was about to hack something together myself.

Speaking as project lead for Matrix, I obviously feel pretty gutted when someone gives up like this. Doubly so when the straw that broke their back wasn't even a Matrix problem, but really gnarly postgres corruption (see https://news.ycombinator.com/item?id=44618702).

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.

Sadly it's essentially discontinued

Super happy to see matrix chug along. I’ve been self hosting dendrite home server for a long time but it doesn’t have sliding sync support, so can’t use the new modernized client. Anyone using conduit for self hosting and do you know if it works with the new client?

> - Notification center is now gone.

It's still there; it just got moved into Labs given it never worked in encrypted rooms, and having a flakey feature for new users was (correctly) considered worse than not having a feature at all. Go look for "Enable the notifications panel in the room header (Unreliable in encrypted rooms)" in Labs on develop.element.io or Element Nightly.

> - Room search is now only limited to official Matrix rooms.

This isn't accurate. On one server (matrix.org) the room directory is currently locked down to stop it filling up with spam, however this should be opened up again to be a curated room list in the near future.

> - At peak it consumes ~2.2 GB of RAM.

> - UI feels more sluggish by the day.

> - Loading it now takes ~10 minutes.

So agreed that Element Web performance is very painful for power-users. This is because we've been putting all of our effort into fixing perf in the protocol itself (via sliding sync etc) using matrix-rust-sdk on mobile in Element X to prove it all out. We've also spent huge amounts of time on encryption reliability.

However, good news is that we've finally moved to Element X Web (codenamed as Aurora: https://github.com/element-hq/aurora), which runs matrix-rust-sdk in browser but with MVVM React components from Element Web for the UI. You can play with an alpha at https://dangerousdemos.net (non-permenant-URL) right now. In contrast:

- At peak it consumes 80MB of heap.

- UI feels instant and is O(1) regardless of account size

- Loading takes ~2 seconds (although that's about 20x slower than it should be given Aurora doesn't currently persist any local state, so it's loading everything from scratch on launch).

> - Using it as an IRC bouncer (to Libera) is now gone, which was what initially attracted me in the first place.

Agreed that this sucks. We did everything we could to stop Libera removing the bridge, but failed due to lack of $ meaning we didn't have enough dedicated manpower to meet Libera's demands.

> And I don't even use the voice / call functionality of Element Web.

Element Call's actually rather good, in terms of providing end-to-end encrypted group calling. If you used it you'd probably complain that we broke backwards compatibility with the legacy 1:1 Matrix voip calling though, which would be true; again, due to lack of dedicated manpower.

> I somewhat understand the reasoning behind the decisions, but I feel like they should have improved the UX first before working on the protocol itself.

To improve the UX with clients, we had to improve the protocol, and Element X shows how good that UX improvement is. We're now catching up on Web.

borgbackup developer here:

TL;DR: don't panic, all is good. :-)

Longer version:

- borg 1.x style “append-only” was removed, because it heavily depended on how the 1.x storage worked (it was a transactional log, always only appending PUT/DEL/COMMIT entries to segment files - except when compacting segments [then it also deleted segment files after appending their non-deleted entries to new segments])

- borg 2 storage (based on borgstore) does not work like that anymore (for good reasons), there is no “appending”. thus “—append-only” would be a misnomer.

- master branch (future borg 2 beta) has “borg serve —permissions=…” (and BORG_PERMISSIONS env var) so one can restrict permissions: “all”, “no-delete”, “write-only”, “read-only” offer more functionality than “append only” ever had. “no-delete” disallows data deleting as well as data overwriting.

- restricting permissions in a store on a server requires server/store side enforced permission control. “borg serve” implements that (using the borgstore posixfs backend), but it could be also implemented by configuring a different kind of store accordingly (like some cloud storage). it’s hard to test that with all sorts of cloud storage providers though, so implementing it in the much easier to automatically test posixfs was also a motivation to add the permissions code.

Links:

- docs: https://github.com/borgbackup/borg/pull/8906/files

- code: https://github.com/borgbackup/borg/pull/8893/files

- code: https://github.com/borgbackup/borg/pull/8844/files

- code: https://github.com/borgbackup/borg/pull/8837/files

Please upvote, so people don't get confused.

My number one problem with Restic is the memory usage. On some of my workloads, Restic consumes dozens of gigabytes of memory during backup.

I am very much in the market for a replacement (looking at Rustic for example).

I think the problem is businesses are tiny little fascist dictatorships. They are always trying to pay less taxes, evade regulations, layoff workers, monopolize, destroy competitors etc. This is their first time ever having to think about the public sphere, or common good, or government, or democracy, or rule of law. They suck at that, it goes against all their training and instincts.

next level would be to hook these "platoons" together physically and then centralize the propulsion in a super efficient package. And then we could move them off the highways and onto specialized "tracks" that guarantee they don't deviate from the planned routes.

speculative, alien technology, admittedly, but some day our scientists will figure it out i bet!