matrix-spec-proposals VS matrix.to

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

Happy to see this on HN =). Lunatik’s main author here. AMA.

Please feel welcome to join us on Matrix [1] as well.

[1] https://matrix.to/#/#lunatik:matrix.org

There is this list of 15-minute bugs that should be easy to tackle https://bugs.kde.org/buglist.cgi?bug_severity=critical&bug_s...

Also strarting on smaller KDE applications is usually a great way to start, For example the Plasma widgets/applets or KDE games or educational applications.

You can join the New Contributors char room on Matrix to get help with starting out https://matrix.to/#/#new-contributors:kde.org

There's also https://matrix.to/#/#review-requests:nixos.org

Hi, I'm the Thib person mention in this article, and I agree that QA is super important. I can mostly talk about matrix.org, since I have little power over the Element clients. Disclaimer though: I'm technically employed by Element (to make paperwork simpler since I'm France-based, Element has an entity in France, and the Foundation is UK-based), but I'm working for the Foundation full time.

This kind of article is super valuable since it gives us the perspective of a new user. I opened https://github.com/matrix-org/matrix.org/issues/2178 to translate the gripes mentioned in the issue into actionable items for us. I took action on the most urgent one (updating the Try Matrix page), but want to take the time to go beyond the surface symptoms and address the root cause of the other gripes.

On the Foundation side, we're a small but mighty team of four. The website is currently maintained part time by me and a volunteer who is doing an excellent job at it.

As I wrote recently in a blog post "Tracking what works, not people" (https://ergaster.org/posts/2024/01/24-tracking-what-works/), I would love to have the resources to conduct user research and user testing on the website but I unfortunately don't. We deployed privacy-preserving analytics to see where people drop and what confuses them. It's not nearly as good as proper QA and user testing, but that's what we can afford for now.

Overall I'm grateful to the author for documenting their frustration, and even more grateful for reacting constructively to our responses and integrating them in the blog post! One of the strengths of open source is to find and address issues collectively. I consider this blog post to be a good open source contribution.

If people around believe in our mission and want to help us with their brainpower, I invite them to join our "Office of the Matrix.org Foundation" room: https://matrix.to/#/%23foundation-office:matrix.org

For those aligned with our mission and who want to support us financially, the https://matrix.org/support/ page should give you all the information you need to help us out.

https://matrix.to/#/#openbao-general:chat.lfx.linuxfoundatio...

Hi all,

This project release is a long time coming. It was a big uphill battle, and by far my largest endeavor so far. I built it for Sandstorm because I believe in Sandstorm's model, and I wanted to show that there's still life and potential in it. If you're inspired, joining our OpenCollective would be really helpful: https://opencollective.com/sandstormcommunity (keeping in mind that Sandstorm has now moved from its original leadership to a community project https://sandstorm.org/news/2023-11-03-from-io-to-org).

You can also join our mailing list or connect on the fediverse: https://sandstorm.org/community (The IRC link is outdated, we've effectively moved to Matrix for now due to the libera.chat split: https://matrix.to/#/#sandstorm:libera.chat)

Also: I'm open for hire! You can see some of my skills in putting things together in this blog post. I'd love to work in something FOSS or OSM related, but not a requirement. I mostly do Python and Golang, with a bit of Haskell under my belt. Other projects and resume here: https://github.com/orblivion/me

I really appreciate you sharing your concerns, and for all the hope and energy you've put into Matrix to date. Very much to your point, we're not yet in a state where I recommend Matrix to friends and family. Right now I only use it with people in FOSS and other circles where folks are a little more patient with the tech.

Only time will tell, and of course I'm biased as the Matrix.org Foundation's Managing Director, but I think there's good reason to remain hopeful:

The spec continues to evolve with major improvements expected in feature set and performance in the next year as we get to the 2.0 spec release, the Foundation is staffing up and beginning to fundraise, we're on the cusp of holding our first ever community elections to seat a Governing Board, and adoption has continued doubling on an annual basis.

I invite you and anyone else who is invested and/or concerned to join us in the Foundation's new office room – it's a way to get a view into ongoing activities, ask questions, provide direct feedback, and celebrate all the little wins on our way to collective success: https://matrix.to/#/#foundation-office:matrix.org

Cool! Just in case you haven't come across this, we've got a (rather quiet lately) chat that might be useful.

https://matrix.to/#/#usb-rs:matrix.org