Hacker Newsnew | past | comments | ask | show | jobs | submit | Arathorn's commentslogin

On the Matrix side we would love for Mozilla (or MZLA) to become a paid Matrix hosting provider. Element has ended up focusing on digitally-sovereign govtech (https://element.io/en/sectors) in order to prevail, and it's left a hole in the market.

There's some really interesting stuff we've been looking into on the Matrix side to solve this - e.g. https://github.com/asonnino/arke aka https://eprint.iacr.org/2023/1218 or https://martin.kleppmann.com/2024/07/05/pudding-user-discove....

Meanwhile, Matrix for now does support hashed contact lookup, although few clients implement it given the privacy considerations at https://spec.matrix.org/unstable/identity-service-api/#secur...


Yeah you're doing a lot better job on the privacy side than signal is IMO.

Especially just being able to run my own service will be priceless when something like chatcontrol eventually makes it through. Signal can only comply or leave, but they'll never manage to kill all the matrix servers around.


https://github.com/element-hq/ess-helm?tab=readme-ov-file#el... is meant to make it pretty easy. I sped-run an install from scratch in about 90 seconds during the Element keynote for the Matrix conference this year: https://youtu.be/TZgcdgv2NXk?list=PLl5dnxRMP1hUgnYEbpEsEEhIq...

Clearly we need to do a better job of pointing folks there.


> What does running a matrix server get me in 2025?

Is there any other FOSS, self-hosted, decentralised platform with E2EE chat & E2EE group VoIP - i.e. the equivalent of Signal, but without depending on a centralised service?

From my pov (which is biased, as Matrix project lead), the downsides are:

* We still expose too much metadata to the server. Work is afoot to fix this, though - e.g. https://youtu.be/Q6NSmptZIS4?t=933 for encrypted state events.

* Synapse is still uses waaaaay too much database. I proposed a solution here: https://youtu.be/D5zAgVYBuGk?t=1852 but it needs to get properly implemented.

* Element's transition from the legacy apps to Element X has not been smooth, causing much of the gnashing of teeth in this thread (e.g. lack of interop between 1:1 voip and group-e2ee voip, or teething problems in the new apps).

* Post Quantum Encryption hasn't landed yet; it's been painful to get funding together for it.


I would say the biggest issue is not any of those things, it's that issues of this magnitude (including many of the ones fixed in the last year) are still being identified and requiring things like a "transition from legacy apps", breaking server changes, etc. In other words, it is not stable.


If you want a simple docker-compose for Matrix, you can always use https://github.com/element-hq/element-docker-demo.

The reason Element ships ESS Community as kubernetes helm charts is simply so that the officially supported distro is as close as possible to the thing we have to support for the big govtech customers, where docker compose simply isn't going to cut it. Perversely, that means that ESS Community is pretty bulletproof (even if the scaling stuff is missing), but comes at the expense of having to run k8s.


this is wrong - the threads support in labs lets you create threads and navigate into them as you expect.

what you are describing is the old threads workaround which predates the proper solution in labs which should exit labs asap.


I am describing what I see on Element X on iOS today. If someone replies to threads, it is not hidden and navigable on this client. Even after switching the labs feature on, the app was showing the thread interspersed with the rest of the conversation.

Uninstalling the app, reinstalling, and making sure the labs option is turned on before navigating to a room with threads, is behaving how I expect.

So maybe, its a bug that the room does not re-render after toggling that setting.


ah right - that sounds very plausible; sorry for the confusion. have filed it as a likely bug at https://github.com/element-hq/element-x-ios/issues/4810 - thanks for the report :)


I get the frustration that Dendrite dev has stalled, but the fault here is not of an evil take-over by Element (given Element wrote both Dendrite and Synapse in the first place) but simply neither Element and Matrix Foundation having the $ to do be able to maintain two homeservers simultaneously.

> Now the free and open source Matrix homeserver has to compete with a closed source commercial one

This isn't really the case - normal open source Synapse is the core focus for Element, and the vast majority of work is going into that, including performance work. Synapse Pro is "just" for scalability and HA for big government-scale deployments - https://element.io/blog/scaling-to-millions-of-users-require... etc. But all the schema work etc which supports that goes into FOSS Synapse.


iamb is pretty good and not abandonware, fwiw: https://github.com/ulyssa/iamb


We did address the elephant eventually with https://github.com/element-hq/element-admin a few months ago.

In terms of VoIP interop - yes, one of the worst bits of Matrix is that the legacy 1:1 VoIP calling is not interoperable with MatrixRTC-based (multiparty) VoIP calling, but we ran out of time/cash to implement interop and instead focused on making MatrixRTC work well. (Does XMPP give you E2EE multiparty calling ooi?)


Thank you Aaron for the direct response. Glad to see the central interface for administrative use. Haven't had the need to use the calling feature in a while. One of the hurdles with the Rust client on Fdroid was it was too new for the OS on the device it needed to be used on, but on iOS it was a performance improvement.

One of the genius ideas behind Element was the ecosystem of clients services that attach to rooms, and in some cases XMPP does not reach those expectations. I do plan on a redeployment soon after creating a new technical scope for its use.

I like what I can observe of the new admin interface. I hope it can come to include security and configuration check guidances to provide tools for admins of all skillsets to properly configure their servers, and related TURN-or-not and storage.

Matrix is bigtime like XMPP - I don't think it's going anywhere anytime soon. Thankful for all that it has provided to our organizations.


Another cashflow idea, as if you don't think of many yourself: A white-label version of Element (called something else) that can be deployed as scoped to an organization and based on an LTS release schedule. We'd gladly pay for this.


That is Element’s current business model: https://element.io/en/pro-app and https://element.io/server-suite/pro.


Looks excellent, sharp website - and I'll admit I hadn't looked for the white label app before talking shit. That offering looks excellent - I see an opportunity for a white label tier between community and enterprise for small/medium orgs with pricing listed on the website.


Well, I can't check if it is still a thing today, but Element's managed servers used to allow you to do that, at least for the web app (though I had the idea they also did that for the old mobile apps?)

Here's a couple of links:

https://element.io/blog/custom-branding/

https://element.io/blog/a-white-label-messaging-app-to-creat...


They've been on their game with this product, which hadn't been on my radar until Aaron's response above.


I'm sorry you had a crap time, and agreed that in the past things were not great. But in defence of the Matrix team, we fixed almost all known encryption in ~Sept 2024, and the new generation of clients fixes the slow sync issues.

In terms of message retention: https://element-hq.github.io/synapse/latest/message_retentio... is how you should have/could have cleaned up those rooms. (It's not exposed in Element's UI yet as we've been prioritising more fundamental stuff).


Hi Arathorn, I recognize your name as the core developer lead. :) Alas, when I was trying to cull my old messages I tried that (and a lot of other API type hacks I found floating around) and none of them, at that time, worked.

In short: the complete lack of user-facing easy to use controls for data retention and culling in the Matrix (Element) clients is a deal killer for me. That painful experience taught me a lesson - now when I test something new, one of the first things I look for is "how do I extract from this thing?". I never want to go through my Matrix extraction pain again, so a personal life lesson was learned.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: