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

https://jade.ellis.link - My blog, plus a bit of a personal link directory.


Thanks


This doesn't really excuse it, but to give you some idea of why Element haven't spent any time on dendrite right now, here's a sample of active servers on the federation as of today:

    2025-12-01
    synapse : 10068 (85.8%)
    conduit : 476 (4.1%)
    dendrite : 369 (3.1%)
    continuwuity : 303 (2.6%)
To add on to that, none of their customers use it, and there's no real community around it, unlike the independent Conduit-family servers that make up that remaining 11%.

Dendrite was a bet for two things: Could they make synapse faster? Yes. Synapse is faster now, and Synapse Pro is apparently even faster. And, can we make Matrix peer to peer? They ran out of money, and didn't have any customers who would fund it themselves. They're left with this project that is idling without a community, a customer, or a reason to exist.

Apparently, they have some funding to do work on the foundational parts of p2p now, but that will take a long time, and Dendrite is unlikely to be a part of that for a while, possibly at all (the Rust ecosystem seems to be where Element invested their time on the client, while Beeper invested in Go).

In the end, a lot of Element's pain is because of ambitious technical decisions made without a way to back them up practically or business wise. Things would be amazing if everyone working on Matrix had infinite time and money. Unfortunately, they don't, and Element is eating the consequences for acting like they did for a while. They seem to be better now, though.


I honestly don't blame them that Dendrite didn't work out, I blame them for leaving us all stranded without any sort of migration path. I don't personally care if my homeserver is written in Python or Go or Rust, at least not very much. Rust may very well be a better choice than Go in the long run. I only chose Dendrite because when I chose it I felt like it was in better shape than Conduit (which at the time wasn't forked off, wasn't well-supported by app services either, and didn't handle federated presence) and lighter weight than Synapse.

Is my homeserver even counted in the 369 active Dendrite servers anyway? I mean, I guess it definitely isn't in that count since it is now an active Synapse server instead, as of late November. However for what it's worth, I don't think I actually connect to Matrix.org at all. Maybe it still counts if you're in a room with Matrix.org users?

But assuming it is basically just 369 Dendrite servers, well, they're all stuck there. How hard could it have been to provide a migration path? I dunno. My attempt is definitely incomplete and possibly quite ill-advised. I truthfully don't understand Dendrite or Synapse well enough to design a migration tool that works correctly. Did I calculate forward extremities correctly? Maybe. Are my state groups actually all correct? Probably not. How the hell did I end up with rooms that have multiple auth events? I have no idea, I just wound up destroying the corrupted rooms I found. I can only imagine that whoever developed the Dendrite database structure also had knowledge of how the Synapse database structure works and would've been able to do all of this in many less hours than I was.

After all is said and done I'm sure the balance sheets will look much better but the damage done to the community side of things will linger. I won't feel bad if Element fails and Matrix winds up replaced by a different standard later.


FTR the server stats are from https://matrixrooms.info/stats. It's not a full view of the network but it's a reasonable sampling, based on servers discovered through public room aliases and servers that use it as a notary (trusted key server).


> Synapse is the only choice that supports bridges

This is not true, at least today. Continuwuity, which is an alternative server implementation, and its predecessors support bridges very well.


I set up Whatsapp and Telegram bridges with Tuwunel today. The config file for mautrix-whatsapp indicates Dendrite should work as well so it seems just about every server implementation supports bridges?


Former Dendrite user: Yes and no. Mautrix stuff does work with Dendrite, technically, but only partially. For Mautrix-Discord, I was able to get DMs mostly working, but only DMs: bridging servers just never really worked at all. I'm honestly not 100% sure why this is the case, but it's not worth worrying about Dendrite anymore. It is a dead-end server that never worked very well. Up until shortly before it was discontinued, none of the Mautrix bridges worked well enough to actually use.


If you look it up, you'll see that JMAP is 6 years old now. It's a protocol for doing email (and now other things) over HTTP, without many of the legacy issues from IMAP and SMTP. https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol / https://jmap.io/index.html


Aside from the other comments, I would say that a modern chat application is anything but 'simple' - there are a vast amount of features that you expect, from pinned messages to file downloads to threads, to say nothing of end to end encryption.


the Matrix foundation is a UK company.


so what? all the specification and all the code is open.


You do have to keep bridges up to date, because they need to remain compatible with the internal APIs of other platforms. Beeper.com (mentioned by a sibling comment) is a commercial deployment of the mautrix matrix bridges, along with some propietary components. You can deploy the exact same bridges using their documentation: https://docs.mau.fi/bridges/ - although you won't have access to the propietary beeper client or hungryserv.


Ink and switch is a research lab. As far as I'm aware, they're not a building any specific products, just exploring what is possible for human computer interactions


But are they building prototypes to validate their ideas in practice?


Yes, they also have some software you can use today, not just prototypes.


Nex is a cybersecurity student in a house of similar people, they're gonna take every way :3

quote:

> The plan is, in future, since we can't hack something that doesn't have a brain, to instead attach a brain to it. The dishwasher is easy, we can just whack that on a smart plug and monitor when the power use surges and drops. The dryer is a bit more difficult, since they pull a LOT of power, and smart plugs typically either don't support that much power, or are incredibly expensive. So that's likely going to be some fancy vibration sensor-based thingy


Vibration sensor is exactly what I did, for exactly that reason. Zigbee sensor + home assistant and a little bit of timer logic to manage the state


Shelly has power meters with clamps, so that the meter is not in-line. There are probably Zigbee variants out there.


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

Search: