[HN Gopher] Verifying your Matrix devices is becoming mandatory
___________________________________________________________________
Verifying your Matrix devices is becoming mandatory
Author : LorenDB
Score : 190 points
Date : 2025-11-20 00:22 UTC (22 hours ago)
(HTM) web link (element.io)
(TXT) w3m dump (element.io)
| olivia-banks wrote:
| What exactly does this entail? I'm willing to be charitable in
| assuming that their use of "verify" isn't the modern usage of
| "give us your ID!" but I'm not enmeshed enough in the ecosystem
| anymore to know.
| ranger_danger wrote:
| My understanding is that there's two different types of
| verification.
|
| Self-verification means that any new secondary devices you log
| into your account with will need to be verified by an existing
| login by way of an automatic popup that asks if you trust the
| device. It used to just be a Yes/No button but I think now
| they've added QR codes and/or emoji matching.
|
| The other kind is verification between two different people,
| like when starting a direct message conversation, you might get
| the same emoji matching window to verify each other.
| xethos wrote:
| Respectfully, not even close. Verification is when I sign in
| from a new device, I use an existing device or second
| passphrase (either-or) to ensure that yes, it is me on both
| devices. I never have to reveal my ID, name, phone number, or
| email address to anyone. Not to Element, the Matrix Foundation,
| or the person running my home server where all my [encrypted]
| messages live.
| josephcsible wrote:
| Yeah, IMO "verify" was a poor choice of wording for what this
| is. It has nothing to do with remote attestation or any other
| form of Treacherous Computing, and it has nothing to do with
| your real-life identity. It's just "go on your old device and
| confirm that the new device is really yours."
| goku12 wrote:
| If you don't mind reading an essay, here is mine from the same
| discussion: https://news.ycombinator.com/item?id=45989744
| tripdout wrote:
| What _is_ verification? What does it involve doing? A lot of
| information on why it 's useful, but how is it implemented? I
| hope it's not something like the Play Integrity API, but with no
| information to go on, I can't say either way.
| olivia-banks wrote:
| Yeah, I was wondering this as well. At the very least, this
| appears to be an Element requirement that was just enabled by a
| Matrix protocol update, so moving would be possible, but afaik
| Element is extremely popular as far as Matrix goes.
| ThePinion wrote:
| In the current state, it's basically just a self verification.
| When you use a new device it shows a series of emoji on each
| device and asks you if they're the same, then the device is
| verified.
| mroche wrote:
| You can also use a generated security key to verify as a type
| of second-factor.
| totetsu wrote:
| https://element.io/en/help#encryption-device-verification
|
| > After Alice logs in on a new device, she uses her
| cryptographic identity to demonstrate to Bob that the new
| device genuinely belongs to her, rather than being added by
| someone else with access to her account. She can do this either
| by entering her recovery key (which gives the new device
| immediate access to her cryptographic identity ), or by
| carrying out an interactive verification from an existing
| verified device.
| navigate8310 wrote:
| So is this like the Signal PIN which is required when
| installing on a new device? If you forget, the cryptography
| changes and old contacts are warned that signatures are
| rotated, right?
| kevincox wrote:
| Yes, the purpose is the same but the UX is a bit different.
| Lerc wrote:
| Quite. I have yet to manage a verification between
| clients.
|
| I have had all variations of clients ignoring requests,
| reporting requests only for the requesting client to
| ignore the response. Both ends quitting declaring that
| the other end cancelled, asking for the other end to
| input a code while the other end shows no interface for
| doing so.
|
| It marked the end of me using Matrix as a platform. I'd
| go back to the old IRC channels if there were anyone
| still there.
| tcfhgj wrote:
| I have never failed at that. Worst case I type my
| recovery key and done.
|
| I still have my encrypted messages available from 2020
| immibis wrote:
| People still use IRC
| rebolek wrote:
| If by bit different you mean absolute nightmare then yes
| tcfhgj wrote:
| imho it's the best out there
|
| - no unnecessary coupling to a phone client
|
| - no coupling to any other client - I can just put my
| recovery key in and be verified without having to deal
| with other apps.
| octoberfranklin wrote:
| More like the safety number / QR code.
|
| The numerical Signal PINs are basically just for when you
| bootstrap your Signal identity from a telephone number.
| jojobas wrote:
| Except Signal PIN appears to be trivial to bruteforce for
| Signal itself, unlike this properly secure verification.
| foresto wrote:
| In this case, it's what you do when signing in from a new
| device (or browser) to attest that it's yours. It avoids
| warnings to you and your contacts that a device has gained
| access to your account without your approval.
|
| It involves doing one of these things:
|
| - Comparing a short sequence of emoji on each device and
| confirming that they match.
|
| - Using one device to scan a QR code displayed by the other.
|
| - Entering a recovery key (a line of text) that you were given
| when you first set up the account.
|
| Pretty quick and easy in most cases, although some clients can
| be glitchy in this area and require trying again.
|
| (Gripe: The recovery key approach was unfortunately made
| painful and error-prone in recent Element releases, by
| disabling the option to choose a passphrase instead, but most
| people can simply use one of the other two approaches.)
| g-b-r wrote:
| > Pretty quick and easy in most cases
|
| The experiences reported here seem to say otherwise...
|
| As others, anyhow, I haven't tried again recently
|
| > (Gripe: The recovery key approach was unfortunately made
| painful and error-prone in recent Element releases, by
| disabling the option to choose a passphrase instead, but most
| people can simply use one of the other two approaches.)
|
| I last tried Element about six months ago, but for years
| using the recovery key was either impossible or close to it,
| and mostly just for idiotic UI mistakes that were never
| corrected (something like you had to enter the key where they
| wanted the passphrase or the opposite).
|
| To my recollection the version from six months ago worked
| better in that regard, but it was still asking to enter the
| passphrase where you actually had to enter the recovery key.
| foresto wrote:
| I think current Element versions accept either a recovery
| key or recovery passphrase in the same input field, so
| there's no getting it wrong. Since you seem focused on UI,
| it's worth noting that Element X (their beta mobile app)
| has a greatly simplified interface; their team clearly has
| been working to make it easier.
|
| Also, other clients exist.
|
| For whatever it's worth, I've been using Matrix for about
| five years, including some of its roughest times. I seldom
| see errors these days, but I can understand how folks who
| were frustrated with earlier iterations would still be
| soured to it. Such is the nature of an ambitious work in
| progress, I suppose.
|
| I use it because there is nothing else with the combination
| of features that are most important to me, and because
| (despite my gripes) I can see slow and steady improvement.
| I think it's moving in the right direction overall. I could
| picture introducing family members to it once Matrix 2.0 is
| released and the implementations shake out any early
| problems.
| BrenBarn wrote:
| > I can see slow and steady improvement.
|
| That is true, but what weakens my confidence is that the
| Element/Matrix team often doesn't present it that way. So
| much communication from them is about how it's amazing
| and great and the best messaging app in the world. If
| they presented it more like a typical slow-growth open
| source app I think they'd garner more goodwill. By
| setting high expectations they increase the likelihood of
| disappointment.
| g-b-r wrote:
| I tried the current Element and Element X.
|
| In short, the passphrase works with both and the recovery
| key with neither, specifically:
|
| Element classic has two separate fields; if I input the
| recovery key (in the correct field), I get told "Backup
| could not be decrypted with this PASSPHRASE: please
| verify that you entered the correct recovery passphrase."
|
| That's how it was the last time I used it, and if I'm not
| mistaken it's been for years.
|
| Element X has a single field, that supposedly takes both
| passphrases and recovery keys, but if I enter the
| recovery key I'm directed to a "Verify with another
| verified device" screen, even if I had logged out from
| all other sessions.
|
| Funnily, by the way, it seems that with Element X you
| can't do _anything_ if you don 't manage to get verified,
| there just doesn't seem to be a way to skip it.
|
| Furthermore, after signing out from Element X I'm unable
| to even just logging back in, I get an error ("Sorry, an
| error occurred") after I enter the credentials; even
| after clearing all the app's storage. Very, very weird.
|
| The new login-via-browser is pretty problematical, by the
| way, I could only make it work with Chrome.
| tcfhgj wrote:
| > Element X has a single field, that supposedly takes
| both passphrases and recovery keys, but if I enter the
| recovery key I'm directed to a "Verify with another
| verified device" screen, even if I had logged out from
| all other sessions.
|
| I have just tried this on Android.
|
| I am directed to
|
| 1) "Device verified - Now you can read or send messages
| securely, and ... - [Continue]"
|
| 2) "Help improve Element X ... [OK] [Not now]"
|
| 3) list of chats
|
| Element X Android fyi. No problems logging in using
| Firefox.
| SilverElfin wrote:
| Maybe I'm missing something but why does this service need
| this process while Discord or whatever don't?
| jorams wrote:
| Discord does not do any sort of end-to-end encryption. All
| messages are fully readable and writable by Discord.
| Discord decides whether you are who you say you are, and
| all clients trust whatever Discord says to be trustworthy.
| bigyabai wrote:
| That's easy, Discord is spyware.
| tcfhgj wrote:
| > The recovery key approach was unfortunately made painful
| and error-prone in recent Element releases, by disabling the
| option to choose a passphrase instead, but most people can
| simply use one of the other two approaches.
|
| honestly it's the best thing ever they have done:
|
| - I have heard of someone who failed to use Matrix, because
| he got frustrated of having not a secure enough passphrase
|
| - people don't choose secure passphrases
|
| - it provides options making things more complex (especially
| when guiding others)
|
| - you know you won't memorize it, so you are more likely to
| put it down
| foresto wrote:
| 1. Generating a random key by default (but still allowing
| advanced users to prefer a passphrase) would solve your
| "secure enough" problem.
|
| 2. Better yet, a "secure enough" passphrase could be
| generated by default, a la Correct Horse Battery Staple. A
| user wouldn't be forced to choose one.
|
| 3. When adding an option, interface complexity can be
| avoided by simply not showing it by default, or by placing
| it off to the side in collapsed state where it doesn't draw
| attention.
|
| 4. If you're worried about people writing down a
| passphrase, you should be even more worried about a string
| of 50 random characters.
|
| That last one is important. Nobody is going to memorize a
| random key, which means everyone has to write it to a file
| (or painstakingly write it on paper) for long term storage.
| When verifying remote devices, they also have to get the
| key to the other devices, so they are likely to use
| copy/paste, which will put it on at least two devices'
| clipboards, where it will be available for harvesting by
| nosy apps/websites or accidental pasting to random ones.
| They also have to figure out a way to transport the key
| from one device's clipboard to another, which might be
| email or SMS or some other insecure channel that they're
| accustomed to using. Or in the unlikely event that they
| choose paper, they have to painstakingly transcribe it
| again at the other end.
|
| In other words, forcing the use of a random key does not
| increase security vs. a well-implemented passphrase system,
| but instead pushes responsibility for security out of the
| software and into the hands of people who aren't trained in
| it. Inviting more big mistakes.
|
| A passphrase would avoid most of those exposure risks by
| not having to be written down or copy/pasted or sent
| through insecure channels. And with the right UI, it
| wouldn't be more complex to use or less secure.
|
| Fortunately, Matrix supports passphrase-derived keys at the
| protocol level, so client developers who understand how to
| implement them well for humans can still do so. I hope
| Element's product managers will come around eventually.
| solarkraft wrote:
| (I think) It transfers (access to) your keys for end-to-end
| encryption between devices.
| Aachen wrote:
| I was afraid of that as well given the wording but, no, it's
| nothing to do with third parties at all. Just when you log into
| a new device, you confirm it on your old device so it knows it
| can transfer encryption keys for old messages to the new device
|
| This has been in Element/Matrix since forever and I found it
| the easiest verification mechanism of all the encrypted
| messengers I've tried. I'm not surprised they're making this
| part of the standard process, but the wording in 2025 is...
| unfortunate. Or perhaps that adjective should be applied to the
| rest of the world since it's not the Matrix Foundation which
| changed. For the reader to decide ^^
| joecool1029 wrote:
| I'm a server admin and I still couldn't tell you why when I
| sign new endpoints in and verify for cross-signing it still
| also asks me for a recovery key.
|
| For encrypted search on desktop it has to fetch batches of
| messages and this is configurable in settings. It just had a
| number? what is that? how large the batch is, how many ms? no
| clue! good thing we can't do encrypted search on mobile/web.
| josephcsible wrote:
| Thankfully, no, it's not anything evil like Play Integrity is.
| The simple explanation is that the first time you log in to an
| existing account from a new device, you need to go on one of
| your old devices and confirm that the new one is yours.
| DrewADesign wrote:
| In my case, it transferred my willingness to self-host a chat
| server to something else.
| bfkwlfkjf wrote:
| Is this the ritual of getting together with a person and checking
| that their fingerprint match what you see on the app?
|
| If this is that case what will happen is that people will start
| verifying everyone (because they might want to text to strangers
| that they can't bother verifying because the stakes are so low)
| and so verification will lose all meaning.
| ranger_danger wrote:
| Isn't this how TLS itself already works? "trust on first use"?
| treyd wrote:
| With PKI you're trusting a certificate chain up to a CA you
| already trust, by way of your OS or browser vendor.
|
| A domain can layer on HSTS to that, which directs clients to
| additionally refuse to trust a new cert for a domain until
| the one you currently trust has expired.
| scheub wrote:
| That's not what HSTS does. It asks the client to remember
| that you want to only use TLS for that domain and refuse to
| use unencrypted HTTP in the future.
| pavon wrote:
| Not in current practice. That is why you have to get a
| certificate from a trusted CA. If your CA isn't in the
| browser's cert database they will reject the connection even
| on the first time. If browsers allowed TOFU we would still be
| able to use self-issued certificates, without manually
| distributing certs to anyone that uses your service.
|
| SSH is an example of TOFU.
| majorchord wrote:
| > we would still be able to use self-issued certificates
|
| You still can... it just displays a warning message on
| first use, as does ssh.
| syntheticnature wrote:
| It is not; I know we don't read articles here, but...
| lousken wrote:
| "The authenticity of this encrypted message cant be guaranteed on
| this device" both sides verified, but this still randomly pops
| up, what happens then? will i lose those messages in the future?
| Arathorn wrote:
| No, it's just a warning that your client can't prove that the
| message was really sent by that sender. These will eventually
| go away once https://github.com/matrix-org/matrix-spec-
| proposals/pull/404... lands.
| jerrythegerbil wrote:
| As someone whose devices randomly became unverified just a few
| months ago, signed out, and then tried to use my recovery keys: I
| was authenticated, but unverified.
|
| When attempting to verify iOS, Desktop linux didn't work. When
| attempting to verify Desktop Linux, Desktop Windows didn't work.
| When verifying Android, iOS didn't work. Every verified official
| client for every platform was verified, tried a different
| verification method than expected, and failed.
|
| All of this to say, this isn't the first time this has happened
| to myself and others. Forcing verification is otherwise known as
| unexpected "offboarding". If some verification methods have
| problems, publish a blog about their deprecation instead.
|
| I love element, but this can't be done without prior work to
| address.
| tcfhgj wrote:
| are you using your own server?
|
| I have never heard of such issue and not experienced it despite
| intensive use, so it's a bit strange that you and people you
| know have experienced this repeatedly.
| Aurornis wrote:
| I went through the same frustration recently. I only
| occasionally use it, but every second or third time I have to
| open it up to talk in some channel I lose 30 minutes chasing my
| tail trying to work through the latest set of problems.
|
| I like the idea, but the effort to reward ratio for using the
| product has not been good. It has caused visible churn and
| attrition in the few channels I've tried to participate in and
| it's become a problem for the OSS projects I'm part of that try
| to use it for their communication. Of course, there are some
| people who like it that way and think making communication
| spaces difficult to access is a bonus, but that's another
| topic.
| Groxx wrote:
| I've had _constant_ problems with the verification ever since
| it was introduced. As far as I can tell it hasn 't improved at
| all. Sometimes it works, sometimes it repeatedly kicks me out
| moments after succeeding, and it's still prompting me to verify
| some old devices that I removed Element from _years ago_ and I
| can 't find any way to make the constant pop-ups go away (when
| they feel like appearing again - sometimes they go away for a
| couple months).
|
| All this will do is make me lose EVERY profile.
| hedora wrote:
| I don't use Matrix, but if it's E2EE, then how is it possible in
| the current design for an unverified device to even exist?
|
| It has the keys, or it doesn't, right?
| kevincox wrote:
| Matrix has E2EE support and many clients are pushing it as the
| default. But it also supports rooms that are only encrypted in
| transit.
| prophesi wrote:
| That's correct, but E2EE also allows for unverified
| devices[0]. Key distribution and device verification are
| separate issues, and the former doesn't enforce the latter
| until April 2026 as they've announced in the HN article.
|
| [0] https://matrix.org/docs/matrix-concepts/end-to-end-
| encryptio...
| bigstrat2003 wrote:
| You don't have to use E2EE if you don't want to. I personally
| don't because I don't care about it, and it adds extra
| difficulties to the experience.
| throwaway290 wrote:
| If you don't need e2ee, are there features that make matrix
| better than xmpp?
| jeroenhd wrote:
| Lots of open source projects have matrix servers and not
| XMPP servers. Some bridges don't have XMPP equivalents (and
| some bridges don't have Matrix equivalents either).
|
| XMPP also does E2EE of course, though I've found it to be a
| worse experience on most clients compared to Matrix.
| toastal wrote:
| Both XMPP (via OMEMO) & Matrix use libsignal for double-
| rachet encryption--so they have the same encryption
| properties. The biggest practical differences for the
| average user in my opinion is XMPP has a separate concept
| for DMs (not a 2-user room with encryption like Matrix),
| XMPP allows encryption to be both enabled then later
| disabled, & Matrix offers better resilience as messages &
| attachments get synced to all servers a room (which has a
| massive downside of resources, storage sizes, & moderation;
| if a server goes offline, you still have a history of the
| chat but if someone shares something explicit, such as CP,
| it will propagate thru the network & there is no way to
| delete it across nodes).
|
| One of the better comparisons out there: https://www.freie-
| messenger.de/en/systemvergleich/xmpp-matri...
| tcfhgj wrote:
| decentralized rooms, built in video conferencing,
| consistent chat history storage
| toastal wrote:
| I tried out an alpha client once & can't get the stupid pop-up
| about unverified devices to go away now. Another client didn't
| have the verification flow even set up--this will end up being
| yet another barrier to entry for new clients. With the clients
| (yes, multiple) crashing often, constantly syncing for ages, &
| feature sets not on parity + without graceful fallbacks, I do not
| like the Matrix client space (nor the server space, but that is a
| different topic).
|
| There has never been a better time to (re)embrace XMPP as your
| decentralized chat option. The clients are less buggy, handle
| missing features gracefully, & best part is, not being built on
| an eventual consistency model, you don't have the constant
| syncing issue with delayed messages. If you wanted you could make
| an XMPP client in a day since the base spec is small/simple--&
| features like device verification would be seen as mandatory in
| the base specification.
| mxuribe wrote:
| I used to consider myself a HUUUGE matrix fanboy....while i
| still respect what the teams have done over time, I have been
| feeling a little, i don't know, deflated maybe? Maybe its the
| UX/UI aspect, i don;t know...i have not run a homeserver since
| like maybe 2019 or so? But nowadays, i have less interest in
| running a homeserver, and as far using the various clients:
| meh. Element feels bloated, and others either might be more
| snappier but might have an odd bug, or don't implement all
| features that might be expected, etc.
|
| So, last year i tried to play briefly with Prosody server to
| re-acquaint myself with xmpp...and it wasn't so bad. Not as
| great as i expected for this day ana age, bbut not terrible.
| The server setup felt like i needed to study a bunch of
| different docs...and ultimately was smoother than
| expected....so i think documentation is either outdated, or was
| written a little less clear than expected. That being said, the
| low resource usage was ridiculously pleasant compared to matrix
| homeserver! The fact that an xmpp server allows for such
| scalability on such low resources is a great testament! And,
| that was prosody, which some folks state is not even as
| performant, scalable as ejabbered....so they say...so wow,
| that's impressive if that's true. Regardless, xmpp servers that
| can run on such low resource hardware but enable so many users
| to chat...is quite awesome!!! The client side of xmpp was a
| different matter; i wasn't so happy. I blame myself because
| maybe there might have been plugins that maybe i didn't install
| correctly on server side, i don't know...but it felt not as
| easy as i expected. The clients were a little disappointing;
| again not terrible but not great.
|
| Maybe i'm spoiled? Or, maybe i did too much wrong? But if
| that's the case, the maybe there's an opportunity for better
| documentaiton? I don't know....i really like both matrix and
| xmpp because both live in the realm of free and open source
| software.....so i really want both or either to succeed. I want
| to live in a world where we are not beholden to only
| proprietary options, like whatsapp, crappy sms/text messaging,
| etc. I want to give props to all the folks who made and
| maintain all aspects of xmpp...as much as i am whining, i don't
| want to take away from all the hard work that they have freely
| given; super props to them!!!
|
| What i really want is a modern, free and open source version of
| IRC, with plenty of modern features (E2EE, file uploads,
| presence detection, etc.), decent desktop and mobile clients,
| easy server installation and management, and said server-side
| software would ideally not need such beefy hardware to
| run...Or, is my wish too far fetched?
| chickensong wrote:
| I think we all want that. The fact that it doesn't exist is
| an indicator that it isn't trivial to build. All those modern
| features are at odds with performance.
| mxuribe wrote:
| > ...it isn't trivial to build. All those modern features
| are at odds with performance.
|
| I suppose both points make sense!
| toastal wrote:
| > can run on such low resource hardware
|
| This is what frees a barrier to decentralization & actually
| owning one's data. A few of my friends are now running their
| own single-user or small XMPP servers since it doesn't use
| much in terms of resources or storage in comparison.
|
| > The server setup felt like i needed to study a bunch of
| different doc
|
| I believe this is what the Snikket project is trying to be.
| That said, XMPP servers are used for a lot more than just
| chat which is why most of them don't have good defaults for
| merely chatting with friends since that isn't the only or a
| generic enough use case (XMPP is behind Zoom, Jitsi,
| Fortnite, etc.).
|
| > The clients were a little disappointing; again not terrible
| but not great
|
| True. But I appreciate that there are many options & most
| features gracefully fallback even on TUI clients (like
| 'reactions' just being a message reply with a single emoji).
| If Element adds a feature (like polls), the other clients,
| the new feature just doesn't show up. For a web client, the
| NLNet funding is really giving a boost to Movim as a
| reasonable alternative to Discord that is self-hostable &
| federated so users--taking back the meaning of "join my
| server" to literally mean someone's server & without needing
| to create another account just to join that server.
|
| As for the wish... this is what XMPP MUCs are--IRC with
| niceties like moderation, optional encryption, & file
| uploads. You said yourself the resources for servers is small
| & for your stated use case, most existing clients can handle
| being IRC+features while also not being centralized unlike
| IRC.
| mxuribe wrote:
| > ...that isn't the only or a generic enough use case (XMPP
| is behind Zoom, Jitsi, Fortnite, etc.
|
| Great point! I forgot that xmpp can/is used for other use
| cases that are not just chat.
|
| Also I guess I should be a little more forgiving about the
| MUCs, and client features in particular because you are
| right that fallbacks tend to be graceful.
| leetnewb wrote:
| One thing I would note on the client side of xmpp - there
| does seem to be a lot of work happening under the surface.
| Snikket is working on an SDK to streamline modern client
| development. There are a couple of alpha stage clients
| written on it already, and maturatoin of the SDK should lower
| the bar for pushing clients forward.
|
| Also independently, Movim keeps advancing and Libervia is
| doing a ton of cool work. I'm sure I am missing others.
| mxuribe wrote:
| I had only heard about Snikket as I was spinning down my
| xmpp experiment... maybe I can take a look nowadays
| (including moving and others). Thanks for sharing!
| tcfhgj wrote:
| > I tried out an alpha client once & can't get the stupid pop-
| up about unverified devices to go away now.
|
| Open app with device management (e.g. Element Desktop) and
| remove the unverified devices you don't intend to verify.
|
| Regarding XMPP: With the lack of Cross Signing, key backup and
| consistent storage of messages, it can't be expected to provide
| the convenience Matrix does for the foreseeable future - just
| my personal opinion. The matrix-rust-sdk should it also make
| easy to get started with a client.
| seszett wrote:
| I like XMPP and I use it with my family (with the Conversation
| client) but the web interface (converse.js) if pretty rough.
|
| I would like to replace Matrix at work with an XMPP server, but
| to convince my colleagues I would have to show something better
| than that :/
| Bayaz wrote:
| I have a private matrix server for a few friends. Whenever
| someone logs on with a new device or client it lists them as
| being unverified. Eventually it goes away. I really have no idea
| at what point verification occurs.
| jeroenhd wrote:
| They verify their device. Usually means opening Matrix on a
| other device, clicking the pop-up, and scanning a QR code or
| matching emoji. One device signs proof of verification of the
| other and exchanges encryption keys so the new device can read
| encrypted conversations.
|
| Unverified devices are indistinguishable from a hacker logging
| in through credential stuffing/password leaks until
| verification is done.
|
| It's a process similar to adding devices to Signal or WhatsApp,
| except with Matrix you can still log in without having physical
| access to another device. Useful if you only ever visit
| unencrypted rooms perhaps.
| iqihs wrote:
| _I think Matrix as a protocol has been pretty ineffective, as
| their top priority seems to be keeping data permanent and
| duplicated. Both performance and privacy are at the bottom of
| their priority list. The one good thing I can say about it is
| that encryption of message contents is enabled by default in
| conversations and available in groups, but that 's about it -
| nothing else is, or can be, encrypted. In other words, every
| participating server knows who is talking to who, and how much,
| and when, and in what rooms, and what those rooms' names are, and
| what those rooms' descriptions are, and who moderates them, etc._
|
| _Meanwhile, an app like Signal can do none of that, and that 's
| by design._
|
| _If you 're looking for a privacy oriented messaging system,
| you'd best look elsewhere._
|
| I'm new to Matrix and found this comment on reddit. How much of
| it is accurate and does it actually contribute to whether or not
| the future of the protocol is promising?
| kachapopopow wrote:
| it's pretty on point, it's mostly a "trusted" platform as long
| as you trust the host with the messages between two people (or
| more?) being (optionally) encrypted.
| xethos wrote:
| @Arathorn would be an objectively better person to discuss
| this, but the Redditor isn't completely off the mark: metadata
| is (currently) not nearly as well-guarded on Matrix compared to
| Signal.
|
| However, work is ongoing to improve the situation; more
| importantly, Matrix is a different threat model (in my
| opinion), and allows for different trade-offs.
|
| When I use Signal, I have to trust Signal's servers and their
| admin team. With Matrix, we get to keep trust circles smaller
| (friends and family on smaller servers, where we already trust
| the people running them). We have no hard requirement to
| federate either - if I want something just for people I know,
| we leak less data than Signal does to the outside world. We
| also get to host Matrix servers in areas we're comfortable
| with, whether that's our living room, or any nation that isn't
| America.
|
| Matrix isn't perfect, but I appreciate how quickly they're
| improving, and the areas they're focusing on.
| tptacek wrote:
| Matrix and Signal have very different objectives. Matrix
| wants to be an encrypted IRC or Slack. Signal wants to be a
| secure messenger you can entrust your life to. They are both
| worthy projects; there's not as much overlap as people think.
| pkulak wrote:
| I trust my life to the server I host in my own closet.
| People can lecture me all day long about the superiority of
| Signal's encryption, and I'll just slowly rotate my chair
| to point my index finger at the Dell OptiPlex behind me.
| tptacek wrote:
| That's fine. You'll pardon me if I'm unwilling to trust
| my own safety to your Dell OptiPlex. Whatever you think
| about Signal, the fact is that Matrix --- which is what
| the thread is about --- makes decisions that serve the
| IRC/Slack use case at the expense of the "absolute most
| possible safety" use case. That makes sense: some of
| larger-scale group chat's goals are in tension with
| "absolute most possible safety".
| dwohnitmok wrote:
| I wouldn't characterize Signal as "absolute most possible
| safety" as you are implicitly doing here.
|
| I would probably characterize Signal as "most possible
| safety for the average nontechnical user" which entails
| trade-offs against absolute safety for certain UX
| affordances (and project governance structures that allow
| for these decisions to be made), because if said
| affordances are not given, the average nontechnical user
| either simply won't use Signal or will accidentally end
| up making themselves even less secure.
| BolexNOLA wrote:
| This is basically the same logic for why I often
| recommend Plex over jellyfin to people. Yes Plex is not
| proper self hosting. Yes Plex the org is making
| increasingly questionable decisions. But for people who
| want to get away from the major streaming services and
| maybe even want to dip their toes into something that
| resembles self hosting, there really is no other option
| like Plex. It's so insanely turnkey and easy to install
| on every device. You also don't have to worry about
| exposing your network if you don't know what you're
| doing.
|
| If nothing else it's an incredible foot in the door for a
| lot of people to make the leap to something like jellyfin
| later.
| tptacek wrote:
| I couldn't be less interested in arguing with you about
| Signal. My point is that it doesn't make as much sense to
| compare Signal and Matrix as people think it does. Large-
| scale group chat is intrinsically less safe than the kind
| of chats most people use Signal for. You can substitute
| whichever other secure messenger you prefer.
|
| This "average nontechnical user" stuff, though, miss me
| with. For 2 decades people have been encouraging the
| "average nontechnical user" to do incredibly unsafe
| things on the premise that _any_ kind of message
| encryption is the best alternative to sending plaintext
| messages. No: telling people not to send those kinds of
| messages at all, unless you 're dead certain the channel
| they're using is safe, is the only responsible
| recommendation.
| JuniperMesos wrote:
| I have started using Signal for large group chats in the
| past year or so, after spending many years using it as an
| encrypted replacement for SMS texting. Signal has gotten
| noticeably better at the UX of group chats during that
| time, although I am still annoyed that they basically
| require you to use their client to access the network in
| the name of security. I can't easily run a legitimate 3rd
| party Signal client on my server, and when I've tried
| I've accidentally broken my access to my account on my
| phone, which is quite annoying since I use Signal pretty
| frequently.
|
| I want there to be something like Matrix that is designed
| first and foremost as a large-group realtime chat program
| (really, as a meaningful FOSS alternative to Discord),
| and it should make different tradeoffs than Signal. I'm
| actually willing to entirely forego encryption, at least
| at first, to make this happen - IRC wasn't encrypted and
| Discord isn't either, and these are things I want to
| replace with something better. Matrix's UX is still
| noticeably worse than Discord's, and I'm skeptical that
| the ostensible security gains from the encryption are
| worth it, especially given the problems with device
| verification UX, metadata leakage, and the fact that as
| the number of people in a group chat grows the
| possibility that they will take a screenshot of the
| encrypted message sent to them and leak it to the press
| grows higher and higher.
| dwohnitmok wrote:
| > This "average nontechnical user" stuff, though, miss me
| with. For 2 decades people have been encouraging the
| "average nontechnical user" to do incredibly unsafe
| things on the premise that any kind of message encryption
| is the best alternative to sending plaintext messages.
| No: telling people not to send those kinds of messages at
| all, unless you're dead certain the channel they're using
| is safe, is the only responsible recommendation.
|
| Eh. You misunderstand me. I don't really have too much of
| a view on this personally. Unless you specifically think
| that the term "average nontechnical user" is a bad term.
|
| N.B. for other readers of this thread to flesh out my
| initial point:
|
| Signal specifically _didn 't_ do that recommendation
| until they got sufficient critical mass of users in 2022.
| In particular Signal gracefully degraded to unencrypted
| SMS if the other side didn't have Signal.
|
| Likewise Signal required phone numbers until 2024 when it
| shifted over to usernames, with all the security
| vulnerabilities that entails.
|
| Signal has repeatedly made trade-offs that prioritize UX
| over absolute security even in 1-1 chat settings. That's
| not to criticize those trade-offs, there's a variety of
| reasons why they make sense or don't. But Signal has
| consistently demonstrated that it is not willing to make
| severe compromises to the UX and understandability in the
| name of absolute security and that it will balance the
| two.
| NegativeK wrote:
| I obviously can't speak for you, but there's not a
| freaking chance I'd trust my life to the servers I run.
|
| To go maybe too literal: when I'm working on machines
| that could physically eat me, I don't trust myself with
| just one off switch -- I want redundancy. And since
| computers are horrible piles of ridiculous complexity,
| the closest I can get (and not really get close) is
| trusting some of the top minds to overthink the crap out
| of it in a way that I can't do with the systems I manage.
|
| But again, YMMV.
| pkulak wrote:
| Well, when US-EAST-1 went down, my family was still
| chatting. Same with Cloudflare. Even if I lose internet,
| we can all chat so long as we're on the network.
|
| That said, the uptime is still probably worse than
| Signal. I didn't mean trust the reliability. I meant the
| security.
| butvacuum wrote:
| When you leak that much metadata, it's disenginious to call
| it encrypted.
| kiitos wrote:
| > Matrix wants to be an encrypted IRC or Slack
|
| matrix's _users_ want it to be a decentralized /encrypted
| irc/slack, but unfortunately matrix's _maintainers_ believe
| their mandate is to build a next-gen tcp /ip (or something
| very close to that)
|
| which dooms the project
| tptacek wrote:
| Hey, I've been there!
|
| https://web.archive.org/web/19991128144800/http://sonicit
| y.c...
|
| https://web.archive.org/web/20010223171430/http://www.son
| ici...
| Gigachad wrote:
| In the real world friends and family aren't running their own
| matrix servers. At most they are signed up for whatever
| random one came up first in the search results.
|
| So you end up with a similar problem to Mastodon where either
| you are facing problematic or inexperienced admins, servers
| shutting down, and everyone centralising on the main server.
| Klaus23 wrote:
| It's pretty accurate. I was a bit shocked when I saw that room
| names were not encrypted. I thought that was such a basic
| privacy requirement, and it's not hard to implement when you
| already have message encryption.
|
| Matrix seems to have a lot of these structural flaws. Even the
| encryption praised in the Reddit post has had problems for
| years where messages don't decrypt. These issues are patched
| slowly over time, but you shouldn't need to show me a graph
| demonstrating how you have slowly decreased the decryption
| issues. There shouldn't be any to begin with! If there are, the
| protocol is fundamentally broken.
|
| They are slowly improving everything, with the emphasis on
| "slowly". It will take years until everything is properly
| implemented. To answer the question of whether the future of
| the protocol is promising, I would say yes. This is in no small
| part because there are currently no real alternatives in this
| area. If you want an open system, this is the best option.
| jeroenhd wrote:
| The decryption problems I've experienced have a been fixed a
| while ago. There was a push to fix these last year or the
| year before that, and at this point I'm pretty sure only some
| outdated or obscure clients with old encryption liberties
| still suffer from these problems.
|
| The huge amount of unencrypted metadata is pretty hard to
| avoid with Matrix, though. It's the inevitable result of
| stuffing encryption into an unencrypted protocol later,
| rather than designing the protocol to be encrypted from the
| start.
|
| I've had similar issues with other protocols too, though.
| XMPP wouldn't decrypt my messages (because apparently I used
| the wrong encryption for one of the clients), and Signal got
| into some funky state where I needed to re-setup and delete
| all of my old messages before I could use it again.
| Maintained XMPP clients (both of them) seem to have fixed
| their encryption support and Signal now has backups so none
| of these problems should happen again, but this stuff is
| never easy.
| Klaus23 wrote:
| Yes, messaging protocols, especially federated ones, are
| never easy. I just wish we could have skipped the three or
| four years when Matrix was basically unusable for the
| average user because end-to-end encryption was switched on
| by default. Perhaps a clean redesign would have been
| better. Now they have to change the wheels on a moving car.
| tcfhgj wrote:
| > These issues are patched slowly over time, but you
| shouldn't need to show me a graph demonstrating how you have
| slowly decreased the decryption issues. There shouldn't be
| any to begin with! If there are, the protocol is
| fundamentally broken.
|
| This is wrong, because afaik these errors happen due to
| corner cases and I really don't like the attitude here.
| Klaus23 wrote:
| It's not just a corner case. The issue was so prevalent for
| years that if it was limited to just a few corner cases,
| the entire protocol must consist of nothing but corner
| cases.
|
| It frequently occurred on the "happy path": on a single
| server that they control, between identical official
| clients, in the simplest of situations. There really is no
| excuse.
|
| I'm not saying that building a federated chat network with
| working encryption is easy. On the contrary, it is very
| hard. I'm sure the designers had the best intentions, but
| they simply lacked the competence to overcome such a
| challenge and ensure the protocol was mostly functional
| right from the outset.
| tcfhgj wrote:
| > The issue was so prevalent for years that if it was
| limited to just a few corner cases, the entire protocol
| must consist of nothing but corner cases.
|
| for me it wasn't really; occasionally it would hit me,
| but mostly it worked, and I have been using it for
| encrypted communication since 2020.
|
| > It frequently occurred on the "happy path": on a single
| server that they control, between identical official
| clients, in the simplest of situations. There really is
| no excuse.
|
| There still can be technical corner cases in the
| interaction of clients
|
| a talk for details:
| https://www.youtube.com/watch?v=ZUSucR2axWI
|
| > I'm sure the designers had the best intentions, but
| they simply lacked the competence to overcome such a
| challenge and ensure the protocol was mostly functional
| right from the outset.
|
| well, even if this was true, they still were brave enough
| to try and eventually pull it off eventually. Perhaps
| complain to the competent people who haven't even tried.
| Klaus23 wrote:
| > for me it wasn't really; occasionally it would hit me,
| but mostly it worked, and I have been using it for
| encrypted communication since 2020.
|
| I think the statistic said that around 10% of users
| receive at least one "unable to decrypt" message on any
| given day. That's a lot. Perhaps not for devs who are
| accustomed to technical frustrations, but for non-
| technical people, that's far too frequent. Other
| messaging systems worked much better.
|
| > There still can be technical corner cases in the
| interaction of clients
|
| > a talk for details:
| https://www.youtube.com/watch?v=ZUSucR2axWI
|
| You linked to a German political talk show. If you wanted
| to show me the talk in which the guy listed reasons such
| as "network requests can fail and our retry logic is so
| buggy that it often breaks" and "the application
| regularly corrupts its internal state, so we have to
| recover from that, which is not always easily possible",
| let's just say I wasn't that impressed.
|
| > well, even if this was true, they still were brave
| enough to try and eventually pull it off eventually.
| Perhaps complain to the competent people who haven't even
| tried.
|
| It isn't a problem that the Matrix team are not federated
| networking experts. At the time, they had already
| received millions in investment. That's not FAANG money,
| but it's still enough to contract the right people to
| help design everything properly.
|
| I'm not mad at them. Matrix was a bold effort that
| clearly succeeded in its aims. I'm just disappointed that
| it was so unreliable for such a long time, and still is
| to some extent.
| tcfhgj wrote:
| Correct link: https://www.youtube.com/watch?v=FHzh2Y7BABQ
|
| > I wasn't that impressed.
|
| If you think, I want to impress you, you are wrong.
| this_user wrote:
| I think part of the problem may be that Matrix is just pretty
| complex, because of its modular and decentralised design.
| Meanwhile, Signal is much more centralised and monolithic. And
| while they have added a few features over the years, its core
| functionality is relatively simple, and they were initially
| just focussed on getting that right.
| Gigachad wrote:
| I remember reading some of the pdf on state management in
| matrix. The math and logic behind working out what the
| current name of the group chat is made my head spin.
| AJ007 wrote:
| The "decentralization" of Matrix is true in some respects,
| and false in others. Which would be ok, but if all of the
| complex architecture and issues are in the support of being
| decentralized, then this seems like an early planning
| failure.
|
| My suspicion is the real problem that exists now originated
| from the bifurcation of desktop and mobile. Mobile broke the
| true p2p decentralization which was easy on desktop, and the
| split between Android and iOS makes it worse. Users expect an
| experience on iOS and Android which has parity with desktop.
| And the entire thing has to be as good as Discord.
|
| I've taken a hard look at all of the truly open source
| alternative messaging options, and almost nothing handles
| multi-platform very well. Even when you expand it to
| commercial options, for a very long time, all of the Slack
| clones had mediocre mobile apps -- which basically was a
| death sentence if you weren't Microsoft. This is true today,
| but I expect it will change in 2026 and onward with the rapid
| increase in software development driven by AI agents.
| sroerick wrote:
| Pretty crazy, right? It almost seems like a honeypot
| the_gipsy wrote:
| To be fair: signal means everybody trusts one central
| authority. Doesn't matter that it's a foundation or non-profit
| or whatever.
|
| And: a phone number is still required, a PIN is not, so by
| default it's susceptible to phone/SIM spoofing attacks. This
| one really boggles my mind, it's not that I personally am
| afraid of this vector, but I don't understand why they would
| insist on phone numbers at this point.
| RicoElectrico wrote:
| I wish FOSS communities that want an alternative to Discord or
| Slack ditched Matrix altogeter. It sucks for that. Better use
| Zulip or Mattermost, both of which are self-hostable.
|
| Edit: I looked up and apparently Mattermost would be out of the
| question for their feature downgrades in the community version
| as of late...
| broken-kebab wrote:
| Correct me if I'm wrong but I believe Zulip's licensing de
| facto restrict self-hosting solution for 10 users (others
| won't see notifications on their mobiles or something like
| that). This is important for non-commercial communities.
| jrm4 wrote:
| Okay so -- this and Bluesky.
|
| REALLY feels like no one talks about how "permanent and
| duplicated" is very much an _anti_ -feature if autonomy and
| safety and freedom is your goal?
|
| Like, no actually - automatically saving everything all the
| time is bad. I thought we sort of already knew that.
| unbolted3032 wrote:
| I decommissioned my server 3 months ago and migrated my community
| back to IRC. I still had the IRC Podman containers kicking
| around, so that was easy.
|
| I dealt with ~monthly issues around my devices not being
| correctly verified, messages not correctly decrypting, and
| various other rough UX edges. There seemed to be a lot of
| velocity in the beginning but the last couple of years have
| addressed approximately nothing in terms of the UX and it's a
| crying shame as Matrix/Element (I no longer fully understand the
| difference/relationship between these entities) had a lot of
| potential.
| colordrops wrote:
| The rough edges are too much for even very technical users and
| admins, so there's no way we're going to get friends and family
| to adopt this.
| solarkraft wrote:
| > but the last couple of years have addressed approximately
| nothing in terms of the UX
|
| This sucks to hear. I thought they had made massive
| improvements in the last year or so (I don't know because I
| feel too burnt by past experience).
| OberstKrueger wrote:
| Unfortunately how I feel about it too. I gave an honest effort
| at getting into the ecosystem and tested it out with a few
| close friends. The rough edges brought the experience down
| compared to other stuff that "just works", and losing community
| support for the IRC bridge took a huge use of my own away from
| it.
| Sanzig wrote:
| Let's not forget the shock image spam issue. Public Matrix
| channels are plagued with horrendous shock images (including
| CSAM). The development team seems to not care, they have a
| proposal for "policy servers" which is still incomplete and not
| supported by all server implementations.
| joecool1029 wrote:
| It's terrible. I had to leave most channels on the matrix.org
| namespace because they won't properly moderate their own
| server from CSAM. I dropped to 7 day media retention to lower
| legal liability on my own server, since there's no way to
| know when one of my users will be in a channel hit with
| abuse.
|
| At this point the majority use case I have for matrix is to
| bridge to IRC with heisenbridge and be able to use signal on
| my laptop through mautrix-signal and nheko. The number of
| native channels I'm in continues to shrink.
| indolering wrote:
| Have they done anything to mitigate this? Like client side
| filters or message scanning for new direct messages?
| Arathorn wrote:
| The main things are
| https://matrix.org/blog/2025/04/introducing-policy-
| servers/ (for flexible serverside moderation) and the
| rest of the stuff in
| https://matrix.org/blog/2025/02/building-a-safer-matrix/.
| Clientside filters already existed, but given they only
| apply per client and there are a lot of different
| clients, we focused on serverside filtering.
| mystraline wrote:
| I know the matrix honeserver I use has taken our
| recommendations to NOT cache images from matrix.org due to
| their non-existent moderation. And the admin put out a
| bulletin to also recommend disable downloading images as
| well.
|
| There's also the split room bug (feature?) that allows
| banned users to still be in rooms where the honeserver
| doesnt ban them. And then, distributes connection shows
| ongoing banned content (primarily, you guessed it, CSAM)
| and the better-moderating admins can't do anything about
| it.
|
| I'm basically in a few well moderated rooms (Gnuradio,
| other topics). They do extraordinarily well in not getting
| many trolls, and for garbage collection.
|
| The only one we're seeing spammed is for some
| cryptocurrency site Liquid something. But its just
| commercial spam.
| teekert wrote:
| Let's not forget a team making a great free product. Yeah we
| can complain about filthy materials but imagine you working
| hard to build something as nice as Matrix/Element only for
| these low-lifes to do these horrible things to it. How
| annoying it must be to have to spend time battling such
| things.
| whatevaa wrote:
| If you make anything public, you will have to deal with it.
| You should be mentally prepared for that from the start.
| johnisgood wrote:
| I mean I could just as easily say you as an user should
| be mentally prepared.
|
| Matrix is developing a privacy IM, you do not really
| moderate that now, do you? Leave the rooms that raise
| your cortisol level.
| jacquesm wrote:
| > I mean I could just as easily say you as an user should
| be mentally prepared.
|
| Users tend to be less aware of these things than the
| operators of such servers (or at least, that's how it
| should be).
|
| > Matrix is developing a privacy IM, you do not really
| moderate that now, do you?
|
| No, but you can create mechanisms for the users to flag
| problematic accounts.
|
| > Leave the rooms that raise your cortisol level.
|
| The filth will follow the users. That's the whole game
| plan here: to cause grief.
| johnisgood wrote:
| I have been in many rooms that are completely fine;
| technical rooms.
|
| As for flagging problematic accounts: how would that work
| in a decentralized E2EE system, and do you think it
| cannot be abused? What would you want them to do if I
| flag your account a million times? Keep in mind they
| probably may not be able to keep up with it, nor do I
| expect them to. Additionally, you still should be able to
| use the service due to its decentralized, privacy-
| preserving nature, so the worst thing that may happen is
| getting banned from a Matrix instance, or a room.
| Teever wrote:
| Wait a minute, doesn't receiving child porn even if
| unintentionally like the situation above open up the
| receiver to legal liability?
|
| It isn't reasonable to expect users to be 'mentally
| prepared' to have their devices download child porn
| because they visited a chat room for support about the
| chat app they're using.
| tcfhgj wrote:
| I'd blame the law if it does.
| johnisgood wrote:
| As someone else have said, then that is an issue with the
| law.
|
| Imagine someone sending you a link that you open and then
| now you have child porn or whatever else on your hard
| drive, cached. Quite a shitty situation to be in.
|
| Perhaps avoid non-technical rooms or rooms in which you
| do not trust people.
| gosub100 wrote:
| And then imagine you have windows with recall enabled
| (that you repeatedly disabled but keeps enabling after
| updates), and/or cloud backup with automatic CSAM
| detection. You're screwed
| johnisgood wrote:
| Yes, and we are screwed either way if we use Windows with
| Recall, or even in general.
|
| I would not consider Windows secure at all, and it seems
| futile to use a privacy-oriented IM on Windows, it really
| defeats the purpose.
|
| Imagine using Windows with Recall enabled that takes
| screenshots of your conversations all the time. You can
| be using the most effective IM for privacy but it would
| not help.
|
| So what is the moral of the story? We have shitty laws,
| and you should not use Windows. :P
| lukan wrote:
| "Imagine someone sending you a link that you open and
| then now you have child porn or whatever else on your
| hard drive, cached. Quite a shitty situation to be in."
|
| I guess the correct legal approach would be to go to
| police with this.
|
| And the correct technical approach to keep online spaces
| clean, is the ability to kick, mute or ban people who
| violate the rules.
|
| Saying, "just be mentally prepared" sounds to me like
| accepting it. Well, I don't. I go somewhere else.
| johnisgood wrote:
| I did not use the term "mentally prepared" because I
| thought it was appropriate, I was just quoting the other
| guy. I find it silly, too. I will not "accept" child porn
| or other degeneracies.
|
| > Saying, "just be mentally prepared" sounds to me like
| accepting it. Well, I don't. I go somewhere else.
|
| Exactly! You should be going somewhere else. Another
| Matrix instance, or at the very least another room, and
| you will be fine.
| lukan wrote:
| "You should be going somewhere else. Another Matrix
| instance, or at the very least another room, and you will
| be fine."
|
| Well, but I never decided to hang around for longer.
| Maybe it is because the moderation tools are simply
| lacking? I would miss the option of not restricting
| certain users to send pictures in a group.
| johnisgood wrote:
| I am not sure if it is currently possible in Matrix, but
| it is not a bad idea to be able to restrict sending
| pictures (among other things), I agree.
| lukan wrote:
| I just read some complaints with links in sibling
| comments and sadly no, not possible. Maybe even hard to
| implement, because of the protocol.
| kldg wrote:
| in defense of this comment, you do need to do a heck of a
| lot of preparation (including psychologically) to do
| anything publicly anymore. wild west days are long gone,
| at least for US-based servers. I spend a lot of time
| thinking about how to stop users from interacting too
| freely, to censor and moderate them so I don't wind up on
| some news site in 20 years being accused of hosting a
| site *Widely Used* by pedophilic narcoterror jihadists; I
| would like to not, but user content (and especially their
| information) is a huge liability to host... unless you're
| Equifax or Facebook or Google or some other large
| corporation -- then you can accidentally dump out
| everyone's sensitive financial information and only pay
| them $9 in compensation (or whatever the amount was; I
| keep throwing the cards they send me in the trash).
|
| (yes I'm salty about that still)
| jacquesm wrote:
| It is super annoying but you have to be very naive to not
| understand that _anything_ that can be abused will be
| abused so you need to bake in countermeasures from day #1
| or you might as well not bother with the launch.
| tcfhgj wrote:
| with that strategy you won't launch ever if you have
| limited budget, especially because Matrix isn't exactly a
| system/protocol off the self
| teekert wrote:
| Aren't there any moderators in those channels? I have 0
| issues in the channels I am in (some podcasting channels,
| some tech, some FOSDEM.)
|
| I find a lot of value in Element as is, I'm glad they
| bothered.
| Aurornis wrote:
| > Let's not forget a team making a great free product.
|
| I am fully appreciative of the work that goes into making a
| product like this, but I'm also tired of this mentality
| that nobody is allowed to talk about the problems with the
| product. Even simple comments from people who tried to use
| the product but encountered show-stopping issues are
| getting downvoted into gray text in this thread.
|
| This mentality that we must only speak praise and cannot
| speak of problems because a product is free is further off
| putting. I've given Matrix/Element an honest try many times
| because some of the OSS projects I'm involved with use it,
| but month after month it's the most troublesome of all of
| the apps in this space that I use, and it's not even close.
| If I've gone a month without dealing with Matrix and I have
| to open it again it feels like there's a 50:50 chance
| something is going to either be inexplicably broken or
| cause problems even though I thought I finally had it all
| working last time.
|
| The contrast between how hard we're told that Matrix is the
| great and superior option and the reality of what it's like
| to use it as a casual or occasional user is really wearing
| me out on the project.
| eredengrin wrote:
| > I'm also tired of this mentality that nobody is allowed
| to talk about the problems with the product
|
| I think there's a pretty big difference between
| constructive criticism vs statements like "The
| development team seems to not care". To me, it seems
| pretty clear that the team absolutely cares, but they are
| also a small and very underfunded team, and things take
| time. Assuming the worst intentions of a team is the
| problem and is disappointing to see here.
|
| > I've given Matrix/Element an honest try many times
| because some of the OSS projects I'm involved with use
| it, but month after month it's the most troublesome of
| all of the apps in this space that I use, and it's not
| even close.
|
| I don't doubt that, but it does not resonate with me.
| There have been a few hiccups over the years, eg the
| database corruption earlier this year (unrelated to the
| protocol or synapse) resulting in stuck invites, but
| overall I've had quite a good experience. Far less
| problems than Teams, and even slack has had issues
| (mainly, notifications not happening) that I have somehow
| avoided with Element, although I am aware others have had
| issues in this area. There are even some things I do with
| matrix that are simply not possible/practical with the
| others to begin with.
| gmerc wrote:
| A product as unsuitable for the adversarial internet as
| ChatGPT and coding agents
| wkat4242 wrote:
| It's free for us but not for businesses. I think this is
| why they are ruining the UX, because they're adapting it to
| their target market, like making it more like MS Teams.
| BrenBarn wrote:
| It's kind of wild to me that they haven't prioritized this
| more. This issue has been open for almost exactly 6 years:
| https://github.com/matrix-org/matrix-spec/issues/565 . This
| one even longer: https://github.com/matrix-org/matrix-
| spec/issues/836 . The Matrix permission system still doesn't
| even have a way to say "sending images is not allowed"
| (either per room or per user).
| tcfhgj wrote:
| maybe because of limited budget and more urgent issues? who
| knows
| chrisjj wrote:
| And what could be more urgent than this?
| tcfhgj wrote:
| having a usable technical foundation, staying financially
| afloat
| Arathorn wrote:
| building a more flexible solution for blocking content,
| rather than hardcoded rules like "no images":
| https://matrix.org/blog/2025/04/introducing-policy-
| servers/
| tcfhgj wrote:
| policy servers show that they indeed do care
| irusensei wrote:
| Considering the thread context I'm curious how would IRC help
| with that other than people running command line or TUI
| clients?
|
| Also do you want the development team to moderate self hosted
| chat servers? How would that work?
| Macha wrote:
| Must irc clients do not automatically download or show
| images which means joining a room and spamming a bunch of
| them is less impactful on recipients and so less appealing
| to trolls, so it doesn't happen.
| BrenBarn wrote:
| I feel they underestimated what the MVP really is and started
| touting Matrix as great before it was really there, which has
| backfired and led to disappointment. They also went a bit too
| overboard on the overgeneralized idea of it being "a
| decentralized eventually consistent JSON database", which led
| to a lack of focus on its concrete usability as a chat system.
| I still use it and it's not bad in some respects, but it's a
| long, long way away from being able to attract a mass of
| ordinary users.
| amluto wrote:
| You did better than I did. I installed the recommended Element
| app, created an account on matrix.org, tried to send a message
| to another user, and... gave up. Every try got stuck and
| eventually created an empty room or whatever they call it. I
| have literally never succeeded in sending or receiving a single
| message.
| trueno wrote:
| There really is no winning in the org comms/chat apps space
| when it comes to OSS. Matrix+element, rocket, mattermost,
| Zulip and so on.. feels like there's either massive gotchas
| on free/self hosted or it's wildly complicated to configure
| and set up. I've been thinking about this a lot. Hosting a
| private irc server and you lose out on rich embeds and will
| need your own pastebin-like service to use, video
| conferencing is probably a big challenge, the need for a
| mobile app at many workplaces. Bleh. I look at something like
| slack and I'm like damn that is literally irc+ and I just
| hate that I don't have the skills to build up something
| completely free that I could host at my org. Teams literally
| owned everyone when they started bundling it in and rug
| pulling slack. Ofc the execs at my workplace were like "hell
| yeah this is great" but so did my IT dept. I was so pissed.
| Out of the box it's just instantly compliant which was a
| major driver then of course at the time it was seen as a free
| offering (I know they've since had to decouple that) which
| completely nuked slack at our org. I can't even believe I'm
| saying this but teams actually makes collaborating slower. No
| one on my team uses the channels we all pin chat groups and
| exclusively use that. It's literally garbage. I guess I'm
| just venting, I really hoped I could find something in the
| oss world to supplant this and I think the bar for
| organizations is: compliance, chat, video conf and sigh the
| ability to schedule in outlook.
| DANmode wrote:
| "Compliance" with _what_?
| trueno wrote:
| Great question! Next question please.
|
| (I have no idea that's the BS I was told when we left
| slack for teams)
| tabbott wrote:
| What do you see as the gotchas with Zulip for community
| use? Zulip is 100% open-source, and we sponsor our hosted
| services (mobile notifications, etc.) free for OSS
| projects.
| trueno wrote:
| Hi ! So zulip is actually probably top of this list as
| the best self managed solution and I'm sorry if I
| conveyed that it was even near the same ballpark of some
| of the others. I actually think it's pretty neat.
| Interestingly the thing that made us spin down our zulip
| instance after ten minutes was the "async conversations".
| I understand this is a core differentiator for zulip but
| it immediately felt like the teams channel threading
| which none of us can stand. The intentions are noble, and
| the implementation is way better than teams, but it's
| interesting to me that solutioning for preventing things
| from getting buried became the core UX philosophy at
| play. Really there is something that just works with an
| absolutely straight forward chronological list of chat
| messages used in conjunction with a capable search
| indexer. It's not that we aren't willing to try new
| paradigms, we have tried this paradigm. For a while now.
| Our topic'd channels are a ghost town these days, our
| entire org has just moved to making group chats in teams
| that serve as channels and pinning them because it's just
| way easier to work together with regular chat. Ironically
| we fail to respond to things and struggle more to find
| things in a topic/threaded paradigm as it seems to go a
| little too far in isolating "noise". A lot of
| serendipitous participation and aha moments and memes
| come from just glancing a chat discussion that might not
| immediately involve your attention, and we just operate
| way better in the open chat space needing only
| channels/members for the right amount of organization.
| nine_k wrote:
| If _IRC_ suffices for your purposes, then Matrix, with its
| encryption and all, is apparently overkill.
|
| If I were to upgrade an IRC-based community to something newer
| and richer, I'd go with Jabber, well-known, well-established,
| with a ton of various clients and several servers. Yes, it's
| not ideal, but it's still a massive upgrade compared to IRC, if
| your server supports a good list XEPs and your community
| members agree to use non-esoteric clients that also support
| them.
| ErroneousBosh wrote:
| > If IRC suffices for your purposes, then Matrix, with its
| encryption and all, is apparently overkill.
|
| IRC has encryption too. You run it over TLS.
| immibis wrote:
| For E2EE there is the very old unofficial and only-
| partially-secure extension of using Blowfish with a static
| key.
| ErroneousBosh wrote:
| I guess it's not end-to-end, it's decrypted on the
| server.
|
| Presumably if you want to send an encrypted message from
| one literal endpoint to another, you'd use some other
| technology. I'm prepared to bet there are enough people
| doing just that, too.
| immibis wrote:
| The extension I just mentioned is E2EE.
| bigfudge wrote:
| It's that hard even with a user in the loop to press buttons.
| Verifying bots is even worse and the docs are either non
| existent or wrong. This is such a shame because element
| otherwise does exactly what we want but it makes me nervous
| it's so badly supported and buggy.
| Timshel wrote:
| Anecdotal but running a server with multiple bridges for
| multiple years. Had such issues initially but none recently.
| tcfhgj wrote:
| > There seemed to be a lot of velocity in the beginning but the
| last couple of years have addressed approximately nothing in
| terms of the UX and it's a crying shame as Matrix/Element had a
| lot of potential.
|
| It still has.
|
| And with Element X they have greatly improved the UX.
|
| Plus utd errors have been reduced by a lot.
|
| That said, I haven't ever had issues with devices not being
| correctly verified ( I use that feature since it was released -
| and can still recover the encrypted messages of that time).
| phantasmish wrote:
| When I looked into it the complexity of standing up and
| admin'ing a Matrix server was clearly either a massive
| "architecture smell" so bad the project was likely long-term
| doomed, or a deliberate choice to make it terrible to get
| people to pay for managed hosting.
|
| In either case, that's a no for me dawg.
| solarkraft wrote:
| This is a good thing. It is (was?) all too inviting to leave
| clients unverified because verification is (was?) hard and
| annoying.
|
| The code examples I'm aware of for clients using the first-party
| library also leave verification and E2EE out, FWIW.
| octoberfranklin wrote:
| This is supposed to be what decentralization looks like?
| iamnothere wrote:
| It's still decentralized. If you read the article this is about
| cryptographic verification, not anything about ID.
| pkulak wrote:
| Despite all the gnashing of teeth in this thread, this seems
| reasonable. This seems to only prevent you from logging into your
| account, with only a password, NOT verifying it (by dismissing
| all the prompts asking you to do so), and then sending (and
| receiving new!) encrypted messages anyway. I've never used an
| unverified Matrix account in the 6 years that I've been an active
| user. Verification used to be a bit finicky, but it's pretty
| seamless now. And once the QR code login stuff is better
| supported, it will be dead easy.
| IlikeKitties wrote:
| > Despite all the gnashing of teeth in this thread, this seems
| reasonable
|
| I think it's not the requirement itself that's the crucible of
| discussion but the issues are rather that the blog post should
| have explicitly defined what verification is in it's second
| sentence and that matrix/element still is barely useable even
| for reasonably technical users.
| pkulak wrote:
| > barely useable even for reasonably technical users
|
| My entire family (including my elderly mother) would be very
| interested to learn how technical they are!
| IlikeKitties wrote:
| Argue with the people in this thread that made this
| argument.
| broken-kebab wrote:
| Scale matters. Once you achieve over a hundred of users,
| you got all the random bugs, and glitches appearing, and
| you can't guide everyone personally across UX issues. This
| is when lack of decent documentation, unpolished UI, and
| even the fact that it uses its own terminology (like
| "spaces") starts to hurt. I don't mean Synapse/Element
| combination is bad, but so far it's not great either.
| Gigachad wrote:
| Doesn't verification also exchange encryption keys, letting you
| decrypt messages from before you logged in? I remember that
| being a huge issue where you would see unable to decrypt
| messages.
|
| Probably just bad UX to let people skip the verification step.
| pkulak wrote:
| Yes. If you don't verify, every conversation is empty.
| joecool1029 wrote:
| But it also asks for recovery key and complains about it
| being out of sync until entered even if you do the
| verification step! Entirely possible to only get a partial
| recovery of messages until this is entered.
| jeroenhd wrote:
| That's not normal. It doesn't happen on any of my
| accounts or clients. Verification takes a moment if
| you're in a lot of rooms, but it exchanges all keys.
| rcxdude wrote:
| been a pretty reliable issue when I've set up a new
| device. Whatever keys the client is getting, they're
| apparently not useful.
|
| (This general flakiness of features just sometimes not
| working as they should is probably the main reason I
| haven't tried to recommend friends to switch to element)
| tcfhgj wrote:
| cannot confirm this either
|
| one method of verification suffices (be it recovery key
| or using a different device)
| tcfhgj wrote:
| > Doesn't verification also exchange encryption keys, letting
| you decrypt messages from before you logged in?
|
| if you use key backup
| Aurornis wrote:
| > Despite all the gnashing of teeth in this thread, this seems
| reasonable
|
| I empathize a lot with the negative experiences shared in this
| thread.
|
| I think the problem is that every little decision in Matrix
| might be reasonable to the people who have complete context
| about the decision, but all of the churn and rough edges have
| added up to a very bumpy ride. Not only that, but it has been a
| poorly communicated and documented ride as many in this comment
| section can attest.
|
| I suspect all of these issues and changes feel like no problem
| to people who are active in Matrix every day and have a support
| network to chat with where they all get through the issues by
| sharing tips and info. For the rest of us who are casual users
| who only occasionally log in it feels like I'm rolling the dice
| every time I have to use it. Some times it works like it did
| last time, some times I have to go on a 30 minute adventure
| with Google and play games across devices to get it back into a
| working state again.
| snerbles wrote:
| > Not only that, but it has been a poorly communicated and
| documented ride as many in this comment section can attest.
|
| The guides are written for cryptographic infrastructure nerds
| and not _regular normal users_ that have a habit of
| forgetting their own passwords after six months. Not to
| mention the fact that the Element UI tends to churn _a lot_.
|
| I didn't even know that they deprecated creating new
| passphrases, and that's what I was telling my users to do!
| ikkun wrote:
| seems like it's just that element (the official, and most popular
| client) will ignore messages from unverified devices, but since
| it's part of the spec, other clients that want to be spec-
| compliant will implement this too. I don't think most other
| clients follow the spec that closely though.
|
| I'm in favor of the change, the only downside I can think of is
| users with esoteric clients or simple bots that don't support
| verification won't be able to post to encrypted rooms with
| element users.
|
| I feel like I'm alone in having good luck with matrix. I've been
| self hosting for nearly a decade to a handful of users, and it
| was a bit rough troubleshooting the encryption problems back when
| element was still called riot, but it's been a number of years
| since any of us have had a single encryption issue, and we added
| a new user recently with no trouble. we're still on 'element
| classic' though, the new 'element x' is a bit of a mess and loses
| the background sync feature, you need to set up a unified push
| server which I'm not looking forward to.
| prurigro wrote:
| For what it's worth, I've been using element x with unified
| push for a month or so now and I get notifications with message
| contents without any delay. Maybe they fixed the issue you're
| worrying about?
|
| Self hosting the call/video feature became a lot more
| complicated though (and it's incompatible with the old system).
| ikkun wrote:
| my issues with element x are with the client itself, mostly
| missing features and bad UX. the main reason I don't want
| unified push is, it's just yet another thing for me to
| install and maintain, plus all my users need the client app
| installed. the ntfy server app even defaults to having a full
| web interface, fortunately it's possible to disable but it's
| just so much stuff to replace what used to be built-in to the
| app, to supposedly solve a battery life problem that I've
| never experienced.
|
| I'm still going to get around to it, because element classic
| will be deprecated eventually. one of my users is on iOS and
| has a well-known bug with images not loading, which will
| probably never get fixed because they're focusing on the new
| client. and unfortunately I do have users that expect voice
| calls to work, so it sucks to hear that'll be annoying too.
| tcfhgj wrote:
| no, you are not alone, though I don't host
| eTomte wrote:
| I've had mostly good luck with Matrix too. Been self-hosting
| since 2022 and while there have been frustrations it has been
| pretty stable for basic chat.
| g-b-r wrote:
| One of the super confusing things is that even if you only use a
| single client it can be verified or not.
|
| That's confusing even for very technical people; because, it
| simply doesn't make sense.
|
| Saying "verified or primary client with recovery keys generated"
| seems too long, so they should just say something like "less
| secure" on the "unverified" sessions.
| rabf wrote:
| Does anyone have any experience with Keet as an alternative?
|
| https://keet.io/
| eTomte wrote:
| Is Keet Open Source? Last time I looked into it (admittedly a
| few years ago) it was not.
| grishka wrote:
| "Now the end-to-end encryption will leak into the UX even more
| and you better like it"
|
| I'll say it again: E2EE will never become mainstream unless
| someone somehow manages to implement it such that it's completely
| transparent to the user while keeping all the features that
| people have come to expect from IM apps, like server-stored
| conversation history or support for multiple devices. By
| "completely transparent" I mean that the user doesn't have to do
| any extra actions whatsoever to make it work.
| joecool1029 wrote:
| I mean we're there for Signal. The parts that suck still are
| regarding access/retention of old messages which is an area
| Matrix is ironically slightly better about. But Signal we don't
| need to think about verification, at worst it says this asshole
| has a new identity and then I have to tell them I've reset my
| iPhone for the 4th time this week...
|
| Normal users do find retention important even if
| privacy/security minded users find value in ephemerality.
| BrenBarn wrote:
| Can you use Signal across multiple devices?
| joecool1029 wrote:
| Officially it supports linking other devices like their
| desktop app as a secondary. I currently use this to link
| into signal-mautrix on my matrix homeserver. This way I can
| access signal from multiple phones and multiple computers
| using a matrix client instead.
| BrenBarn wrote:
| But you still need one "primary" device and it has to be
| a phone, right? That's different from Matrix where you
| can have arbitrary devices that are all on an equal
| footing.
| grishka wrote:
| Yes. And, annoyingly, when you only use Signal
| occasionally, these desktop sessions expire. And you have
| to link again. And when you do, you end up with a gap in
| your conversation history because "security".
| int_19h wrote:
| Yes, and there's also a limit of max 5 linked devices.
| jeroenhd wrote:
| You can use Molly to put Signal on multiple devices or you
| can bridge it into Matrix or XMPP, but you'll always need
| to run on one "main" device.
| josephcsible wrote:
| If that's true, then E2EE will never become mainstream.
| Consider this scenario: "My phone got lost/stolen/broken, so I
| just got a new one. I haven't logged in to this app since I got
| my last phone, so I forget my credentials for it. I'll reset
| them through my email. What do you mean my conversation history
| is gone?"
|
| That's not really far-fetched. If you can get your conversation
| history back in that scenario, then so can the server operator
| so it's not real E2EE, and if you can't, then by your statement
| it won't become mainstream.
| grishka wrote:
| > If that's true, then E2EE will never become mainstream
|
| Yes? :)
|
| Given the choice, the vast majority of people would pick
| convenience over the kind of security that requires this much
| effort.
| BrenBarn wrote:
| I more or less agree. And I also agree with the other commenter
| who says this may mean e2ee will never become mainstream. I
| think a lot of e2ee enthusiasts don't realize that the
| overwhelmingly most important feature for a messaging system is
| "when I log in, I can see all my messages". If there is a
| chance of that not happening, you're going to lose a lot of
| users.
|
| I think there's the potential for a slight middle ground, but
| it would involve giving up a lot of the e2ee bells and whistles
| that privacy enthusiasts enthuse about (like perfect forward
| secrecy). You could image for instance a system where you have
| a single e2ee password and your data is encrypted on the server
| with that password. When you log in, you supply two passwords:
| your login password and your e2ee password. Then you have
| access to everything.
|
| This tends to irritate people on both sides, since you can
| still lose your messages if you forget your e2ee password, and
| your privacy guarantees are also weaker, since the e2ee
| password can be a single point of failure that allows someone
| to read your messages. But people already rely on this level of
| security in other contexts. For instance, some cloud backup
| solutions encrypt your backup with a single passphrase. People
| are okay with having one password to unlock _their entire hard
| drive 's worth of data_ but not with one password to unlock
| their chat history?
|
| I think it's worth exploring the space of e2ee solutions to
| find something that finds the balance between the levels of
| privacy and convenience that most users want. The thing is that
| existing apps that tout e2ee often do so to appeal to hardcore
| privacy advocates or people like dissidents in authoritarian
| states who are at risk of death if their messages are
| discovered. This level of security simply isn't a concern for
| the average person, and so they're not willing to take on the
| inconveniences that go along with it.
| monerozcash wrote:
| > E2EE will never become mainstream
|
| iMessage and Whatsapp are both mainstream.
| grishka wrote:
| Technically they are, but neither of them fits the strict
| definition of a E2EE messaging app, while _also_ still
| hurting the UX.
|
| Whatsapp is very insistent about backing up your messages to
| cloud services without encryption. To use it on desktop, you
| have to make everything go through your phone. And, afaik,
| you still can't transfer message backups between Android and
| iOS.
|
| Even disregarding the extreme gatekeeping, iMessage relies on
| Apple managing your encryption keys so there are no
| confidentiality guarantees. Apple can, at any moment, give
| themselves a key to decrypt your messages.
|
| Both Whatsapp and iMessage are proprietary, so it's also the
| case of "please trust us that we've implemented it the way we
| claim we did".
| monerozcash wrote:
| iMessage has worse UX than signal for key verification, but
| does support it. https://support.apple.com/en-us/118246
|
| >Both Whatsapp and iMessage are proprietary, so it's also
| the case of "please trust us that we've implemented it the
| way we claim we did".
|
| This is simply not true, any serious analysis of Signal
| would be performed on the binaries and not the source code.
| Having access to the source code does not make it any
| easier to discover well-hidden backdoors, but it is
| possible to exploit e.g. compiler behaviour in a way to
| create a backdoor that is essentially impossible to detect
| by reviewing source code.
|
| Access to source code might very well make it easier to
| discover non-intentional bugs, but does not solve the
| problem of trust.
| int_19h wrote:
| > iMessage relies on Apple managing your encryption keys so
| there are no confidentiality guarantees. Apple can, at any
| moment, give themselves a key to decrypt your messages.
|
| It relies on Apple _device_ managing your encryption keys,
| no? Which, yes, Apple can still access if it really wanted
| to simply by virtue of being able to push an iOS update
| that does that. But the same exact vulnerability applies to
| any app running on your iPhone.
| pfych wrote:
| I use Thunderbird as my main Matrix client since it's already
| always open on my PC and is Lightweight. Whenever I open Element
| or any other client (Nheko, etc.) they all complain about each-
| other being unverified.
|
| Clicking verify in any client does nothing. No popups in any
| other clients - doesn't ever seem to do anything. Sometimes
| Element will pop up a QR reader but there's no QR presented in
| the other clients. The UX around Matrix is a nightmare.
| beeflet wrote:
| I am in the same boat. It is ridiculous and shows no signs of
| improving.
| eredengrin wrote:
| Not sure how often they update these pages, but Thunderbird is
| still listed as beta on matrix.org clients page [0], and I
| remember trying it out some time back and it was indeed very
| beta (maybe not even beta). It didn't feel like it was getting
| much maintenance so I stopped using it. I think it's fair to
| expect bugs in beta releases.
| rclkrtrzckr wrote:
| I hope beeper will continue to work, as it's based on Matrix
| iirc.
| cowhax wrote:
| The problem with Matrix adaptation has always been E2EE, or
| rather, the annoying implementation of it
| kogasa240p wrote:
| Haven't used matrix for a few years now, last time I used it
| everything was a slow, buggy mess.
|
| >device verification
|
| Kinda weird because it's a protocol, but then again matrix is
| extremely centralized.
| teekert wrote:
| I love Martix/Element, and about the only thing I don't like is
| that I need moar features!
|
| We have a space with several rooms for our FOSDEM devroom, it's
| been working flawlessly, including for all our video calls with
| many participants. Thanx Element team!!
| mihaaly wrote:
| So compromising identities might happen - this seems to be a
| leading reason to verify devices - but can device verification be
| compromised too?
| teekert wrote:
| I always use my master key, verifying using other devices does
| not always work optimally in my experience. Maybe I switched to
| ElementX too soon...
| crossroadsguy wrote:
| I am not sure the founder is reading this. I tried googling but
| couldn't find it - I recall the hn handle being something like
| Atheon. Not that hn sends mention notifications.
|
| Matrix is something that had my eyes lit after years or being
| burnt/disappointed by communication apps (Signal included). I had
| converted/migrated a lot of people to it (I mean of course they
| didn't "convert" but they had it and were replying to me) from a
| country where WhatsApp is essentially "basic need" today - along
| with water, air, food, and shelter and that too in an era when it
| was not even stable. After that I just didn't know what the hell
| happened. Matrix, Vector, Riot, Element - things just kept
| happening. App was never an end user app and it became very clear
| that it was not the intention either. To be honest it didn't look
| like a replacement for something like Slack or something like IRC
| either. It was trying to become something which it seemed/seems
| has no end goal or destination i.e a clear roadmap. As if the
| goal is to develop cool features and just put them haphazardly
| together which I am afraid often results in something Mary
| Shelley wrote.
|
| I still login from time to time and I don't understand what is
| happening. Something I see this notification, something that,
| sometimes I see there's a message pending, sometimes I see I have
| a chat recovered (old/stale; because there's no one I know uses
| it anymore), sometimes I see a certain chat is not recovered
| because some verification or decryption (or something) failed,
| sometimes I see (or understand it) that I might another active
| and verified device to recover certain messages. I had created
| some groups and of course they remain abandoned - but no, few og
| them were filled were porn and the kind of some was scary because
| that vector/riot/element account is connected to my real ID
| including the email and I was scared shitless. I tried deleting
| them but I couldn't. Next time I will try harder or just try to
| make it private after kicking everyone out. I will still keep the
| account. Never say never :)
|
| I sadly have moved from writing enthusiastic to sad to
| disappointing comments to not even paying attention to it when
| there's a Matrix/Element news now. I think I don't even notice
| it. I think that's the worse kind of eventuality in this context.
| Anyway, I wish you all luck and I am sure you all know what you
| are doing.
| tcfhgj wrote:
| > Matrix, Vector, Riot, Element - things just kept happening.
| App was never an end user app and it became very clear that it
| was not the intention either.
|
| Element X definitely is.
| adham-omran wrote:
| Last time I used Matrix for our internal team notifications were
| beyond broken and we moved to Zulip, verification and
| authentication were also very funky at the time, I don't dare to
| try it again.
| goku12 wrote:
| There seems to be a lot of confusion regarding what verification
| is all about. I'm going to list out what it means, based on my
| reading of their documentation[1] and on what worked for me. It
| includes some essential preparations that you _MUST TAKE_ if you
| have access to your account. This is to ensure that all your
| devices are verified, that they all have access to all encrypted
| messages and that you don 't ever get fully locked out.
|
| DISCLAIMER: I have no direct experience with Matrix or Element
| code base. I have no affiliation with them either. So this isn't
| official and a few errors can be expected. Please let me know if
| you notice any. I will keep this corrected for as long as I can.
| Otherwise I'll add the errata as child comments.
|
| 1. Matrix has _TWO levels of authorized access_.
|
| 2. The first level is where you enter your regular username and
| password, that's unique to your homeserver (like matrix.org). It
| looks like OIDC/OAuth2 to me. On being authenticated at this
| level, your client (Element, Fluffy, Cinny, etc) is able to
| access the messages meant for you. At this stage, you're able to
| read any unencrypted messages. Most community chatrooms are
| unencrypted by choice.
|
| 3. The encryption used for your encrypted messages is end-to-end.
| Their encryption keys are named 'room keys' in Element (there are
| several of them). They are not directly available to your
| homeserver (otherwise, it wouldn't be end-to-end). Similarly,
| there seems to be an 'Identity key' (presumably a cryptographic
| private key that makes you the owner of the account and is needed
| for some account operations). This key is also not directly
| available to the homeserver.
|
| 4. The client app just logged in and the server doesn't know your
| room keys or ID keys. They're known only to your other clients.
| So now you need to transfer them from those clients to the new
| client without divulging them to any servers in between. Once
| that's done, your new client will be able to decrypt all your
| encrypted messages and join those discussions.
|
| This process of transferring your _room keys_ and the _ID key_ to
| your new client is the second authorization step known as '
| _Verification_ '. (I presume it's called verification because
| your new client can now prove its authenticity using your ID
| key.)
|
| 5. Verification can be done in _three_ different ways. The first
| two are manual methods and are rarely used. We will discuss these
| two later. The other is using a 'verification request'. This is
| straightforward. Your new client requests the already verified
| clients attached to your account for your room and ID keys. Any
| verified client can respond. However, it needs to first verify
| that your new client is really yours, and not someone who used
| your leaked password or hacked your account. To do this, the
| clients currently offer you two methods - one using a QR code and
| the other using a sequence of icons.
|
| If you select QR code, your verified client will show you a QR
| code that you need to scan with your new unverified client. Since
| it proves that both clients are in the possession of the same
| person, the verified client then proceeds to transfer the keys to
| the new client, finishing the verification. Now if you chose the
| Icon sequence instead, then the verified client creates a random
| sequence of icons that it sends to the new clients. Then both the
| clients display it to the user. If the user accepts on both
| device that the icon sequences are identical, it's the required
| proof that both clients are with same person. The rest of it is
| the same as before.
|
| 6. So far, so good. If you were able to complete till step 5, the
| new client is verified and now you can carry on with your
| business. Now we address the situation of what happens _if you
| are not able to do any of these_. Just assume that all your
| clients got logged out together for some reason (yes, it has
| happened before). Now none of your clients or the server has any
| of the room keys and the ID key needed to prove your ownership
| (crypto authn) or access your encrypted messages, even after you
| log back in. The only solution is to load the room keys and ID
| key from a backup. This is why _it is IMPORTANT TO BACKUP your
| room and ID keys_.
|
| 7. There are _two ways to backup the room keys and the ID key_.
| These two methods are also the two manual methods of verification
| that I mentioned above. The first method is to back up the keys
| on the homeserver itself. It 's convenient because all your
| clients can access them at any time and keep the room keys
| updated as they change or new ones are added. This feature is
| called 'Key Storage' in Settings/Encryption tab of Element. It's
| enabled by default. ALWAYS keep it enabled.
|
| You may be wondering how it can be end-to-end encryption if the
| private keys are stored on the homeserver itself. If you're, then
| you're correct. They are stored in encrypted form on the server
| key storage. The decryption keys for that is available only to
| the clients. So while the server holds the keys, it cannot access
| any of them.
|
| 8. Here is your first opportunity to do something about
| accidental losses. The decryption key for the key storage can be
| downloaded and preserved in a secure manner. Perhaps write it
| down on a paper or put it in the password manager. This key is
| called the ' _Recovery key_ '. You can download or change it from
| Element's Settings/Encryption tab. _ALWAYS BACKUP YOUR RECOVERY
| KEY_.
|
| You can use the recovery key instead of the QR code or the icon
| sequence to verify your new clients. There are two differences
| from the previous method. The first is that you can enter the
| recovery key directly into the new unverified client. The
| verified clients are not needed here. The second is that this is
| _possible even if all your clients gets logged out_. Again, this
| is why it 's very important to BACKUP YOUR RECOVERY KEY!!
|
| 9. Besides setting up server key storage, you can take one
| additional step. This is the second manual method of
| verification. You can download and _backup all the room keys and
| your ID key on your local system_. This option is available as
| the 'Export keys' button on the Settings/Encryption tab. When
| you do so, you'll be asked for a password. This password is used
| to encrypt the file with all those keys, so that they don't sit
| unencrypted on your disk. This file can be backed up as such, but
| you can encrypt it again if you prefer.
|
| You can use these keys also to verify your account. You'll need
| the above password to decrypt the keys file. However, this method
| still has one big _CAVEAT_. I suspect that the keys file need to
| be updated regularly, since there will be new keys when you join
| rooms. So if you use this method to validate, it 's likely that
| your client won't be able to decrypt the rooms/messages for which
| it doesn't have the copy of their key. But this is still worth
| doing, because it contains your ID key which can be used to
| verify all your devices again as a last ditch measure (if your
| homeserver happens to quit or something).
|
| 10. Now let's just say that you're a careless ### who didn't do
| any of the above. You still have the option to nuke it! That is
| to _Reset your cryptographic identity_ from Settings /Encryption.
| I presume that this just discards all your previous keys and
| creates a new private ID key. Since all the clients can now
| access this key, your account is verified again. But you will not
| be able to access any of your previous encrypted conversations.
| And the homeserver helps you along by discarding all your
| previous conversations, room subscriptions and settings. So now
| you're left with a cleanly empty account. But hey! You have your
| verified account back!
|
| So, in summary:
|
| 1. Always verify all your clients
|
| 2. Setup server key storage (it is enabled by default, don't
| disable it) and backup the recovery key
|
| 3. Backup the room keys and ID keys on your local system. Use it
| for recovery/verification only in the worst case
|
| 4. Don't forget the password you used to encrypt the above file
| (just sayin)
|
| NOTE: I intentionally left out some crypto details from the above
| (like session keys) to avoid making it any more complex. If
| you're unhappy with those omissions, please just leave a comment.
|
| [1] https://element.io/en/help#encryption
| Dilettante_ wrote:
| Can't wait for a bug to un-verify me on both my devices and lock
| me out of my account.
| lysp wrote:
| I'm pretty sure you get recovery keys with it also.
| sschueller wrote:
| I want to switch to SimpleX Chat[1] but at the moment there are
| issues with battery usage on android devices because of the way
| notifications are done. I hope this[2] or some other solution get
| merged soon even if there is a slight impact on anonymity.
|
| [1] https://simplex.chat/
|
| [2] https://github.com/simplex-chat/simplex-chat/pull/6205
| jbaiter wrote:
| I tried implementing a Matrix bot a few months back, and it was
| an absolutely miserable experience, since Device
| Verification/E2EE was not working with any of the available open
| source Python implementations I found.
|
| I then stumbled upon their internal Rust SDK[1] that they use for
| Element X, which is actually quite nice, and even has FFI
| bindings for Python and Kotlin[2]. Unfortunately the
| documentation was really lacking at the time. I managed to put
| something together with the help of an LLM and the source code
| and examples to find my way around the various APIs, and it
| actually works with emoji verification and E2EE (although there
| are weird bugs around synchronization, but that's probably just
| an API misuse on my end).
|
| It seems they've improved the documentation since and even
| provide a reference client[3] to see how things work.
|
| [1] https://github.com/matrix-org/matrix-rust-sdk
|
| [2] https://github.com/matrix-org/matrix-rust-
| sdk/tree/main/bind...
|
| [3] https://github.com/matrix-org/matrix-rust-
| sdk/tree/main/labs...
| photios wrote:
| Conspiracy theory time...
|
| Matrix is the Firefox of chat apps. Castrated on purpose and kept
| around as a "see how much worse than WhatsApp things can really
| be!"
| irusensei wrote:
| I had a more pleasant experience with SchildiChat hosted on a web
| server than the desktop Element clients.
|
| I don't like the way groups/chatrooms are displayed to be honest.
| Its confusing. It feels like its trying to get away from the
| "server room/#somechat" model that works well with IRC and even
| with trendy current products like Discord.
| pqs wrote:
| I've been using Delta Chat with a lot of success. It is easy, it
| works, bots are easy and the concept is improving. They even plan
| to have forward secrecy. So, give it a try. If you explored it a
| long time ago, try again, many things have improved in that
| ecosystem.
| kuon wrote:
| I really want to love matrix but it always turned bad/broken at
| some point. I switched to XMPP. No issue ever, but the clients
| are not very good.
| jones89176 wrote:
| FYI: here are the videos of the latest matrix conference: [1]. I
| think there's a lot of interesting stuff going on!
|
| also, instead of hosting your own server or using some (more or
| less well-financed) public servers, you can simply throw some
| money at [2] to pay for hosting for your group of friends or
| family or whatever. (not affiliated, but I like the idea)
|
| [1] https://media.ccc.de/b/conferences/matrix-conf [2]
| https://etke.cc/
| superkuh wrote:
| This basically means that Matrix will stop working for my parents
| and other family: the only people I use matrix for. We started
| during the pandemic for the video chat element. But
| Riot.im/Element.io changes to the homeserver over these many
| years have made it so none of our accounts properly verify. I
| can't even get my account to properly verify and I'm a huge nerd.
| We put up with it because of inertia and chat still working fine.
| But this? I guess it's the end.
|
| Riot.im/Element.io really knows how to shoot themselves in the
| foot.
| chrisjj wrote:
| > This security update will give you assurance that when you
| receive a message from a contact, you can effortlessly assume
| it's really from them.
|
| Here's the thing. You can already! Whether you should or not.
| nottorp wrote:
| From an outsider's point of view, what is this "verifying"?
|
| Because it sounds like "we'll put them in a database so we can
| sell it" to me...
| tcfhgj wrote:
| cryptographic process to poof that the devices you use in fact
| belong to you (as cryptographic identity)
| wkat4242 wrote:
| Ugh.. I loved Matrix but I'm starting to hate the way they force
| these things through. Also last month they removed the categories
| (People, Rooms, Favourites) from Element Web just like that.
| Making it very hard to use as I use it. I had to roll back to an
| older version. They seem to be focused on whatever commercial or
| consumer experience but they are ruining it for power users.
|
| My matrix server isn't even publicly accessible and users can't
| sign up. I don't federate with the network. So these issues are
| irrelevant to me. There should still be a way to turn it off.
| Because many of the bridge bots I run can't verify.
___________________________________________________________________
(page generated 2025-11-20 23:01 UTC)