Verifying your Matrix devices is becoming mandatory

Original Article ↗ Hacker News Discussion ↗

What “verification” actually is

  • Not ID/KYC or device attestation; it’s cryptographic device linking.
  • Matrix has two layers:
    • Login to homeserver (username/password, like OAuth).
    • Separate cryptographic identity + room keys for E2EE.
  • “Verification” is how a new device proves it belongs to your cryptographic identity and receives your encryption keys.
  • Main methods:
    • Compare emoji sequence on old + new device.
    • Scan a QR code between devices.
    • Enter a recovery key (or exported key file) that decrypts the key backup stored on the server.

What the change does

  • Element (and, via spec, other clients) will start refusing to send/receive E2EE messages from unverified devices.
  • Purpose: stop unnoticed “extra devices” (e.g. logins from stolen credentials) from silently reading encrypted conversations, and reduce “cannot decrypt” errors by forcing correct key flows.

User experience: polarized feedback

  • Some report verification as fast and reliable for years, preferring it to Signal/WhatsApp because it’s not tied to a phone number and can be recovered from a master key.
  • Others describe it as a “nightmare”:
    • Cross‑client verifications failing or looping.
    • Devices randomly losing verified status.
    • Recovery keys/passphrases UI confusing or broken in some Element versions.
    • Popups for long‑gone devices that can’t be cleared.
  • Casual/infrequent users and families are especially affected; several say this change will effectively lock their relatives out.
  • Element X is seen as cleaner by some, but missing features, buggy verification flows, and unified-push requirements are pain points.

Impact on ecosystem (clients, bots, and servers)

  • Simpler or experimental clients and bots often don’t implement verification, so they may be unable to participate in encrypted rooms once this is enforced.
  • Admins of small private homeservers (no federation, trusted users) want a way to disable mandatory verification; otherwise bridges/bots break.

Broader Matrix critiques raised

  • Protocol seen as complex, “eventually consistent JSON DB” rather than focused chat, making UX fragile.
  • E2EE praised but metadata and room names remain unencrypted; some argue privacy is weaker than Signal’s model.
  • Persistent complaints about moderation, especially image/CSAM spam on large public servers, and the lack (or slowness) of tools like per‑room media restrictions.

Alternatives discussed

  • XMPP (Prosody, Snikket, Movim), IRC (+bridges), Signal, SimpleX, Delta Chat, Zulip, and Mattermost are mentioned as options with different trade‑offs in UX, features, and privacy.