mastodon - Link to source
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…

Matrix 2.0 Is Here!

Matrix, the open protocol for secure decentralised communications
Matthew Hodgson (matrix.org)
in reply to The Matrix.org Foundation

mastodon - Link to source

keschi Θ

Mentioning Bluesky here as an example of a federated network, when it currently does not federate at all (why forgo the mention of the ActivityPub Fediverse?), and calling a bunch of uncompleted MSCs "Matrix 2.0" really does disillusion me about the Matrix group of protocols. What the fresh hell is this?
This entry was edited (10 months ago)
in reply to keschi Θ

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.

@keschi Θ
in reply to The Matrix.org Foundation

mastodon - Link to source

keschi Θ

Look, I am not discounting the improvements here at all. Especially Sliding Sync! A great thing to have.

But until it is part of the protocol, officially, it isn't.

And that editorial choice makes no sense, again, considering that Bluesky is not federated or decentralized at all currently, only could be made to be so in theory!

This entry was edited (10 months ago)
in reply to keschi Θ

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!

@keschi Θ
in reply to 183231bcb

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 πŸ˜…

@183231bcb
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)

MSC2530: Body field as media caption by tulir Β· Pull Request #2530 Β· matrix-org/matrix-spec-proposals

Rendered Implementations: Beeper Desktop/Android/iOS (both sending and rendering) SchildiChat Android Next (rendering: SchildiChat/schildichat-android-next@e65d7cb + SchildiChat/matrix-rust-sdk@d4...
GitHub
in reply to The Matrix.org Foundation

mastodon - Link to source

Midgard

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.

⇧