matrix-spec-proposals VS rust

Not only are they actually very closely linked, in that Element operates matrix.org, but to a new user (told to try Matrix -- what is this Element thing?) there's no difference.

I onboarded a family member onto my Matrix server with FluffyChat as the client. This person is a power user, fairly technical, yet still refers to the chat as "FluffyChat" and although I've explained several times that choosing FluffyChat was maybe a mistake and they should use Element, it never seems to really click that multiple clients are possible.

And really, they aren't possible. They have different subsets of features.

If you want to see a trash can fire, just try to follow the discussion for adding custom emoji to Matrix: https://github.com/matrix-org/matrix-spec-proposals/pull/195...

it's been going on for years. It's a feature the competitors have had for half a decade, as long as this discussion has been ongoing. I've been watching this issue for half a decade thinking "surely they'll decide on something" but mostly all I've been convinced of is this: Matrix is design by committee in all of the worst aspects and at every level of design. If anything gets done at all, it's a convoluted mess, and it's a miracle that it even happens.

I wish community software developers would focus their attention.. somewhere else.

So Matrix also has account portability (almost) - https://github.com/matrix-org/matrix-spec-proposals/blob/keg... and https://github.com/devonh/matrix-spec-proposals/blob/cryptoI..., implemented in Dendrite. Unfortunately dev is paused on it currently thanks to lack of $ though.

The AP approach (prioritising portable identities over portable account data) is cute though, and perhaps we should have prioritised that as an alternative to fullblown cryptographic IDs & account portability.

Luckily, it doesn't matter what individuals expect. There is written documentation on what the foundation is supposed to do or not to do: https://github.com/matrix-org/matrix-spec-proposals/blob/mai...

Notably, "Code Core Team members must arrange their own funding for their time", which I understand as such that the Foundation does not pay directly the developers (same as other standards organizations like IETF).

Main tasks of Matrix.org Foundation is maintaining the spec, documentation, owning IP, promotion and the matrix.org home server. The home server is "generously hosted" by UpCloud (i.e. is not using New Vector EMS), at least according to the matrix.org website.

Looking again at MSC1779, I noticed it says that one function of The Matrix.org Foundation is "Owns the copyright of the reference implementations of Matrix (i.e. everything in https://github.com/matrix-org). By assigning copyright to the Foundation, it’s protected against New Vector ever being tempted to relicense it." That protection apparently wasn't very effective, but also notably, New Vector and their leadership clearly have shown to not stand behind the goals of the Foundation. As the leadership of New Vector is also part of the leadership of the Foundation, I see some huge potential for COI here.

The main remaining Nebuchadnezzar issue is mitigating server-controlled group membership. The first step has been to kill off the 1st gen E2EE implementations, which were responsible for the implementation vulns found by RHUL - and we should hopefully conclude that next week by moving everything into the matrix-rust-sdk crypto create implmentation: https://github.com/vector-im/element-web/issues/21972#issuec... is the tracker.

Then, we can address the harder server-controlled group membership issue in one place. First step will be to improve device verification & trust so that trust is the default, not the exception, to make it easier to spot and warn about unexpected devices in the room. The full solution is then either MSC3917 (https://github.com/matrix-org/matrix-spec-proposals/blob/fay...) - or potentially to switch everything to MLS.

We're working on MLS anyway in parallel to RHUL mitigation work; you can see the progress at https://arewemlsyet.com, and it's looking good.

I'm guessing you're not interested in doing a podcast on "yay we converged our crypto implementations on a single robust Rust implementation so we can fix the remaining bugs in one place", but as soon as the server-controlled group membership thing is solved we'll be in touch. Work has also gone much slower than hoped on this, thanks to the joys of funding open source.

https://github.com/matrix-org/matrix-spec-proposals/blob/keg... is how we’re doing it, and it’s being implemented currently in Dendrite.

Matrix already has key-based identity in the works at https://github.com/matrix-org/matrix-spec-proposals/blob/keg... (and implemented in Dendrite at https://github.com/matrix-org/dendrite/pulls?q=is%3Apr+is%3A...). Matrix is set up to let folks go wild and change fundamentals like this; basically every Matrix Spec Change (MSC) is a small fork, which then gets merged into the main spec if it can be proven to work well in the wild.

Gitter seems to have moved to being a Matrix instance (or maybe it always has? it didn't look like Matrix when I used it circa 2016), but matrix feels half-baked and is just a bunch of hacks put together. For example

- Can't "mark all as read" on a space. probably because rooms within a space are only tangentially related,

- No custom emojis or sticker packs (their proposal for this is to create rooms to house custom emojis/sticker packs[0])

Not a great bet to go to keybase with the Zoom acquisition https://news.ycombinator.com/item?id=28814210

0: https://github.com/matrix-org/matrix-spec-proposals/pull/195...

We’re currently working on account portability (https://github.com/matrix-org/matrix-spec-proposals/pull/401...) and experimenting with glueing bluesky style DIDs onto it (so as to provide DMs for bluesky via Matrix, should they want them)

slow moving but there is discussions https://github.com/matrix-org/matrix-spec-proposals/pull/1998

> There are online Rust compilers and interpreters already if you just want to rapid prototype and develop ideas in Rust

You are responding to one of the key developers of Rust early on[1], who's been working with the language for 14 years at that point.

[1] https://github.com/rust-lang/rust/graphs/contributors?from=2... and he's still #16 in commits overall today, despite almost no activity on the rust compiler since 2014.

If you haven't dipped your touch-typing fingers into Rust yet, you really owe it to yourself. Rust is a modern programming language with features that make it suitable not only for systems programming -- its original purpose, but just about any other environment, too; there are frameworks that let your build web services, web applications including user interfaces, software for embedded devices, machine learning solutions, and of course, command-line tools. Since a custom GitHub Action is essentially a command-line tool that interacts with the system through files and environment variables, Rust is perfectly suited for that as well.

Here's an example of someone citing a disagreement between CRT and shell32:

https://github.com/rust-lang/rust/issues/44650

This in addition to the Rust CVE mentioned elsewhere in the thread which was rooted in this issue:

https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html

Here are some quick programs to test contrasting approaches. I don't have examples of inputs where they parse differently on hand right now, but I know they exist. This was also a problem that was frequently discussed internally when I worked at MSFT.

    #include 

> instead of choosing a certain numbered version of the random library (if I remember correctly) I let cargo download the latest version which had a completely different API.

Yeah, they didn't follow the instructions and got burned. I still think that multiple things went wrong simultaneously for that experience. I wonder if more prevalent uses of `#[doc(alias = "name")]` being leveraged by https://github.com/rust-lang/rust/pull/120730 (which now that I check only accounts for methods and not functions, I should get on that!) so that when changing APIs around people at least get a slightly better experience.

Almost fixed the compiler: https://github.com/rust-lang/rust/pull/123325

Rust: A secure, efficient, and modern programming language (omitting ten thousand words). You can simply follow the installation instructions provided on the official website.

Recently did something similar in Rust but for generating SVGs. We've adopted it for snapshot testing of cargo and rustc's output. Don't have a good PR handy for showing Github's rendering of changes in the SVG (text, side-by-side, swiping) but https://github.com/rust-lang/rust/pull/121877/files has newly added SVGs.

To see what is supported, see the screenshot in the docs: https://docs.rs/anstyle-svg/latest/anstyle_svg/

We strongly believe in Rust as a powerful language for building production-grade software, especially for systems like ours that run alongside Kubernetes.