[HN Gopher] Why We Abandoned Matrix (2024)
___________________________________________________________________
Why We Abandoned Matrix (2024)
Author : Flere-Imsaho
Score : 170 points
Date : 2025-12-24 15:06 UTC (7 hours ago)
(HTM) web link (forum.hackliberty.org)
(TXT) w3m dump (forum.hackliberty.org)
| Arathorn wrote:
| /me sighs; Merry Christmas everyone.
|
| For what it's worth, we've been working on improving Matrix's
| metadata footprint this year: MSC4362 (https://github.com/matrix-
| org/matrix-spec-proposals/blob/kay...) got implemented on matrix-
| js-sdk for encrypting room state (currently behind a labs flag on
| Element Web: https://github.com/element-hq/element-
| web/blob/develop/docs/...). Meanwhile more radical proposals like
| MSC4256 (https://github.com/dklimpel/matrix-spec-
| proposals/blob/mls-R...) go and remove senders entirely and
| encrypt room state via MLS.
|
| The reason Matrix hasn't prioritised metadata protection earlier
| is:
|
| * If you're particularly concerned about metadata footprint, you
| can run your own servers in whatever network environment you feel
| like - you are _NOT_ surrendering metadata to some central or 3rd
| party server as you would in a centralised platform.
|
| * We've had to focus on getting decentralised encryption stable,
| which turns out to be hard enough without also throwing in
| metadata protection - it's only this year that we've turned that
| corner.
|
| * Unless you're using a mixnet, network traffic gives away a
| significant amount of metadata anyway.
|
| Anyway, yes: Matrix can do better on obfuscating metadata on
| servers, and we'll continue improving it in 2026.
|
| Meanwhile, if anyone's feeling nostalgic you can see a
| presentation I wrote preempting the challenge of metadata
| protection back in 2016 (on the day we first turned on E2EE in
| Matrix, ironically):
| https://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20E....
| In some other world perhaps we would have got to this point
| sooner, but better late than never.
|
| EDIT: I can't face going through all the other points in this
| post, but it's worth noting that some of it is just entirely
| false - e.g. the hackea claims of "an impressive collection of
| private data being sent to Matrix central servers, even when you
| use your own instance", or the fact that media isn't authed (it
| has been since Jun 2024). Meanwhile the abuse situation has
| evolved significantly in 2025, with stuff like
| https://matrix.org/blog/2025/02/building-a-safer-matrix/ and
| https://matrix.org/blog/2025/12/policyserv as well as hiring up a
| larger trust & safety team at the Matrix Foundation.
| jdonaldson wrote:
| People here always want to run the software themselves first,
| but then the next day they want to pay someone else to host it.
| If you're running into people throwing security flags, the
| silver lining is you're also a stone's throw away from offering
| a hosted option.
| chaps wrote:
| "If you're particularly concerned about metadata footprint, you
| can run your own servers in whatever network environment you
| feel like"
|
| You're not going to win any long-term support with this
| attitude, even if you're technically right. Like, if we're
| still in this "why doesn't the pleb just become a part time
| sysadmin" way of thinking, it's hard to think it's not just
| DoA.
| Arathorn wrote:
| Well, that's why the first half of the post spells out the
| work that we're doing to improve the metadata footprint. The
| second half that you're quoting explains why we didn't solve
| this back in 2014.
| chaps wrote:
| Frankly, I'm not sure why explaining it (or the
| explanation) makes the situation any better.
|
| FWIW, I'm the kind of weirdo who gets annoyed by having to
| add a new noscript rule for every federated instance. So
| I'm not exactly Matrix's target audience.
| Arathorn wrote:
| yup, unsure why i bothered too.
| ezst wrote:
| > [federation] offers a degree of censorship resistance, as the
| messages or images are replicated across multiple servers, making
| it difficult for any single entity to censor or control the
| content.
|
| That's the way Matrix goes, but that's not an inherent property
| of federation (XMPP doesn't leak nearly as much metadata as
| Matrix does, for instance)
|
| Also, there is no free lunch in this space: p2p is slow and
| inefficient (bandwidth as much as battery) for modern mobile
| usecases, the workarounds generally consist of having edge
| servers to act as caches or preferred routing points, and that
| brings us back to the exact same set of tradeoffs found in the
| federation model, except with less control.
|
| In short, I agree with the premise that Matrix is terrible, but
| not that federation is necessarily bad, nor that P2P is clearly
| superior.
| pmlnr wrote:
| Email itself is federated. Sort of the original federated
| messaging.
| tptacek wrote:
| And the worst available secure messaging system.
| pmlnr wrote:
| And it's the best widely available, accessible, battle
| hardened, omnipresent messasing system.
| tptacek wrote:
| I disagree and think rather that people have a parasocial
| relationship with it, like they do with IRC.
| leetnewb wrote:
| What do you think of a system like Delta Chat built on top?
| akerl_ wrote:
| Trying to build a secure system on top of email is a
| waste of time and energy. Even if you succeeded, it would
| only be by compromising all the things that make email
| useful.
| HNisCIS wrote:
| I'll preface by saying that I would prefer fully
| decentralized/p2p systems to take over, that's said...
|
| Their arguments against the middle ground (federation) made no
| sense. Yes, some current implementations are flawed in that you
| can poison caches with spam and csam, but that's not inherent
| to federation. In fact, it looked more like they were upset
| that you can't censor federated communities sufficiently to
| their liking (nuke them out of existence on a whim?). Their
| main, and really only, argument against Lemmy was group think
| but...it's a consensus platform, that's its purpose. There is a
| time and place for communities to build group consensus
| organically and it's a viral part of society, so while I can
| understand chafing at that from time to time, I wouldn't call
| it a protocol failure.
| zx8080 wrote:
| Discourse "loading" screen is the worst user experience. It's
| long, non-informative and meaningless.
| julianlam wrote:
| When they added it (probably a decade ago now), it signalled
| that they completely gave up on providing a performant forum
| software.
| zx8080 wrote:
| > Why Federation Must Die
|
| They've lost me right here.
| mystraline wrote:
| Matrix should rightly die. Its a terrible protocol in so many
| aspects.
|
| As a counter, Mastodon federation is pretty sweet.
| sitzkrieg wrote:
| it's too bad running a mastodon instance is also a nightmare
| wizzwizz4 wrote:
| GoToSocial and snac2 are both much simpler.
| https://gotosocial.org/ https://comam.es/snac-doc/
| tcfhgj wrote:
| I have yet to learn about a federated alternative which is
| better than Matrix or at least on the same level
| ezst wrote:
| XMPP just works and has matured substantially in the last
| 5years or so. You may or may not like it, but that's all
| I've been using/needing for a decade, and because of that,
| I ended up onboarding a bunch of tech-illiterate friends
| and family members along the way. It just works for them,
| too.
| tcfhgj wrote:
| I "need"/want more, Cross Signing, completely autonomous
| servers, not contacting 3rd party servers as a client,
| easy access to e2ee msgs including fresh sessions, non-
| centralized rooms, e2ee video conferencing, to name to
| most important aspects.
| tormeh wrote:
| Lol. Mastodon is terrible, be the tech as it may. At least
| there's content I care about on Matrix, although Discord is
| still king.
| mistrial9 wrote:
| agree - it needs better immune responses, healthier community
| in some real ways
| xiaomai wrote:
| Several years ago I was looking for something to use as a family
| chat server. Many of my friends/coworkers were using Slack/etc.,
| but since my immediate family members didn't already have a
| preferred chat app, I was hoping to self-host something open-
| source. Matrix was under very active development at the time and
| I was pretty excited about the prospect of using it. Matrix
| didn't even have E2EE yet (I think it was under development), and
| that really wasn't a feature I needed or cared about
| (disappointing to read about all the trade-offs involved in this
| post though). The computational/storage costs for Matrix really
| were way too burdensome though. I ended up going with Jabber
| (Snikket). A jabber server costs essentially nothing to run.
| Highly recommend.
| dijit wrote:
| I don't really have a dog in the fight so to say (aside from
| running a relatively large IRC network for the passed 22
| years)...
|
| But I really do wish we had doubled down on XMPP. It was nearly
| everywhere in the late-00's early-10's. If we could have just
| solved the mobile case (which, was solved, just not in popular
| server versions) then we would have been in a better place
| today.
|
| Hatred of XML has cost us so many wonderful things, the one
| that hurts me most is SMF (the solaris init system) which
| obviated the major issues people have with systemd. Except
| because it's using XML people would rather carve off a limb
| over seriously considering porting it.
| mxuribe wrote:
| Now that i'm looking back at xmpp, i agree that i wish we
| would have doubled down on xmpp - either to make some things
| easier for hosting, etc. And, yeah, its funny that you
| mention about the hatred of xml...i never loved it, but never
| hated it. Same with json, etc....To me they're just data
| formats...but so much dislike seemed the cool thing to do
| back in the day. Ah, well.
| phantasmish wrote:
| It's so easy to host, and I once implemented a partial in-
| browser client (using, basically, a web bridge that I also
| wrote on the other side) in no time, starting from not
| knowing a single thing about it aside from having used xmpp
| chat clients in the past. Like getting to the point of status
| online/offline indicators showing up and messages passing was
| _so_ easy. I get that I was a far cry from supporting things
| like encryption extensions, but it's a great sign when going
| from nothing to having at least _some_ of a protocol working
| takes very little time.
|
| The web platform's still (for now) really good and fast at
| working with xml. Kinda wild we ended up with json
| everywhere.
| Avamander wrote:
| You say that but has XMPP really improved over the past 10-20
| years? The same issues plague it still.
| dijit wrote:
| because all the investment (and, crucially: time) has gone
| elsewhere.
|
| I thought I was clear about that?
|
| SMF also has not moved in 15 years.
| tcfhgj wrote:
| would XMPP 2.0 still be compatible with XMPP?
| mxuribe wrote:
| > ...The computational/storage costs for Matrix really were way
| too burdensome though. I ended up going with Jabber (Snikket).
| A jabber server costs essentially nothing to run...
|
| Your experience seems to mirror my own. I still use matrix very
| little, but have defaulted to use xmpp. Well, really returned
| to it after so many, many years away from xmpp. I tried
| prosody, but then after a multi-server cleanup killed it off. I
| think it was fine. Up next, i'd like to try either self-hosting
| my own ejabberd server, or if i don't want manage yet another
| host might consider the paid option of Snikket...or maybe go
| through jmp.chat which if i recall correctly includes xmpp
| hosting with some jmp chat paid plan, etc.
| bossyTeacher wrote:
| > my immediate family members didn't already have a preferred
| chat app
|
| I am curious, how is this possible? Most non-techies seem to
| use the app that matches the app that is the most popular one
| in their area/demographics. For most, that would be Whatsapp i
| guess. How did you sell your app to your family?
| dfajgljsldkjag wrote:
| I really wanted matrix to succeed, but I've completely and
| entirely given up on it now.
|
| State resolution is just a total mess. On the best of days it's a
| hideously complicated system that sucks crazy resources, and on
| the worst of days rooms get blown up and bricked. Supposedly it's
| not as bad as before, but the fact that rooms can get bricked in
| the first place is bonkers. Just computing the member list of a
| room is a disaster due to the complex resolution algorithm - I
| spoke to a homeserver admin once who found that the DB storage
| space of just the member list can easily reach multiple gigabytes
| for larger rooms.
|
| Also years later, we still don't have custom emojis, user
| statuses, user bios, invite links etc. - very basic things that
| literally every messaging platform has.
| https://github.com/element-hq/element-meta/issues/339
| https://github.com/element-hq/element-meta/issues/573
| https://github.com/element-hq/element-meta/issues/426
|
| I'm interested in hearing if anyone has used simplex and what
| kind of experience it is. It seems like simplex is going for a
| similar audience as signal but using a very different approach. I
| don't think they've really had a breakout though and haven't
| heard it talked about much.
| Arathorn wrote:
| > State resolution is just a total mess.
|
| Not since https://matrix.org/blog/2025/08/project-hydra-
| improving-stat...
|
| > I spoke to a homeserver admin once who found that the DB
| storage space of just the member list can easily reach multiple
| gigabytes for larger rooms.
|
| This is nothing to do with state resolution; it's due to
| Synapse's implementation deliberately cutting corners on
| storage efficiency while trading off for speed. I showed how it
| could be fixed a few months ago here:
| https://youtu.be/D5zAgVYBuGk?t=1853, but we prioritised fixing
| state resets instead.
|
| > Also years later, we still don't have custom emojis, user
| statuses, user bios, invite links etc
|
| There are MSCs for all of these now, and implementations are
| starting to filter through. The reality is that the project has
| been in a funding crunch since 2023 and we've had to focus on
| survival by prioritising stuff people pay for (i.e. big servers
| for govtech deployments) rather than custom emoji.
| juliangoldsmith wrote:
| >trading off for speed
|
| If speed is a concern, why did you all stick with Synapse
| (essentially single-threaded due to the GIL) over moving to
| Dendrite? As far as I can tell, Dendrite is, for all intents
| and purposes, abandoned.
| Arathorn wrote:
| Because we didn't have enough people or cash to do a good
| job of simultaneously writing two servers, and as Synapse
| had gone into production across *.gouv.fr and other
| critical deployments, we instead frantically backported
| Dendrite's main novelties to Synapse - adding instead
| worker processes to Synapse so it could easily scale beyond
| the GIL: https://matrix.org/blog/2020/11/03/how-we-fixed-
| synapse-s-sc...
|
| The hope was always that we would then get back to Dendrite
| and be able to invest in it and migrate over, but the cash
| situation got worse in 2022 due to Matrix being more and
| more successful (causing the available $ in the industry to
| be flow to integrators rather than the upstream project),
| and instead we had to essentially park Dendrite dev in 2023
| other than for critical fixes.
|
| Meanwhile, to try to fix the $ situation, we added Rust
| workers to Synapse as "Synapse Pro" to give customers a
| reason to actually route money to us as the upstream
| project, and nowadays Element is actually on a more
| economically sustainable path. However, at this point the
| likelihood is that rather than progressing Dendrite we'll
| instead look to add more Rust to Synapse and fix its
| resource usage. That said, others are of course very
| welcome to continue progressing Dendrite forwards, and I
| personally find it super depressing that we failed to
| progress both servers at the same time.
| The_President wrote:
| Matrix team is doing a solid job of running - Keep it up
| and keep eating the Slack/Teams marketshare up with
| competitive features and pricing. Additional business
| considerations like HQ location costs, tax liabilities,
| and talent pool availability on paper also affect what
| you have to work with. London tax, talent, and labor pay
| versus Austin for example.
|
| Also I got your name wrong last time - I apologize for
| that.
| majoe wrote:
| > nowadays Element is actually on a more economically
| sustainable path
|
| Good to hear. Keep up the good work.
| juliangoldsmith wrote:
| It sounds like you were stuck between a rock and a hard
| place there. Hope the Rust integration goes well.
| xethos wrote:
| > the likelihood is that rather than progressing Dendrite
| we'll instead look to add more Rust to Synapse
|
| I thought the goal of Dendrite was decentralization done
| right? Namely, the ability to run a homeserver from the
| very phone one is using the client on?
| dfajgljsldkjag wrote:
| > This is nothing to do with state resolution; it's due to
| Synapse's implementation deliberately cutting corners on
| storage efficiency while trading off for speed.
|
| It's specifically to increase the speed if *state
| resolution*. If it weren't for the convoluted state
| resolution system, there wouldn't be a need to store
| gigabytes worth of state groups in the database.
|
| * https://element-
| hq.github.io/synapse/latest/usage/administra...
|
| * https://github.com/matrix-org/rust-synapse-compress-state
|
| Maybe there's a way to calculate state without state groups,
| but I sure don't see one that I can use if I were to run a
| matrix server.
|
| > Not since https://matrix.org/blog/2025/08/project-hydra-
| improving-stat...
|
| Simply fixes some of the many ways that rooms can explode or
| be bricked. Zero confidence that room brickings are totally
| fixed once and for all.
|
| > There are MSCs for all of these now, and implementations
| are starting to filter through. The reality is that the
| project has been in a funding crunch since 2023 and we've had
| to focus on survival by prioritising stuff people pay for
| (i.e. big servers for govtech deployments) rather than custom
| emoji.
|
| A funding crunch since 2023 yet those features have been
| necessary for many years before 2023.
| tcfhgj wrote:
| The room state is cached to not need to recompute the
| current room state from the beginning of time.
|
| You probably would do that even if there was no state
| resolution at all
|
| > Simply fixes some of the many ways that rooms can explode
| or be bricked.
|
| How many other ways are there? Afaik none is known
| dfajgljsldkjag wrote:
| > Afaik none is known
|
| Before project hydra people didn't know about the room
| exploit either. They just knew that rooms exploded
| somehow every once in a while.
| Arathorn wrote:
| Most people actually working on Matrix have been aware of
| state resets for quite a while. Hydra is just the name of
| the project which addresses them. There are 3 phases, of
| which the 1st covers the most serious ones; the 2nd and
| 3rd phases should drop next year.
|
| As an analogy, it's not dissimilar to how Git has added
| various different merge resolution approaches over the
| years in order to come up with more predictable and more
| "do what i mean" algorithms (resolve, recursive, ORT,
| octopus, etc). It's slightly different in that a bad
| merge in Matrix feels very unexpected and problematic,
| whereas manually unpicking collisions in a VCS is just
| part of the territory.
| Arathorn wrote:
| > It's specifically to increase the speed if _state
| resolution_. If it weren 't for the convoluted state
| resolution system, there wouldn't be a need to store
| gigabytes worth of state groups in the database.
|
| No, it's specifically to increase the speed of state
| retrieval. One of the uses for that is state resolution,
| but it could equally well just be calling the /messages API
| or any other point you need to know historical state. But
| what do I know :)
| dfajgljsldkjag wrote:
| > it could equally well just be calling the /messages API
| or any other point you need to know historical state.
|
| State groups aren't really a thing for messages in a
| timeline, there are many easier ways of doing it, for
| example, simply storing the message sequentially
| (impossible in matrix though, due to the convoluted tree
| structure it uses)
|
| But when it comes to state (where state groups are
| actually needed) who actually needs a snapshot of the
| state at literally every point in history? Any other
| messaging app just needs to know the current state and
| maybe also an audit log of the change history for audit
| log purposes.
|
| In any sane messaging app (e.g. discord, slack, telegram
| etc.) there is exactly zero relevance in knowing the
| member list, room configuration, permissions and room
| title at exactly 2024-06-19T15:23:45Z. Who the heck
| cares??? Yet the design of matrix somehow makes this an
| integral part of every single operation.
| Arathorn wrote:
| Perhaps just watch the video and see that the proposed
| solution is just doing a temporal state table - _just_ as
| Slack and Discord etc must have in order to know what the
| state of a room was at some point in time.
| dfajgljsldkjag wrote:
| Slack and discord _don 't_ know the state of the room at
| any given time in the past. Show me anywhere in slack or
| discord where you can see the membership of a room at
| 2024-06-19T15:23:45Z. Or anywhere where you can see the
| historical profile picture and nickname of everyone in
| the room at 2024-06-19T15:23:45Z. You can't, because they
| don't know.
| Arathorn wrote:
| I am pretty confident that slack and discord know who has
| permission to read a message at a given point in time,
| which is all that state groups are achieving here.
| rglullis wrote:
| > A funding crunch since 2023 yet those features have been
| necessary for many years before 2023.
|
| But before 2023, the funding was going to things like
| solving state resolution, a VoIP system that was not
| dependent on Jitsi, getting rid of "could not decrypt
| message" errors, and so on.
| 2Gkashmiri wrote:
| https://kashmirlife.net/14-messaging-apps-blocked-in-
| jk-3163...
|
| You guys gave up on the national security threat and caved.
|
| Dont want authorities knocking my door down for using an app
| mxuribe wrote:
| I also wanted - and still want - matrix to succeed! But, i've
| also semi-given up. I still use it because there a small number
| of folks i still chat with; though that's dying off. I managed
| a synapse home server very early in matrix's life, for a few
| years, and yeah it was complex back then...and for me the
| security is fine. Sure, there are gaps and things to be address
| for security...but, overall the thing that grinds my gears are
| the heavy resources needed. I started returning to xmpp. Is
| xmpp "simpler" or "more secure"? I would reply: no. But, you
| know where xmpp is really great? Ridiculously low needs for
| resources for a server! I understand that in this day and age
| we have far more access to so much more computing power...But,
| why should we allow bloat just because we can? Sorry, nowadays
| if I'm just trying to provide for chat, I'm looking into xmpp.
| I have no experience with simplex, but i think i'll wait til it
| bakes a bit more (and also see the resources usage story in a
| year or so).
|
| Its funny, I was such a matrix fan boy, and now i'm looking at
| a chat tech (xmpp) that has been around for tons of years -
| figure that!
| Jnr wrote:
| At this point I just want them to die off completely so we
| could get something better. They have been unable to make
| real improvements that make using Matrix a nice experience.
| And their existence somehow inhibits other solutions from
| emerging in the OSS community chat space.
| Arathorn wrote:
| > And their existence somehow inhibits other solutions from
| emerging in the OSS community chat space.
|
| How?
| mystraline wrote:
| People new to the system think that Matrix can work. So
| FLOSS devs spend time trying to lipstick the pig. Takes
| time away from other areas.
|
| Matrix is completely busted, for the article's
| aforementioned reasons, and others.
|
| My complaints is that ive seen child sexual assault
| imagery on your primary servers, hours later (and
| thousands of CSAM images) finally the user banned. And
| still does it cause some federated server they are
| connected to still allows them to be half-joined to a
| room.
|
| The only safer way to federate is to disable image
| caching and preloading, and ideally defed from
| matrix.org.
|
| And combined are the laughable moderation tools. I'm sure
| for some gov deployment, they're not going to spread
| child sex images. But on the public internet, even basic
| tooling is a joke.
|
| I recommend all Matrix admins to discontinue. Its frankly
| too legally dangerous to run it, given all the various
| failure modes and E2EE failures.
|
| Its 1 size doesnt fit at all. And it being gone would
| allow others to potentially succeed.
| dingnuts wrote:
| This is an astute comment, despite "Arathorn" CEO of
| Matrix LLC's downvote ring pushing down the score. (Hey
| bud you know you can just read without commenting, right?
| Sit and listen for awhile)
|
| ActivityPub has the same problem. Browse a Japanese
| MissKey server and it'll start loading yours up with
| questionable drawings. I turned off my server FAST
|
| This is a big, big problem for federated software that I
| have not seen addressed or even frequently discussed.
| Arbitrary file upload by the public is not something
| small operators can reasonably allow on their servers.
|
| Even large operators of non federated systems with
| controlled access like Facebook struggle with this. It's
| impossible to protect yourself as a server operator on
| Matrix or ActivityPub from malicious actors that want to
| use your server to distribute illegal material, and
| you'll be the one found liable!
|
| No thanks!
| jorvi wrote:
| > People new to the system think that Matrix can work. So
| FLOSS devs spend time trying to lipstick the pig. Takes
| time away from other areas.
|
| What I don't understand is how multiple governments and
| militaries are able to make it work. Are they using a
| reduced core-features-only version?
| Arathorn wrote:
| They're typically operating in private or semi-private
| federations, and so aren't so worried about spam/abuse
| issues like the one in question here. They may also not
| care as much about serverside metadata footprint (or
| indeed they may actually require serverside metadata in
| order for the server admins to enforce who can talk to
| who).
|
| As a result, the popularity of Matrix in public sector
| has resulted in focus there - which is somewhat different
| to the expectations of folks looking for a Discord
| replacement or a privacy-at-any-cost solution.
| inferiorhuman wrote:
| As someone who wants to care _not at all_ about the
| implementation details: last week I tried to sign up and use
| Matrix. I just want it to die.
|
| It's got all the downsides of both centralized and
| distributed chat systems. Matrix.org didn't have the username
| I wanted so I went through four different home servers before
| giving up.
|
| Tried to install a cli app (Weechat). Homebrew wanted four or
| five scripting languages, a spell checker, and still no
| Matrix plugin (need to install an abandoned C library for
| that and then wrangle python). The web app is shit. I get
| hijacking Cmd+K (and despise it), but it also hijacks Cmd+`.
|
| Makes me miss IRC really.
| behringer wrote:
| I have a room going on multiple years now.
| INTPenis wrote:
| I used it for a year or so, with the default servers, worked
| just fine. We tried to get a group chat over from Signal to
| SimpleX but were unsuccessful in the end for unknown reasons.
| It just petered out and I didn't reinstall it on a new phone.
|
| Maybe there was no migration?
| ekjhgkejhgk wrote:
| Have you tried XMPP?
| delduca wrote:
| Use keet, true p2p & secure chat. No servers.
|
| https://keet.io/
| juliangoldsmith wrote:
| It doesn't appear to be open source, so users have no control
| or lasting guarantees of privacy.
| maqp wrote:
| Not open source, you can't verify the end-to-end encryption or
| any other measures the client uses actually happen. This makes
| it trivial to hide backdoors.
|
| The entire secure messaging app space is open source, why
| anyone would bother with writing a proprietary app and thus
| omit verifiability of the security claims is beyond me.
|
| EDIT: Also, no proxy settings, meaning your IP address can't be
| masked with Tor/SOCKS5 proxy.
|
| Do NOT use.
| gritzko wrote:
| It's all npm on the inside, if I understand correctly.
| jokoon wrote:
| I use the strict cookie policy on firefox, and set cookies to be
| deleted at shutdown. I just save credentials and login to
| platforms each time.
|
| I joined the mozilla matrix, and ironically, this caused the auth
| system to completely break down for some reason since I would log
| in each time.
|
| It suggested to reset the whatever login data cookie thing
| because it did not want to trust me anymore, displaying red
| warning or whatever.
|
| I asked around, and apparently they disagreed about that strict
| cookie policy, which felt quite ironic coming from the mozilla
| community.
| aprilnya wrote:
| Yes, deleting your encryption keys every time you close the end
| to end encrypted chat app is definitely a great idea
| dxdm wrote:
| I know nothing about any of this and I am surprised to learn
| that something that is apparently considered to be permanent
| is stored in something as ephemeral as a browser cookie, and
| then causes problems if deleted. At least this is how I
| understand the exchange above.
| 0x1ch wrote:
| As the other guy pointed out, you would 100% experience the
| same issues if Signal was a web app. You're deleting your
| encryption keys. They have to be stored somewhere. You want
| private keys on the public server?
| cvwright wrote:
| Don't blame the user - blame Matrix for designing the system
| like this.
|
| > They have to be stored somewhere. You want private keys on
| the public server?
|
| Yes. Encrypted. The feature is called "dehydrated devices"
| and the Matrix team has been working on it for quite a while
| now.
| seanieb wrote:
| Moxie (Signal Founder) gave a talk about the issues with
| federation at CCC in 2020, he took a crazy amount of flak for it,
| a lot of it from the Matrix community. Lots of the issue
| highlighted are in this post.
|
| https://youtu.be/DdM-XTRyC9c
| dijit wrote:
| Yeah, but it boiled down to "we want to move fast and modify
| the client on our whim".
|
| Which, is fair, but if absolute control of the client is
| required then there's no benefit to E2EE.
| 0_____0 wrote:
| The message I got was more "decentralized services have major
| coordination issues that prevent them from adapting to
| changing needs".
|
| Also a major point in Signal's development philosophy is
| building a comms platform that doesn't require that you trust
| them, because the protocol is built in a way that leaks the
| absolute minimum of data about the user necessary to make the
| service usable for the general public.
| 0_____0 wrote:
| Just gave it a listen. A lot of what he asserts seems pretty
| obvious with many examples e.g. the ones he give about IP, DNS,
| email etc. Centralized movers will always have the advantage of
| coordination, so decentralized systems have to have a damn good
| raison d'etre that's immediately obvious (e.g. Tor) or else be
| eventually consigned to niche use in highly idealistic
| communities.
| dang wrote:
| These discussions look related. Others?
|
| _Why federated protocols don 't work (2016)_ -
| https://news.ycombinator.com/item?id=30314454 - Feb 2022 (130
| comments)
|
| _The Ecosystem Is Moving [video]_ -
| https://news.ycombinator.com/item?id=21904041 - Dec 2019 (90
| comments)
|
| _Reflections: The ecosystem is moving_ -
| https://news.ycombinator.com/item?id=11668912 - May 2016 (99
| comments)
| jcgl wrote:
| Here's his original blog post from 2016:
| https://signal.org/blog/the-ecosystem-is-moving/
|
| I go back and re-read this pretty much every time a
| decentralized thing has problems. It rings true.
| maqp wrote:
| >Unlike any other existing messaging platform, SimpleX has no
| identifiers assigned to the users
|
| Lies by omission. SimpleX doesn't mask your IP-address by
| default. It leaks to the server. The ENTIRE public SimpleX
| network is hosted by two companies, Akamai and Runonflux.
| Metadata of two conversing users running on the same VPS can be
| detected with end-to-end correlation attacks, so pray that the
| two are not PRISM partners or whatever has replaced that program.
|
| I'd be fine with SimpleX if they
|
| 1) bundled Tor and had a toggle switch during initial setup.
|
| 2) were transparent about what the toggle switch does
| (lag/bandwidth vs IP masking)
|
| This is crucial as they already have Tor Onion Service server
| infra set up, but they're not making it easy for a layperson to
| use those. Instead they lie by omission. Their
|
| "SimpleX has no identifiers"
|
| only means
|
| "SimpleX does not add additional identifiers"
|
| They don't give a damn about your router gluing your IP address,
| that's increasingly becoming a unique IPv6 address, to every TCP
| packet header.
| HNisCIS wrote:
| Simplex is also going down the crypto drain, they're starting
| their own coin.
| irusensei wrote:
| Didn't knew. Do you have a source on that? Can't see any
| mention of coins in their blog. Are you maybe referring to
| the crypto exchange with the same name that normally appears
| on top of google searches?
| epoberezkin wrote:
| That is untrue.
|
| We do not plan any coins.
|
| We plain a private payment mechanism for the servers that
| will utilize blockchain for valid reasons - we call it
| Community Vouchers. But they are not coins, they are service
| credits that cannot be created out of nothing (as coins) and
| cannot be sold - they can only be used to pay for the
| servers.
|
| It's covered here: https://simplex.chat/vouchers
|
| Whitepaper on that design will be published in early 2026.
|
| Disclaimer: I designed SimpleX network
| wkat4242 wrote:
| Hmm that's still very 'crypto'.
|
| I understand that servers need to be paid for but that's
| why I run my own matrix server. So I pay for that and for
| the users on it. Much nicer than having to trust another
| party to run them.
| adamthegoalie wrote:
| What's wrong with being "very 'crypto'" when you use a
| real use case crypto can solve?
| j45 wrote:
| Feels like a use of a ledger technology where everyone is
| a stranger in a way that isn't a credit and debit system
| in a relational databse.
| chaps wrote:
| "Buy Community Vouchers. Initially you would pay with a
| stablecoin (USDT/USDC). "
|
| You're literally requiring people to buy specific
| cryptocurrencies to buy your community vouchers.
| epoberezkin wrote:
| > "SimpleX has no identifiers" only means "SimpleX does not add
| additional identifiers"
|
| These two statements are identical. IP addresses are Internet
| user identifiers, not SimpleX identifiers. All other
| application-level networks have identifiers of their own, in
| addition to IP addresses.
|
| The goal of the design is: - to prevent correlation of which IP
| address communicates with which, - to prevent IP address from
| servers not chosen by the users.
|
| It is not supposed to protect IP addresses from all servers,
| and Tor does not achieve that either, as Tor relays are servers
| too.
|
| The reasons not to embed Tor are listed here:
| https://simplex.chat/faq/#why-dont-you-embed-tor-in-simplex-...
|
| Disclaimer: I designed SimpleX network, and the founder of
| SimpleX Chat.
| maqp wrote:
| >These two statements are identical. IP addresses are
| Internet user identifiers, not SimpleX identifiers.
|
| You are promoting SimpleX as an metadata-privacy improvement
| over Tor Onion Service based messengers like Cwtch, that
| hides the IP address by default. IP-addresses can be linked
| to users, and users will have to blindly trust the server is
| not collecting them. TelCos and ISPs keep logs of those as
| per data retention laws, so it's not hard to determine who a
| SimpleX user is if SimpleX wants to disclose that
| information.
|
| >to prevent correlation of which IP address communicates with
| which
|
| Which Akamai can do, and Runonflux can do. With 50%
| probability on per-target basis I might add.
|
| >It is not supposed to protect IP addresses from all servers,
| and Tor does not achieve that either
|
| Tor relays actively mask the IP of previous node from the
| next node.
|
| Tor relays do not have access to internal protocol of SimpleX
| queues etc. SimpleX servers do, so they can collaborate with
| better efficiency.
|
| Tor relays are chosen at random by the user, and random
| collaborating entry/exit nodes expose 10 minute windows for
| ciphertext-only metadata collection without access to IPs.
| SimpleX has 50% chance same company runs the server of both
| users.
|
| >Tor does not achieve that either, as Tor relays are servers
| too.
|
| This is ridiculous. You're effectively arguing, that because
| Tor isn't literally magical in being able to send TCP packets
| without IP addresses in headers, it's not significant
| improvement. As I showed you last time, the NSA itself has
| admitted they will NEVER be able to deanonymize all Tor users
| all the time, and that nor are they able to do that on-
| demand. Which is quite different from your "we run servers on
| two VPS companies ourselves, but pinky promise, they don't
| aggregate and correlate information."
|
| >I designed SimpleX network, and the founder of SimpleX Chat.
|
| I know. We two have had a looong conversation about this,
| first in Reddit, then here, then in privacyguides forum, and
| now again, here. Every single time you run to the hills.
|
| Link your open, honest, non-misleading threat model to your
| front page. Make sure it makes it extremely clear that
| "Unless you install and configure Tor, SimpleX client does
| not take actions to hide your IP-address from the server".
|
| I mean, look how professional https://tryquiet.org/ looks
| when the treat model is up there in the title bar, and not as
| a fine print behind menus.
|
| Do that and we're done. I won't call you out anymore.
| marigolds wrote:
| I wondered from the beginning why matrix was adapted so quickly.
| It's cryptographic protocol is so flawed. Most of the leaks could
| be easily prevented.
| HNisCIS wrote:
| There were no good alternatives at the time. They were
| competing largely with Telegram and Whatsapp so basically
| anything was seen as an improvement. Since then Signal has
| gained popularity and set a much more robust standard for
| implementation, instead of hollow feature count.
| pojntfx wrote:
| I still wonder why my experience and the experience of my
| friends, community and family with Matrix has been so positive
| compared to what people describe all of the time. Maybe it's
| because something changed in ~2025 when I started using it again?
| Both Beeper (my main Matrix provider, the one that preconfigures
| WhatsApp, Signal, SMS etc. bridges) and Element (the new mobile
| app and EMS for hosting). I onboarded something like two dozend
| non-technical people to it, and they are all happily using it
| every day, mostly to use the bridges that come with Beeper.
| Haven't heard a single complaint, even switching devices just
| works now. Almost all communities I care about (GNOME and so on)
| have Matrix servers, and since the spaces feature launched it's
| been really competitive with Discord, even UX-wise thanks to the
| new apps on desktop and mobile. Yet all I hear on HN and
| elsewhere is people complaining about UX issues that just have
| not appeared a single time for myself. Maybe it's people using
| non-compliant clients, old servers, or some other strange
| configuration? It's a mystery to me.
| 0x1ch wrote:
| Self hosting experience went well, but it was very confusing
| for people moving from Discord about a year ago. If it's still
| the same, there's literally no way to simply send a
| registration or channel invite link to someone, and have them
| onboard through your home server by default without the need to
| explain "Oh, you have to change this URL to that" etc.
|
| My primary issue is that they changed the voice chat system,
| broke existing self hosted installs, and the new system was
| barely documented. I threw in the towel since I mostly hosted
| it for myself. Could never fix their livekit stuff.
| Arathorn wrote:
| My best theory here is that because Matrix is actually quite
| close to being really good, folks get _very_ upset about the
| remaining flaws, especially when the last few years have had to
| prioritise development for public sector deployments over being
| a Discord killer, in order to keep the lights on.
| rapnie wrote:
| Yes, that is my impression also. Extensively using for a
| couple of years, and only occasional quirks now and then,
| e.g. a profile verification issue (seeing the annoying red
| shields to each comment), but easily fixed. Or a UX update
| that doesn't necessary feel improvement (this is an Element
| thing, really).
|
| It may not be good enough for your grandma, but certainly can
| support your software dev team, and there are countless of
| those active most probably. I really like Matrix as a daily
| driver. Also using Discord and Slack, and to me these look
| like a UX Christmas trees full of blinking lights, and far
| from anything you can call 'calm technology'.
|
| Update: Seeing who I respond to, taking opportunity to
| mention these recent UX musings.. there used to be
| 'favorites' in one click in Element, now it is in a drop-down
| of filters not shown by default (I make distinction of 3
| groups 'favorites', 'people', and 'rooms' for all/other. Not
| using spaces at all (except for the record)). And then
| there's paragraph spacing between replies given one after the
| other, is to small. Setting margin to 10px (think its 4px
| now) makes a world of improved reading already. Element web
| UI in firefox. Oh, I might add very long UI (re)loading times
| of a browser tab refresh of Element, as somewhat annoying and
| to avoid.
| Arathorn wrote:
| > Update: Seeing who I respond to, taking opportunity to
| mention these recent UX musings
|
| Thanks - the Favourites roomlist section will be back
| shortly; we just hadn't re-added sections to the rewritten
| roomlist (and in retrospect, probably shouldn't have
| launched without it). In fact I think they've already
| landed (experimentally) on the same roomlist component but
| in the Element X Web playground at
| https://github.com/element-hq/aurora.
|
| > And then there's paragraph spacing between replies given
| one after the other, is to small. Setting margin to 10px
| (think its 4px now) makes a world of improved reading
| already.
|
| Hm, is that new? Probably something to propose for the
| compact layout.
| wkat4242 wrote:
| > Thanks - the Favourites roomlist section will be back
| shortly; we just hadn't re-added sections to the
| rewritten roomlist (and in retrospect, probably shouldn't
| have launched without it). In fact I think they've
| already landed (experimentally) on the same roomlist
| component but in the Element X Web playground at
| https://github.com/element-hq/aurora.
|
| That's not a complete fix though. The split between users
| and groups was also really important. Because the old
| view showed the top X chats in both categories at the
| same time. I'm not sure about others but for me the group
| chats are less important but update more frequently and
| when they're bunched together the individual user chats
| get drowned out. Favouriting them all isn't really an
| option either as I have too many.
|
| There's a filter now but then you don't see group chats
| at all unless you turn that off again, making it very
| restless to have to constantly switch.
|
| However it's great to see the favs are coming back.
| Arathorn wrote:
| Given the people / rooms section split was my idea in the
| first place, i can try to make a case to have it as an
| option. (Interestingly I haven't missed it much)
| Avamander wrote:
| I think you're partially correct. People are upset at the
| time it takes to land even the most basic of fixes. Replies
| being bright red might be one of the most indicative
| examples. So while the work towards public sector deployments
| has probably helped with some aspects, the user-facing side
| has stagnated and people dislike that.
| pkulak wrote:
| Yup, this makes sense. I host a Matrix server, and it's
| equivalent in quality to Discord or anything else. Except
| that I've had a single unread badge on my account on iOS for
| at least a year now. It drives me nuts.
| Arathorn wrote:
| yup. https://github.com/element-hq/element-x-
| ios/issues/3151 is a real wart; we're _finally_ at the
| point now where the push notification process can
| synchronise with the main process to get the badge count
| right. Sorry it 's taken so long to fix.
| wowthatsucks wrote:
| My experience has been in an enterprise environment but
| Matrix still falls way short of common enterprise messaging
| suites like Slask or even Teams. The effort has mostly been
| in managing channels.
|
| The recent mandatory room version upgrade required a lot of
| real coordinated effort across our org.
| TheCraiggers wrote:
| I'm in the same boat. I manage my own server with tons of help
| from the ansible script(0) and it's generally been great for
| years.
|
| I can only assume our experience in private servers is way
| different than people logging into the matrix.org server or in
| extremely populated rooms?
|
| (0): https://github.com/spantaleev/matrix-docker-ansible-deploy
| lbotos wrote:
| Can also vouch for this ansible script. I just updated a very
| outdated homeserver, postgres, and switched from nginx to
| traefik, and it was extremely painless. I was dreading it,
| but it worked amazingly. I donated to the author yesterday
| because of how well it went.
| bigstrat2003 wrote:
| For what it's worth, I have had zero issues with Matrix myself.
| Some friends and I use it to stay in touch and we have had a
| very smooth experience. I'm not trying to discount the issues
| people have had, but for me Matrix has Just Worked (TM).
| mmooss wrote:
| Much of the OP is about Matrix's security. What is your
| experience with that?
| the__alchemist wrote:
| Element web and PC applications are _still_ , in 2025, a mess. I
| have heard you have to use it on Mobile using the ElementX.
|
| No new complaints: The standard it badgers you to authenticate,
| then doesn't let you due to errors. Slow to load messages,
| inconsistent whether edits will show or not, inits channels to an
| arbitrary time in the past, then you have to click the arrow a
| few times and wait to get to the latest, the page won't load on
| mobile, etc.
| Arathorn wrote:
| Yup, work has been going into refactoring Element Web into MVVM
| components so we can switch out the ancient matrix-js-sdk
| underpinnings with the same matrix-rust-sdk that is a day-and-
| night improvement. https://element.io/blog/element-x-web-a-
| glimpse-into-the-fut... gives an idea.
| ceroxylon wrote:
| As someone who has witnessed a malicious Matrix admin, it has
| become glaringly obvious that operating on a platform that hinges
| on any sort of trust in a human who can oversee metadata (even
| those who you consider to be good friends) is not viable.
|
| I wanted to believe, but sadly privacy must be hard-coded or the
| people with a large set of technical skill, access to AI agents
| who will restlessly pursue their mission, and a dysfunctional
| moral compass will attempt to technologically dominate users.
| ilvez wrote:
| care to elaborate was it encryption they targeted as well?
| orionspelt wrote:
| It's all soylent green in the end; people.
|
| There's no decentralized protocol as they're centered around
| their developers. Too much human effort and attention has been
| centered around software.
|
| The ephemeral gibberish of software developers approaches
| religious like obsession with sigils and notation levels of
| absurdity. Believe in their scripture! It will see humanity to
| the promised land!
|
| Meanwhile in meat space everyone I socialize with is tired of
| software engineers; "they over complicate everything!" is a
| common refrain.
|
| This little filter bubble is probably fostering asocial mental
| illness's in many of its disciples
| kayo_20211030 wrote:
| This post is madness, but apposite madness. All systems are
| ultimately their creators; with everything they believe encoded
| in some way.
| orionspelt wrote:
| The VC on the mound doth shout "Who will make thy line go
| up!"
|
| Upon this a roar from the Rubicon Cathedral; we shall make
| your line go up!
|
| From the Pycon Papalcy; we shall make your line go up!
|
| From the NoCode Choir; we shall make your line go up!
| wkat4242 wrote:
| > Why Federation Must Die
|
| I disagree so much. Yes Federation is hard and it brings lots of
| new challenges. But with things like Chatcontrol it's the only
| way we can continue to communicate securely in the EU. Everything
| that is not federated has a single entity managing it which can
| be threatened with punitive actions. With federation everyone can
| run their own server meaning too many people to go after.
|
| I understand these guys don't want it and they have good reason
| but federation in general should not die.
| lucideer wrote:
| It sounds like you haven't read the article. They're advocating
| for fully decentralised protocols over federated ones.
| wkat4242 wrote:
| Fair enough I haven't had a chance to read the whole thing
| through, just had to skim eg the Matrix criticism. But if
| it's completely decentralised, why are there servers that
| must be paid?
|
| Anyway I'll read it tonight when I have more time.
| ekjhgkejhgk wrote:
| Same. Also, see how cool Mastodon is. Sure, it has technical
| problems, for example discoverability is harder. But so what?
| Preventing centralization of control is more important than
| more mundane things like "discoverability".
|
| And in fact, discoverability on Mastodon is only less immediate
| because you don't a central authority making these decision for
| you. Nothing prevents you from checking out someone who follows
| and see who follows them and who they follow. It's more work,
| but you end up with a better result.
|
| People who says "discoverability on Mastodon is difficult"
| presumably also say "I don't want to have to decide who my
| friends are, I want a corporation to choose my friends for
| me"...?
| jdgoesmarching wrote:
| My friends are in real life, not on Mastodon or Bluesky.
|
| Not everyone interested in doing detective work to find
| accounts related to their interests. It's perfectly
| reasonable to expect social media platforms to help with that
| discovery.
|
| If preventing centralization is important to you, then you
| should care about the product experience of the decentralized
| platforms.
| Arathorn wrote:
| Btw, if anyone wants to read the flipside to this, I just posted
| the annual Matrix holiday update:
| https://matrix.org/blog/2025/12/24/matrix-holiday-special/
|
| Happy holidays, HN... :)
| lucideer wrote:
| The table comparisons here of Simplex vs Signal, XMPP & Matrix
| don't seem particularly interesting (like for like) beyond
| demonstrating the general differences between decentralised &
| federated systems.
|
| Has anyone done a comparison between Simplex & any specific P2P
| systems (the P2P coverage in this article is extremely vague &
| handwave-y) - e.g. something like Scuttlebutt?
| anilakar wrote:
| We've been happy Matrix users. Apart from less technical folks
| losing their encryption keys every now and then and certain other
| users having issues with flatpak permissions it's been an
| uneventful experience... until now. We're losing a domain due to
| contractual obligations and it seems the only way to migrate to a
| new one is to start over.
| Arathorn wrote:
| ugh, sorry. https://github.com/matrix-org/matrix-spec-
| proposals/pull/424... should help significantly with this, and
| is due to happen in 2026 (it's required for Hydra Phase 2). But
| it's not there yet.
| mkoubaa wrote:
| Death by a thousand features. A cryptographically secure simple
| listserv is _well_ within reach
| tptacek wrote:
| I don't have opinions about Matrix (a more-secure version of
| Discord or IRC seems like a reasonable thing to want) but want to
| put a word in for reading the Nebuchadnezzar paper, which is kind
| of a master class in cryptanalyzing secure messaging protocols,
| and really drives the point home that the hard part of a group
| secure messaging system isn't encrypting messages (anybody can do
| that) but rather in securely managing group membership without
| trusting servers:
|
| https://nebuchadnezzar-megolm.github.io/
| packetlost wrote:
| Combining something like FOKS (https://foks.pub) to a messaging
| system would be pretty neat
| inopinatus wrote:
| I just read through the Matrix protocol documentation, coming
| to it from never having heard of Matrix before, and I have to
| say, it is hot garbage, reading like someone with no
| distributed systems background and hasn't heard of lamport
| clocks or virtual synchrony vibe-coded a shonky mashup of IRC
| and XMPP and then tried to copy-paste Signal's crypto in the
| middle. There are early warning signs in which it extensively
| reinvents endpoint name resolution, by the time you get to the
| twelfth attempt to build consensus over group state by sorting
| a DAG you may, like me, realise their entire project is a lost
| cause.
|
| Matrix for me just went from, "what is this?" to being, "not
| touching that with a barge pole". You could probably build
| yourself a group chat more worthy of trust using NNTP+gnupg and
| a couple of shell scripts.
| tptacek wrote:
| I think you're looking at the outcome of attempting to design
| a secure open federated system for 12 different major kinds
| of user, not so much a lack of understanding of distsys
| stuff. The real problem is federation.
|
| Notably, though, very few systems get the group membership
| problem right; this is a thru-line of secure messaging
| research results.
| inopinatus wrote:
| Well, you're a little kinder than me, but I also agree
| entirely; and notwithstanding that it's certainly a hard
| problem, I'd hoped/expected to find end-to-end behaviours
| at the heart of distributed consensus in a modern protocol,
| and instead it was "the servers are in charge" all over
| again, cue disappointed frown.
| tptacek wrote:
| I think I'm being less kind and more pointed, in that I
| think security is too much to hope for from any federated
| group secure messenger.
| inopinatus wrote:
| Perhaps you put your finger on it before, in that given
| the current state-of-the-art, the range of needs is
| simply too diverse to be met by a single paradigm.
| Nevertheless I still retain that hope, being disappointed
| by one effort didn't break my faith in progress.
| exceptione wrote:
| Is that on theoretical or practical grounds? I would love
| to learn how you would approach the challenge (no snark).
| I feel lots of developers miss the needed background,
| pour in a lot of work and then be stuck with it. How can
| we avoid that?
|
| Is there some settled science, some principles and
| patterns in distributed security? Like, you want A, now
| you can only have option 1 or 2. But if you want B too,
| this only leaves you with option 2, provided you satisfy
| D too. But the combo D+B rules out any E.
| tptacek wrote:
| No, there's no science to it at all; it's just a
| collective action problem. You saw it in Matrix's effort
| to get all their clients encrypted by default (they were
| hamstrung by an installed base of popular clients that
| didn't work that way), and again in the response to
| Nebuchadnezzar.
| exceptione wrote:
| That sounds like a social problem again. What
| foundational materials would you recommend to read though
| for anyone trying to build something secure and non-
| centralized? It is a pity that everyone spends a lot of
| effort in this area, only to learn they did it wrong and
| having to deal with unfortunate design decisions. That
| is, if they are honest about it.
| tptacek wrote:
| You can build secure and noncentralized! What you can't
| do is build secure and _federated_ , where everyone lives
| in a shared, broadly reachable namespace comprised of
| independently operated instances.
|
| I simply wouldn't build a secure group message system to
| begin with. It's a treacherously hard problem and the
| very few people who have done it well accomplished that
| with major UX compromises that put them at long-term
| disadvantage against schlock like Telegram, and survived
| mostly due to force-of-nature word of mouth.
|
| If you're going to try, and you want to be rigorous about
| it, I'd say you need to start by reading the _whole_
| history of cryptanalyses of secure messaging systems,
| even systems you don 't care about. Read the papers
| carefully and work out the attacks for yourself. It's a
| little like math in that you're only going to figure it
| out by actually working the examples yourself.
| ekjhgkejhgk wrote:
| I disagree that federation must die. Federation has problems, but
| it solves the most important point which is to avoid that one
| company controls everything. Whether you have identities, or
| servers associated or bla bla bla all of that is secondary to
| preventing centralization of power.
| MerrimanInd wrote:
| Like any opposition party, the anti big tech crowd is actually a
| loose coalition of different goals and interests. I've noticed
| that as these platforms get through the earlier stages of "will
| it even work" the differences in values are becoming more
| pronounced and controversial. The primary two groups seem to be
| those who value federation and see centralized control and
| algorithms as the threat and those who value encryption and see
| surveillance as the threat. Obviously these two things aren't
| mutually exclusive and we all want to see new platforms that can
| solve for both. But there's a quite distinct difference in the
| primary priority and consequent technical decisions.
|
| I hope maybe if we can be aware that this is a broad set of
| technologies being driven by a broad set of goals then we can be
| a bit more gracious when a project isn't perfectly aligning with
| our personal values and find the common ground and values.
| Havoc wrote:
| That's a pretty lengthy list.
|
| The illegal content one is I think the most problematic. Meta and
| friends don't employ teams of psychological scarred content
| moderators for giggles...
| orthecreedence wrote:
| So why not centralize THAT? Build federated (or hell, p2p)
| protocols and pay some company that has editor access JUST to
| do moderation.
|
| There are tons of systems where it's decentralized up until the
| point where centralization makes sense. It doesn't have to be
| all or nothing.
| Arathorn wrote:
| this is what we effectively did with
| https://matrix.org/blog/2025/04/introducing-policy-servers
| (on a per-room basis). the OP is from 2024, and so predates
| this.
| arunc wrote:
| Not alone. We started with Matrix, but we are very happy with
| Zulip now.
| orthecreedence wrote:
| I have to say, this comes across as incoherently babbling by
| someone with an axe to grind. The things they say are bad about
| Lemmy/Matrix are in conflict with the other things they want.
|
| The person who wrote this just wants a centralized, moderated
| chat/social media system. Use Discord/Slack/Reddit if you don't
| like the resiliency of decentralized systems. There are some
| legit gripes in this massive list, but 90% of this reads as "I
| want Matrix to be centralized!" Good news, that exists already!
| mmooss wrote:
| I don't know enough to comment on the accuracy, but almost all
| of the page is about security holes in Matrix, and then how
| their preferred service, SimpleX, is both decentralized and
| doesn't have those holes.
| foresto wrote:
| Why I chose not to use SimpleX after investigating it last year:
|
| - No multi-device support. I want to send and receive messages
| using any of my devices, independently, no matter where they are.
| (Being able to tether a phone to a computer is not sufficient.)
|
| - Messages are dropped if not retrieved a timely manner. 21 days
| by default, which is shorter than some of my vacations.
|
| - It was not clear to me what happens to undelivered messages
| when a queue server crashes, loses power, or reboots for
| maintenance.
|
| - Establishing a chat requires sharing a large link or QR code
| through some out-of-band channel, which I often find
| inconvenient.
|
| - Funded almost entirely by venture capital. This suggests to me
| that it is likely to either vanish or turn to some form of
| exploiting users, eventually. I don't want to build my contacts
| network upon that foundation.
|
| - It was not clear to me who controls the queue servers, what
| incentives exist for their operators, or how their maintenance is
| funded. Absent that information, I must assume that most or all
| of them are run by the same people, making it a hair's breadth
| from a centralized service.
|
| - Frequently repeated marketing claims of having no user IDs,
| when its message queue IDs _are_ user IDs. The privacy
| improvement vs. a traditional service is through generating a
| distinct ID for sharing with each contact in 1:1 chats. (Group
| chats do not have this feature.) While I consider this valuable
| (it 's like automatically giving you a separate email alias for
| use with each contact), I despise that it was presented as
| something that it is not. Perhaps they have stopped making the
| original claim by now, but even if so, the fact that they lied to
| people in the first place makes me unlikely to entrust my
| communications to them.
|
| I prefer Matrix. I'll comment separately regarding why.
| foresto wrote:
| I've been on Matrix for 6 years or so. Some of that time was
| painful (especially when the largest public server was overloaded
| by a surge of new users in 2020). It's better now. I can't
| remember the last time I saw a decryption failure.
|
| I still have gripes about it. Improvements to the spec and
| software have been slow lately, due to funding issues. But they
| are still arriving. The official desktop client remains buggy,
| bloated, and cluttered. But there are lighter alternatives that
| do what I need 99% of the time. Much of the meta-data is not yet
| end-to-end encrypted. But that's still planned, and since it's
| not as important in my day-to-day chats as it might be if I were
| whistleblowing, I'm willing to wait.
|
| I continue to use Matrix because there is nothing else offering
| the combination of features that I most value in it. Notably:
|
| - decentralized
|
| - 1:1 and group chats
|
| - offline message delivery
|
| - multi-device support
|
| - end-to-end message encryption with well-understood ciphers and
| protocols
|
| - easy enough that I have brought in non-tech-savvy contacts with
| very little assistance
|
| - cross-platform, on every major desktop and mobile OS
|
| - not tied to google services or libraries
|
| - open-source
|
| - free (in both senses)
|
| - self-hostable
|
| - reasonably anonymous; no need for a real name, phone number, or
| (depending on homeserver) even an email address
|
| - (in development) scalable audio/video chat that looks very
| promising
|
| Harder to quantify, but also worth acknowledging: The project
| lead seems very level-headed, demonstrating good judgment and
| tremendous patience, and consistently makes himself and the inner
| workings of this difficult project accessible to the public. This
| gives me the sense that Matrix continues to develop with sound
| guidance. Thanks, Arathorn!
| Arathorn wrote:
| thanks for sticking with it and the vote of confidence. totally
| agreed that Element Web has issues (i'm currently having to run
| a custom fork to stop it OOMing thanks to
| https://github.com/element-hq/element-
| web/issues/27983#issue...); hopefully switching to matrix-rust-
| sdk will be a huge improvement; https://github.com/element-
| hq/aurora is already looking promising.
___________________________________________________________________
(page generated 2025-12-24 23:01 UTC)