[HN Gopher] Matrix Conference 2025 Highlights
___________________________________________________________________
Matrix Conference 2025 Highlights
Author : Arathorn
Score : 124 points
Date : 2025-10-20 12:00 UTC (11 hours ago)
(HTM) web link (element.io)
(TXT) w3m dump (element.io)
| bilal4hmed wrote:
| Compared to Signal, where does element stand today in terms of
| privacy and encryption? Due to the decentralized nature they
| werent able to offer the same guarantees from what I remember
| singpolyma3 wrote:
| It's exactly the same encryption tech, but a bit more
| trustworthy than signal.
| bilal4hmed wrote:
| can you expand on how its more trustworthy than signal?
| candiddevmike wrote:
| You can validate the code that's running on the client and
| the server, in theory
| jeroenhd wrote:
| You can validate the code running on the client (well,
| not on iOS, but that's true for all iOS apps unless
| you've jailbroken your phone).
|
| If Signal works well, you shouldn't need to validate what
| code is running on the server in the first place.
| holowoodman wrote:
| With Signal, you can't really validate the code running
| on the client. Signal insists on distributing only via
| Google Play Store or Apple App Store, so usually updates
| are automatic and uncontrolled by you. And Signal has a
| history of not releasing timely updates of their client
| code, so even if you would do your own builds or compare
| their released code to their public updates, you would
| have at least a few weeks latency. And I doubt anyone
| would notice, since the Signal people tried hard to piss
| off everyone who did reproducible builds of their code.
| tredre3 wrote:
| In theory you can do the same with Signal, as they source
| dump their server code every now and then.
|
| If you reject that on the basis of "we can't know if it's
| what they're running" or "it's a partial dump", then I
| don't see how Matrix is any different. Not only we can't
| know if Matrix servers have modified software, but we
| also have to trust/verify several servers instead of a
| single one.
| dijit wrote:
| The fundamental difference boiling down to trust isn't
| primarily in the cryptography; it's entirely down to the
| infrastructure and the root of control.
|
| Signal is widely regarded as the gold standard for
| centralised E2EE, but its architecture forces you into two
| massive, non-negotiable trust compromises:
|
| 1) You must trust the Signal corporation with all your
| metadata. Every routing and handshake detail passes through
| one single choke point that they control. That is an
| unacceptable risk for security-minded users.
|
| 2) You rely completely on Signal to truthfully publish a
| pre-compiled binary that actually reflects the open-source
| code. For the vast majority, this is unverifiable in
| practice. It's a critical client-side act of faith.
|
| Matrix's design fundamentally eliminates these single
| points of failure, shifting the root of trust squarely to
| the user (or a group you trust):
|
| 1) Self-hosting; This is the game-changing feature. Host
| your own Synapse/Dendrite instance. Your metadata never
| leaves your control. You move the trust boundary from a
| corporation to yourself. You genuinely achieve "no
| communication outside your control."
|
| 2) Matrix uses an open specification. You can use
| FluffyChat, Nheko, or Element. This breaks the coupling
| between the server and the client. Even if you rely on a
| third-party server, you can use a client built by a
| completely different team, making the client-side code
| independently auditable and verifiable across projects.
| This is the ultimate defence against subtle backdoors in a
| single vendor's binary.
|
| TL;DR: Signal offers "trusted third-party" crypto running
| on a single, unauditable binary. Matrix is decentralised,
| verifiable zero-trust communication. The comparison isn't
| about the strength of the AES key or which data it has been
| applied to; it's about the architectural freedom to not
| have to trust another entity with either your data or your
| code. That freedom represents an essential leap in
| trustworthiness.
| Etheryte wrote:
| You might be making good points, I'm not familiar enough
| with the context to tell, but whining about downvotes is
| in bad taste, so a large part of your downvotes probably
| come from there, mine included.
| dijit wrote:
| Apologies, it's frustrating watching my comment go from
| +5 to -2 in a handful of seconds.
|
| Not that I'm into karma farming (or that it even means
| anything), but it irritates me to think that people are
| gaming the discourse here.
|
| There's an implicit groupthink when it comes to seeing
| greyed out comments; to the point that people may (and
| do) think that the comment is non-factual or at the very
| least unpopular. This is especially true in subjects that
| are critical of Signal.
| Etheryte wrote:
| There's eight billion something humans on the planet, I
| think it's pretty okay if seven of them disagree with
| what you're saying.
| dijit wrote:
| Yeah.
|
| Just weird that they all found my comment at the same
| time.
|
| .. and it happens, _every_ time, a slow build up of
| points, maybe some ups and downs, then suddenly it falls
| off a cliff. It 's.. it's too perfect.
| Etheryte wrote:
| Quoting the guidelines [0], if you think that's really
| what's happening, you can try reaching out to the mods.
|
| > Please don't post insinuations about astroturfing,
| shilling, brigading, foreign agents, and the like. It
| degrades discussion and is usually mistaken. If you're
| worried about abuse, email hn@ycombinator.com and we'll
| look at the data.
|
| [0] https://news.ycombinator.com/newsguidelines.html
| nxor wrote:
| Unfortunately, many people work this way: "I don't like
| this, therefore it's false"
| jazzyjackson wrote:
| Super nice summary. Makes me want to use Matrix again,
| but the clients have all been very poor in my experience.
| Element on desktop was okay and I used it for work
| without issue, but it's not nearly as slick as "scan this
| QR code and import your contacts" (oh that's another
| difference, your ability to use the network is governed
| by Signal allowing you to register an account, typically
| requiring a phone number for bot prevention, which seems
| like an extreme step for an app that aims to keep you
| anonymous.)
| heinrich5991 wrote:
| It's less encrypted. E.g. you'd think that emoji reactions
| are end-to-end-encrypted (as they are in Signal). But they
| aren't[1]. I expect similar implementation issues wrt. the
| encryption in Matrix.
|
| [1]: https://github.com/matrix-org/matrix-spec/issues/660
| some_furry wrote:
| This is factually incorrect.
|
| https://soatok.blog/2025/02/18/reviewing-the-cryptography-
| us...
|
| https://soatok.blog/2024/08/14/security-issues-in-matrixs-
| ol...
|
| Signal uses a whole suite of modern cryptography, including
| post-quantum ratchets for key agreement and zero-knowledge
| proofs for group membership.
|
| Meanwhile, Matrix has a plaintext mode and knowingly shipped
| libraries with side-channels for _years_ , by their own
| admission (and left many clients in the ecosystem depending
| on the vulnerable C implementation when they rewrote their
| cryptography protocol in Rust).
|
| Even today, they are not the same protocol. Olm/Megolm is
| distinct from Signal in a lot of ways that I've outlined in
| my previous blog posts.
|
| I don't particularly care if people like Matrix, but please
| don't spread falsehoods about the cryptography being used.
| _def wrote:
| I think these two topics need to be looked at a bit separately,
| similar to for example WhatsApp, where you have e2ee but there
| are still lots of privacy risks.
|
| In the matrix ecosystem, as far as I understand, having only
| one user from the matrix.org homeserver in your room already
| undermines metadata privacy to some degree. Also, there still
| are issues with decrypting messages from time to time with
| certain combinations of clients, rooms and homeservers, which
| effectively means that the "failsafe" option for getting
| messages across the network is using unencrypted rooms.
|
| Having free, secure, federated, usable instant messaging is
| still not solved imho, and I think it's not easy to solve. So
| far matrix is the best attempt in my book, but it's also not
| there (yet?).
| uyzstvqs wrote:
| > So far matrix is the best attempt in my book, but it's also
| not there (yet?).
|
| IMO XMPP is the best attempt so far, but it's completely
| outdated by today's standards. Matrix is a modern attempt,
| but it's just bad. I doubt that Matrix will actually get
| anywhere usable in the future.
|
| It's absolutely possible to build such a protocol with high
| performance, seamless UX, Signal's level of privacy and
| security, and Discord's level of features. It's just _a lot_
| of work to actually build the specifications and flagship
| implementations, compared to just building a good centralized
| option.
| _def wrote:
| On XMPP, I agree. I think requirements also changed a lot
| over the years with smartphones and mobile internet access
| everywhere.
|
| And yeah it's definitely possible, but it's a lot of work,
| both technically and from an organizational perspective
| (funding, governance, etc).
| upofadown wrote:
| >I think requirements also changed a lot over the years
| with smartphones and mobile internet access everywhere.
|
| I recently started using an XMPP client on a smart phone
| (Cheogram, fork of Conversations). It handles that stuff
| remarkably well. Switching between, say, mobile data and
| WiFi takes seconds. It seems to have some way of noticing
| the loss of connection and immediately fires up a new TCP
| connection on the new medium.
| Arathorn wrote:
| > Matrix is a modern attempt, but it's just bad. I doubt
| that Matrix will actually get anywhere usable in the
| future.
|
| Obviously I'm biased, but I seriously suggest looking at
| the various vids from the Conference. Matrix has definitely
| had some ups and downs in the past, but right now it is in
| a good place.
| jeroenhd wrote:
| Matrix allows for unencrypted messages so it's inherently less
| encrypted than Signal. The federation capability also means
| messages leak metadata. Furthermore, encrypted messages also
| contain some metadata in the unencrypted envelope. Some
| protocol features (emoji reactions) also ended up outside of
| the encrypted envelope because of that. It's a risk with any
| protocol that has encryption bolted on and optional.
|
| On the other hand, you can host your own Matrix server and
| still participate in the network, whereas Signal will have you
| convince your friends and family to install a custom Signal
| client if you want to run your own Signal server, for instance
| because you don't want to rely on Amazon's servers (Signal was
| down when Amazon went down this morning).
|
| Signal sacrifices network openness for encryption capabilities.
|
| There's also the MLS/MIMI side of things, but AFAIK that work
| hasn't been completed yet (MIMI isn't even a full RFC yet).
|
| Element/Matrix, with some modifications, has been chosen as the
| messenger of choice by the French government (Tchap) as well as
| the German military (BwMessenger, BundesMessenger) and
| healthcare (TI-Messenger).
| nxor wrote:
| Somewhat related - Can someone explain this to me? France and
| Germany want to lessen dependence on American organizations,
| so they choose Matrix, also an American organization.
| dijit wrote:
| If it's open source (and libre software) then it's not as
| important where the main development offices are (or where
| the company is incorporated). You still have control.
|
| Seems like the majority of the team are in the EU anyway:
| https://matrix.org/foundation/about/
| nxor wrote:
| Thank you, and I see it's registered in the UK. I think
| it started in the US? Well, not like it's relevant
| anymore. And can you answer this question: If everyone
| has secure chat, then won't that benefit criminal
| organizations? I struggle to understand the love for
| private communication when it seems like that would
| benefit, for example, religious sects and sex abuse
| rings. NOT that I like that Zuckerborg keeping all my
| messages.
| dijit wrote:
| > If everyone has secure chat, then won't that benefit
| criminal organizations? I struggle to understand the love
| for private communication when it seems like that would
| benefit, for example, religious sects and sex abuse
| rings. NOT that I like that Zuckerborg keeping all my
| messages.
|
| Yes, sort of.
|
| The thing is, the government is already not permitted to
| wiretap people, at least without reasonable suspicion.
|
| Wiretaps themselves are not admissible in court, and can
| only be offered as a mechanism to correlate behaviour
| _anyway_. At least in the UK. (Which, is ironic when you
| consider what 's going on there with online speech, but I
| digress).
|
| Factually speaking, in order to do a crime you have to
| physically do a crime, the police knowing when and where
| do not require access to your communications to figure
| out. They will sting people, get people to turn on other
| people or simply catch red-handed when doing ordinary
| police work.
|
| If we legitimately believe what the governments of the
| world are saying: that we need to embolden the police.
| Then funding them properly is the right start, yet nobody
| seems to be doing that. The EU _has_ been making cross
| border communication easier though, which _is_ in-line
| with emboldening the police, so I 'll give them that.
|
| Having more information will do very little to help, for
| the same reason that phone taps aren't given out freely
| (and never have been) - because even if you have the
| data, you have to choose how to act on it, and you'd need
| the resources to investigate and follow-through.
|
| There is a distinct irony that unencrypted SMS is more
| secure than online messengers, because there are legal
| protections.
| nxor wrote:
| Funding police outweighs the benefit organized crime may
| get from communicating securely ?
| dijit wrote:
| Very much so.
| jcynix wrote:
| So you think that if normal people aren't allowed to use
| encryption that would hinder organized crime to use
| encryption? :-0
| nxor wrote:
| Are you European? I don't understand that use of hinder.
| You mean prevent from using? Then no, I don't think
| preventing normal people from using encryption will
| prevent criminals from using encryption, and didn't mean
| to imply that
|
| I'm not referring to hinder meaning prevent, I'm
| referring to how "hinder someone to use" is not
| grammatical. https://www.merriam-
| webster.com/sentences/hinder
| jcynix wrote:
| To "hinder" means to make it more difficult to use
| something, or "to restrict" or "to prevent" someone from
| using it.
|
| https://www.merriam-webster.com/thesaurus/hinder
| detaro wrote:
| Freedoms tend to also benefit criminals, yes. That's kind
| of unavoidable.
| nxor wrote:
| Then crime will increase
| fsflover wrote:
| See also:
| https://support.torproject.org/abuse/#abuse_what-about-
| crimi...
| bigstrat2003 wrote:
| > If everyone has secure chat, then won't that benefit
| criminal organizations?
|
| Probably. But criminal organizations also benefit from
| having electricity, or cars, or a million other things
| that we all would be much worse off if we didn't have
| them. Just because something benefits criminal
| organizations as a side effect is not really a reason to
| not do it for the benefit of ordinary citizens.
| nxor wrote:
| My point wasn't that we should or shouldn't have it. I
| just get the impression that the same people calling for
| privacy will be highly outraged the next time, for
| example, an Austin Wolf (gay porn 'star' who used
| Telegram to share thousands of files showing abuse of
| children) situation arises, or it's inevitably revealed
| that religious sect xyz coordinated over it. Europeans
| trash talk Telegram (and that is fine), but somehow
| Matrix is different? How?
| bigstrat2003 wrote:
| Oh I don't think it's different at all in that respect. I
| think that many people are very ignorant about the
| inherent double-edged sword that is freedom, and think
| that it's possible to deny it to only bad people. On top
| of that, many people don't particularly value private
| communications, considering it to be a theoretical issue
| that doesn't affect them. So yeah there will certainly be
| outrage in cases like you mentioned.
| jeroenhd wrote:
| Matrix, the organisation, takes care of the open source
| side of things.
|
| BwMessenger is a partnership with "ELEMENT SOFTWARE SARL"
| (according to https://messenger.bwi.de/datenschutz), the
| French entity of the commercial side of the people
| originally behind the open Matrix ecosystem
| (https://element.io/legal/company-information). I'm not
| sure why the French entity is doing business with the
| Germans as Element also has a German entity, but either way
| the American side is not the one doing the work.
|
| For the American entity, a lot (most?) of the work that's
| not from unrelated open source contributors seems to be
| coming in from either EU countries or the UK.
| nxor wrote:
| Thank you, it looks like my assumption was wrong
| Arathorn wrote:
| Matrix isn't US at all; it's a UK Non Profit.
|
| Element is also UK headquartered, albeit with
| French/German/US subsidiaries when selling to those
| respective governments. BWI buy via France because when
| we started working with them we didn't have a German
| legal entity yet.
| nxor wrote:
| It appears to have been started by Americans:
| https://en.wikipedia.org/wiki/Matrix_(protocol),
| https://en.wikipedia.org/wiki/Amdocs
|
| Who perhaps chose the UK in an effort to distance
| themselves from the US
|
| As I said, I see now my assumption was wrong
| jazzyjackson wrote:
| Signal and any kind of Slack SaaS: US infrastructure, US
| law around data governance. Matrix (and Zulip, for that
| matter, and mattermost too) encourage self-hosting on your
| own infrastructure, or at least in-country, even if the
| upstream security patches are coming from US developers.
| nxor wrote:
| Thank you, that helps me understand it better
|
| Oh, and as everyone has said. Only some of the developers
| are from the US
| JadedBlueEyes wrote:
| the Matrix foundation is a UK company.
| jonesjohnson wrote:
| so what? all the specification and all the code is open.
| fsflover wrote:
| > Matrix allows for unencrypted messages so it's inherently
| less encrypted than Signal.
|
| But that logic, Matrix is less encrypted than Whatsapp, too,
| which is a crazy thing to say.
|
| > The federation capability also means messages leak
| metadata.
|
| It's the opposite: The centralized architecture means that
| there is a single target server to attack for the metadata.
| With decentralization, you can't easily scale up your attack
| to all users.
| tptacek wrote:
| It's not a crazy thing to say. It's a complicated question.
| the_gipsy wrote:
| Signal requires a phone number, and AFAIK the PIN to prevent
| carrier-level attacks (well known) is not enabled by default.
| basilikum wrote:
| Signal is a cryptographically well thought out protocol that
| reduces meta data.
|
| Matrix does not even encrypt emoji reactions.
| fsflover wrote:
| Signal is centralized, so it becomes a huge target of all kinds
| of hackers and three-letter agencies. This alone is sufficient
| for me to never touch it. And then, there is this:
|
| https://news.ycombinator.com/item?id=42788647
|
| https://news.ycombinator.com/item?id=39445976
| JuniperMesos wrote:
| If the open source client encryption is good enough, it
| shouldn't matter if the CIA itself is openly running the
| centralized portion of Signal.
| fsflover wrote:
| I'm not an expert, but it doesn't look so simple:
|
| https://news.ycombinator.com/item?id=39421128
|
| https://news.ycombinator.com/item?id=39445976
| upofadown wrote:
| The vast majority of people using "end to end encrypted"
| messaging systems fail to verify the identity of their
| contacts. So those running the servers can fairly trivially
| MITM the messages. So in practice it does matter who
| controls the servers.
| tptacek wrote:
| I don't think this is a super useful comparison, because the
| two services have wildly different threat models. I think of
| Matrix as a secure replacement for Discord. Signal is about
| small group messaging. It's literally a replacement for the
| built-in texting app on your phone, and that's its intended
| userbase. Signal is what you use when you need to know, to the
| limit of best practices available to ordinary users, that your
| messages will be as private as they can be made to be. That's a
| goal that isn't compatible with many of the affordances people
| want for project discussion platforms and things like that.
|
| If you pit Signal against Matrix and make the competition
| purely about security, Signal will win for the foreseeable
| future. But I think it makes much more sense to think about
| different sets of tradeoffs being more appropriate for
| different kinds of problems.
| Scene_Cast2 wrote:
| I noticed that they renamed the Element mobile app to Element
| Classic. Has Element X reached feature parity and stability yet?
| For how long will Classic be maintained?
| _def wrote:
| As of lately, Spaces are now supported in Element X which
| possibly brings it to feature parity (at least I wouldn't know
| what's missing, and I've been using Element X now for some
| months because of these plans)
| noident wrote:
| > The outgoing Element mobile app ('classic Element') will
| remain available in the app stores until at least the end of
| 2025, to ensure a smooth transition
|
| https://element.io/blog/mas-migration-unleashes-element-x-on...
|
| I can't find any other communication from Element Creations
| other than that.
|
| The renaming to Element Classic doesn't bode well considering
| that Element X still doesn't support a vast number of home
| servers and a number of Synapse authn/authz features.
|
| If they remove it from the app store, my advice for my users is
| going to be to switch to fluffychat, and I'll eventually
| migrate away from Synapse to some flavor of Conduit.
| Arathorn wrote:
| Element X now has initial support for threads & spaces (as of
| last week), which were the main things missing from full parity
| with Element Classic.
| JuniperMesos wrote:
| Good to know! These are very important features and not
| having them really gets in the way of switching off of
| classic. I am worried about "intial" support - what is going
| to break with threads and spaces that I try to join with thr
| new Element X?
| conor- wrote:
| Sorry to hijack this thread to ask - but what is the current
| state of sliding sync? Does it still require a separate proxy
| service to enable sliding sync if you're self-hosting a
| homeserver; or is it upstreamed into synapse? Also is there a
| list of clients that are sliding sync aware?
| Arathorn wrote:
| upstreamed into Synapse as of Sept 2024, and the proxy was
| sunset in Nov 2024:
| https://matrix.org/blog/2024/11/14/moving-to-native-
| sliding-...
|
| Not that many clients have actually adopted it though,
| because the MSC is still not 100% finalised - it's
| currently entering the final review stages at last now over
| at https://github.com/matrix-org/matrix-spec-
| proposals/pull/418.... Right now Element X uses it
| (exclusively), and Element Web has experimental support for
| it; I'm not sure if any others actually use it yet.
| basilikum wrote:
| Absolutely not. It doesn't have commands and probably a lot
| more.
|
| It also does not have parity by having deliberate breakage like
| calls.
|
| It's a sluggish buggy mess, so I guess you could say it has
| parity in that aspect.
| yaky wrote:
| After installing and configuring coturn, and then finding out
| that ElementX requires Element Call instead feels like a
| "fuck you" from developers.
| Arathorn wrote:
| what guide were you following that told you to install
| coturn for Element X? It shouldn't be /that/ surprising
| that Element X's group-capable calling requires a group
| call server, and in general most people seem happy to not
| have to worry about coturn given the server acts as a
| relay.
| yaky wrote:
| The instructions are from Synapse docs:
|
| https://element-
| hq.github.io/synapse/latest/setup/turn/cotur...
|
| Element (not ElementX), the official/preferred app, works
| with coturn for 1-on-1 calls. But ElementX does not. IMO
| it is surprising to break 1-on-1 call functionality.
| Arathorn wrote:
| In Matrix 2.0, all calls are group capable (much like
| Matrix itself doesn't specialcase DMs - they are just
| rooms with 2 people). So yes, no coturn is needed.
|
| We haven't got as far as interop between legacy Matrix
| 1:1 calling and Matrix 2.0 style MatrixRTC though, which
| I can see being annoying - but overall the admin burden
| should be simpler than running a coturn.
|
| We'll update the synapse docs to explain that coturn
| isn't needed for MatrixRTC calls.
| entrepy123 wrote:
| > It's [Element X is]...sluggish...
|
| I regret to concur. On an iPhone PRO MAX with iOS
| 18.7-latest, my stopwatch says: - Element X
| loads to list All Chats in 3 seconds. - Element Classic
| loads to list All Chats in <1 second.
|
| And Element X is supposed to be the "fast one", due to Rust
| SDK, etc. etc.
|
| I'm giving Element X etc. the benefit of the doubt and will
| see them through.
|
| But there NEEDS TO BE a user-advocate or project-manager just
| wailing on usability internally at Element. If you need such
| a person, find someone, and if you can't find anyone, hit me
| up, but I would think someone should be filling this role
| already.
|
| In addition to bundling and network effects, one magic thing
| that helped grease the skids for some apps like AOL Instant
| Messenger or Facebook Messenger (in its glory days) or
| WhatsApp/Discord/Telegram or whatever gain very wide adoption
| was their relatively seamless user experience.
|
| As much as the Parent sounds like complaining, I think it's
| complaining in good faith. We want Matrix to succeed.
| Arathorn wrote:
| Hm. Something sounds wrong here, then. On my iPhone 12 Pro
| Max on iOS 26, my account (~5000 rooms) opens in about 2s
| in Element X iOS. On the classic app it's about 10s (ie
| unusable).
|
| Roughly how many rooms are you in? and what server is this
| on (it could be a serverside problem)? And what precise
| build of the app?
| entrepy123 wrote:
| > how many rooms are you in?
|
| 8 on both (same account) > and what
| server is this on (it could be a serverside problem)?
|
| It's a hosted SaaS personal homeserver. So yes, quite
| possibly a server-admin issue. I've just put in a ticket
| to find out.
|
| EDIT: Synapse 1.139.0 > And what precise
| build of the app?
|
| Element X Version 25.10.0 (190)
|
| EDIT: After updating to Element X Version 25.10.1 (192)
| [latest Update from App Store], about 2 seconds is
| observed -- still slower than Classic, but a little
| better than before. I will still finish following up
| regarding Server issues/info with server admins;
| hopefully that fixes it.
|
| Thanks a ton for all you do! Good to know it's _not_ the
| expectation.
| Arathorn wrote:
| This is really surprising. Can you do a clean launch (ie
| kill the app and relaunch it) and then submit a bug
| report from both apps and let me know what mxid to look
| for? (DM to @matthew:matrix.org if needed). The logs will
| say where the time difference is coming from. EX should
| _always_ be way faster than classic Element.
| entrepy123 wrote:
| Sure, both are uploaded, I'll DM you what to look for
| Arathorn wrote:
| thanks - both received; we'll dig into it. thanks!
| entrepy123 wrote:
| > opens in about 2s in Element X iOS
|
| I think we're getting closer.
|
| Your "good experience" on Element X iOS matches my "bad
| experience" on Element X iOS.
|
| See, with my Server and Chats, Classic is actually very
| snappy: - Element X: ~1.5 seconds avg
| (rounds to 2 sec if using a non-decimal stopwatch, but
| more like 1.5 when measured more precisely) -
| Element Classic: ~0.6 second avg (actually slightly
| faster visually, this includes my response time to stop
| the timer, probably more like just around/under 0.5 sec)
|
| Anyway, Classic is very fast for me to open. I like it a
| lot. It feels almost instant.
|
| But X loads in 2-3 times the time. I sit there waiting
| for content to load, even if it's just for a second.
|
| Is this the best Issue to watch?:
| https://github.com/element-hq/element-x-ios/issues/4102
|
| Because I really hope speed does not regress for people
| already with very fast load times in Classic, when X
| becomes the only flagship App in the App Store.
| entrepy123 wrote:
| To be complete, for anyone following along: the above
| hypothesis was allegedly incorrect. 2 seconds is not
| supposed to be normal for so few chats. Element X is
| supposedly normally nearly instant to load & list chats
| for such a small number of chats.
|
| So, I'll try to come back here and comment if I get it
| resolved.
| neiljohnson wrote:
| You can learn more about Element X migration plans from last
| weekend's Matrix conference here
| https://youtu.be/_cahXxr8d-4?si=0b9qyjiEYVpMczDy&t=442
| the__alchemist wrote:
| User report from 2025: Both the application and web UI are still
| buggy and slow. This is not acceptable in an application this
| simple in nature, that has been around for so long.
| Arathorn wrote:
| which app are you talking about? as per the conference keynote,
| there are loads of different ones now, written in different
| stacks without any overlapping implementations.
|
| If you're talking about the old Element Classic mobile app,
| then yes, it's now been replaced by Element X (which now has
| spaces & threads support, and so pretty much has parity with
| the old app), and it is super fast, and not buggy.
| abeindoria wrote:
| It's not buggy? You should try going to the app store(s) and
| looking at reviews.
| Arathorn wrote:
| again, which app are you talking about? it's like saying
| "the web is buggy" but not saying what browser you're
| using. Looking at the App Store reviews for Element X at
| https://apps.apple.com/us/app/element-x-secure-chat-
| call/id1..., there are no complaints about bugs at all
| (only missing functionality, which has since been added)?
| abeindoria wrote:
| Brother, look at reviews for element x for android on
| play store. Come on, you're being intentionally obtuse.
| the__alchemist wrote:
| Hi! I'm referring to the one on element.io/download marked
| "Desktop" I haven't tried element.x. Seems to be phone only?
| Arathorn wrote:
| Right, thanks for clarifying. Yes, the desktop app isn't as
| fast as it should be. On mobile we fixed this with Element
| X; on desktop we're in the middle of the transition still.
| The conf talk on Element X Web is pretty good at explaining
| where it's at: https://youtu.be/z0ULOptq2vk?t=240
|
| Edit: also, on macOS on Apple Silicon, you can use Element
| X on macOS as a desktop app, and it works impressively
| well.
| entrepy123 wrote:
| For Desktop, use nheko as the client app. It's lightning
| fast.
| catgirlinspace wrote:
| Latest Element X Testflight and nightly both crash for me
| very consistently when navigating back from two or more
| levels deep (like from Chats > room > room info and then
| going back). iOS 26.1 beta (23B5064e). I've been blaming it
| on iOS for now since I can't go back to not running a beta
| yet :( Also seems like the notification badge is always =
| real notifications + 1 which i've read happens with Synapse
| or something but I've never found a way to fix it.
|
| Also seems like spoiler messages in Element X appear as just
| an empty chat bubble that i've been meaning to report. And
| why does sending spoilers on Element require using /spoiler
| when discord and telegram use `||spoilered text||`?
|
| I really want to love Matrix. I've been using it with my
| girlfriend (on a self hosted Synapse server for us) who
| barely tolerates it, some other friends who range from also
| tolerating it to hating it (and having decryption errors a
| lot with a friend who has several clients they switch
| between, mostly whenever I send a message from another client
| like when going from element to nheko). I bridge Telegram,
| Signal, and IRC to matrix (and probably will add more soon).
| I'm not sure why I care so much about this chat protocol, but
| I do for some reason and I really want to see it work.
| Arathorn wrote:
| Unfortunately that really does sound like an iOS beta
| problem - iOS betas are infamously unstable, and
| effectively used by Apple to hunt crashes that they've
| introduced when existing apps run.
|
| The notification badge issue is this mess:
| https://github.com/element-hq/element-x-ios/issues/3151 and
| is almost solved (but not deployed yet).
|
| Spoilers is https://github.com/element-hq/element-x-
| ios/issues/2839 but isn't really on our radar - please can
| you upvote / comment on it.
|
| Thanks for keeping the faith :)
| catgirlinspace wrote:
| Hoping there's a new iOS version soon then so I can get
| off the beta, has been annoying dealing with crashes but
| at least element x launches really fast.
|
| Really glad to hear that notification badges are almost
| fixed! I left an upvote on the spoilers issue but don't
| really have anything to add other than it's annoying to
| not have a way of even seeing the contents.
| jeroenhd wrote:
| The only desktop messenger with smooth performance I'v used was
| Telegram. Signal, WhatsApp, Element, and all the other Electron
| applications all introduce hard-to-pinpoint latency somewhere.
| Unfortunately, Telegram is... Telegram.
|
| For XMPP/Matrix/etc. there are plenty of (more) native
| alternatives but they're not as feature complete as Telegram or
| their Electron counterparts, unfortunately.
|
| My lack of C++ and Qt experience has still managed to keep my
| urge to rip out the Telegram protocol and replace it with
| something else. Maybe I'll try throwing AI at the problem and
| release a slop POC. Secretly, I'm hoping someone else will do
| the hard work for me...
|
| The mobile apps for all are fine, though. Electron hasn't hit
| mobile phones just yet.
| jazzyjackson wrote:
| I use thunderbird for email and they now let you connect to
| matrix, irc, xmpp, and whatever Odnoklassniki is. It's quite
| barebones however, like it looks like people are just adding
| lines to a google doc, barely any interface at all. Really a
| stylesheet would go along way, looks like userChrome.css
| works, so maybe I'll mess with that.
| JadedBlueEyes wrote:
| 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.
| solarkraft wrote:
| Aurora is a big deal! I've been waiting for the Rust SDK to come
| to the web.
|
| I'm not fully through the talk yet, but it looks like they're
| first modernizing the old application and planning to eventually
| switch base to Aurora, which seems sensible!
|
| Either way, Rust SDK on the web, finally! This will hopefully
| make it easier to write other Matrix clients, since the JS SDK is
| pretty undocumented (and outdated).
| Arathorn wrote:
| So Aurora (https://github.com/element-hq/aurora) is a proof-of-
| concept we put together of rust-sdk on Web, using the new MVVM
| components from Element Web. However, the plan is likely not to
| actually switch base to Aurora, but instead migrate SDK within
| the existing app codebase eventually. (We might end up using
| Aurora for other purposes though). Either way, the ground work
| is the same: to split up the current app into MVVM components
| which can run on either js-sdk or rust-sdk.
| A4ET8a8uTh0_v2 wrote:
| So honest question as I am now looking into matrix as a solution
| to combine multiple messaging channels. Does it play well with
| signal/telegram these days or do I need to constantly update
| various connectors and hope for the best?
| Arathorn wrote:
| Your best bet for that is almost certainly beeper.com, which
| isn't FOSS, but specialises in combining messaging channels and
| is built on Matrix. Otherwise, you do have to run your own
| bridges and hope for the best, and moreover the bridges re-
| encrypt Signal and so miss the point of its end-to-end
| encryption. On the Element side, we're not focusing on bridging
| currently.
| yaky wrote:
| I've been hosting Matrix Synapse and mautrix-WhatsApp bridge
| for many years. Due to WhatsApp changes, bridge has to be
| updated periodically (about 1-2 times a year IIRC), but it has
| worked pretty reliably otherwise.
| JadedBlueEyes wrote:
| 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.
| osamagirl69 wrote:
| I have been self hosting a matrix setup for a few years now,
| using the spantaleev ansible playbook. It does require updates
| roughly once a year to keep up with changes of the 3rd party
| chat APIs. Generally that involves logging into the server and
| running 'just update' followed by 'just install-all', but
| occasionally there are changes that need updates to the
| playbook as described in the release notes. In the worst case,
| if one of your bridges does go down you can always fall back to
| the vendor client for that protocol until you get the bridge
| updated.
|
| Overall it has been absolutely rock solid, and the new element
| x app has been night and day compared to the old one.
|
| Feels a lot like the days of using Pidgin chat, but since the
| bridges run on the server you only need to authenticate once
| instead of going through the process for every device.
| TheCycoONE wrote:
| I apologize if it was mentioned anywhere but has there been any
| retrospectives on the August security update and v12 room roll
| out.
|
| The v12 room upgrade in particular seems to be difficult, and
| still not supported by many of the bridges. Is there a plan to
| force upgrade all rooms on matrix.org at some point?
| Arathorn wrote:
| There was an internal retro, but nothing external - from our
| perspective the upgrade was overall successful. What bridges
| are you thinking of which don't support v12?
|
| We will start force-upgrading foundation-managed matrix.org
| rooms sooner or later; the only reason we haven't yet is trust
| & safety manpower rather than there being a problem with v12.
| BrenBarn wrote:
| It's good to see Matrix getting more adoption. I still feel a bit
| uneasy when so much of it is focused on big institutional
| deployments, but hopefully that can trickle down to a better
| experience for average users.
| Arathorn wrote:
| the rationale is to get element (and the foundation)
| sustainable by funding from big institutions. meanwhile the
| competition is typically whatsapp & signal, so the hope is that
| whatever works for institutions will also work for average
| users.
___________________________________________________________________
(page generated 2025-10-20 23:02 UTC)