Skip to main content


It's official - Matrix 2.0 implementations are here and ready for mainstream use! πŸŽ‰πŸ₯³πŸŽŠ Come watch the keynote from The Matrix Conference and learn about the joy of instant sync ⚑️, next-gen auth πŸ”, native VoIP 🎦 and Invisible Crypto πŸ‘»: matrix.org/blog/2024/10/29/mat…

reshared this

in reply to The Matrix.org Foundation

congratulations!

> what might Matrix 3.0 bring? (…) Could it be switching to #MLS (or Decentralised MLS) for encryption?

That would be absolutely amazing as a top priority for v3

#MLS
This entry was edited (1 year ago)
in reply to Erlend Sogge Heggen

@erlend Right?! We look forward to seeing what emerges as folks explore what that major version release could signify.
Unknown parent

mastodon - Link to source
The Matrix.org Foundation

@kescher Thanks for sharing your concerns. Our spec process requires proof and implementation before things get merged in, and we're not going to be shy about celebrating when a meaningfully improved UX, based on spec proposals that have stabilized and are on track for merging, is becoming available.

And we're ActivityPub-first in our approach to social in line with our values, but AP hasn't made the news recently in the same way – thus the editorial choice.

in reply to The Matrix.org Foundation

For me, the biggest problem with Matrix ecosystem right now are servers not cleaning after themselfs.

I can wait for some features, but in the meantime servers I have struggle to survive because of Synapse's state_groups_state infinite grow while Condu(wu)it/Dendrite seems to be too risky bet because of unsure development speed.

in reply to { Didek }

@didek Yeah, that's a good point about resource use. The server side of the ecosystem is promising but we'd like to see more of those server implementations hit maturity.
Unknown parent

mastodon - Link to source
The Matrix.org Foundation

@183231bcb Glad to hear you're having a good experience there! And thanks for raising that – aside from availability in that mobile client, the improved UX is available in the develop/nightly builds of one web/desktop client.

That said, it's fair to say that's many people aren't going to use those at this time.

Given the length of the road we're traveling here, we're eager to celebrate incremental progress where we can πŸ˜…

Unknown parent

mastodon - Link to source
The Matrix.org Foundation

@kescher Genuinely, thanks for sharing your thinking here. We've definitely heard from folks who pay close attention to the spec that the 2.0 comms centered on implementations land wrong for them.

No doubt we need to calibrate how we communicate about these things... Relatedly, we've been very glad to hear that our Governing Board is interested in helping us think about our outbound communications strategy!

Unknown parent

mastodon - Link to source
The Matrix.org Foundation
@tom Thank you, taking a look at that now!
Unknown parent

mastodon - Link to source
The Matrix.org Foundation
@Laelia captioned images are coming very soon: github.com/matrix-org/matrix-s…. custom emoji is a rats nest but we are doing our best to prioritise it (although foundations comes first)
in reply to The Matrix.org Foundation

are there instructions out there for migrating from the sliding sync proxy to the native sliding sync?
in reply to amd

@amd clients should move over to native sss automatically, and once the ss proxy logs are quiet you can turn it off.
@amd
in reply to The Matrix.org Foundation

but how many new side channels did you create / knowingly leave in place?
in reply to feld

@feld none to our knowledge, and the libolm ones weren’t exploitable in practice (hence not prioritising them).
@feld
in reply to The Matrix.org Foundation

If a friend loses her device again without having recovery, she has to abandon her account. Better to be upfront about this than to leave her in confusion as to why she's "banned", so a client should say:

> You've successfully signed in. Before you can send and receive messages with this device, you need to validate it using another device or a recovery passphrase.
> If you lost all devices where you were signed in and do not have a recovery passphrase, you should create a new account.

in reply to Midgard

The better, user-friendly solution would of course be to simply couple the authentication and the crypto. So that signing in *is* validating the device.
This entry was edited (1 year ago)
in reply to Midgard

@midgard
I wonder if there are security reasons for doing it this way, or else I see no reason to ask for both authentication and crypto. If this improves security then I can understand, I usually have a backup of my keys so thankfully I've never lost any messages yet.
in reply to Rokosun

There are several messengers where the authentication is embedded within the E2EE, such as tox.chat/, briarproject.org/ and simplex.chat/. They didn't see a security problem.
This entry was edited (1 year ago)
in reply to Midgard

@midgard

Do these messengers store all of the messages in the server like element does? If the messages are only stored on the client device then they don't need any keys to restore old messages from the server and decrypt them. In Signal messenger for example you'll loose all your chats unless you manually backup, and this backup will have a separate key that you need to enter when importing it into a new device - kinda like what element does.

⇧