hydrogen-web VS matrix-spec-proposals

Yes! See https://github.com/vector-im/hydrogen-web/releases/tag/v0.3....

I think you're right, the experience of element on Android isn't great, I use mostly the web app that seems to get more attention and doesn't feel as sluggish. But to bring some hope, I think this will change soon-ish. The Matrix ecosystem has been in kind of a MVP state for several years, the focus was more on the protocol/APIs and not so much on the performance that translates in user experience. But efforts are on the way to improve all of this, on the client side there are several projects working on other clients that might be more performant, including the company behind Element, they have a work-in-progress lightweight client https://github.com/vector-im/hydrogen-web On the server side most servers run Synapse which is written in Python without much though for performance or scalability but there are faster/lighter alternatives on the way like Dendrite or Conduit. It also doesn't help that most accounts are in the same overcrowded Synapse server(matrix.org), overtime it should become more common to have more alternatives and people even running their home server embedded in their device.

It’s using normal Matrix olm/megolm double ratchet encryption.

To track the identity of who you’re talking to we can do TOFU and/or normal out of band Matrix verification as per https://github.com/vector-im/hydrogen-web/issues/518 - but this isn’t yet exposed in Chatterbox. We’ll get it added, as without verification you obviously can’t spot a MITM.

You can use this web app to access the chat. Join the #general channel. https://github.com/vector-im/hydrogen-web

Hydrogen's installation process was pretty much exactly the same as Element, the github README was just a lot less specific and there is no config file so you have to edit the HTML directly to get it to point to your site instead of matrix.org by default.

> I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach.

I've got plenty of React & front-end experience and vastly prefer a thin library on top of the DOM than something like React, also for large applications. React is ok if all goes well, but when you have to debug or profile something, all the complexity behind the scenes occludes what you are looking for. Most of the time, people want JSX so you need a transpiler. Also keeping up with changes in new React releases seems like a lot of lost time.

I've been building [1] without a transpiler and just a 600 lines template library (see [2]), and it has been such a breath of fresh air. The fact that there is so little code between you and the browser makes it very easy to see what is going on. Call stacks of max around 15 frames.

It sounds like you are comparing React to jquery code without components, and I justed wanted to highlight that DOM APIs have evolved since those days, and that you don't need a library like React to structure your code.

React has popularized good ideas in front-end development, like components, but I think the complexity cost of a virtual DOM is often underestimated.

1: https://github.com/vector-im/hydrogen-web/

Matrix's resource utilisation is improving very rapidly at the moment.

Dendrite is still in beta, and hasn't been tuned that much yet, but every release has had a substantial improvement. In other words, if you're not using today's release (0.3.5) you're on stale data. For context, dendrite.matrix.org (running 0.3.5) has ~5K users on it, and is in ~3K rooms spanning 162K users... and its RAM usage is stable at 488MB (occasionally spiking to 2GB during traffic spikes). This doesn't seem unreasonable at all for a chat server of that size. Meanwhile, Synapse has been steadily improving too.

On the client side, Hydrogen (https://hydrogen.element.io, https://github.com/vector-im/hydrogen-web) is our next-gen client implementation, which gives you full E2EE, complete with backup (I have no idea what Durov is banging on about in the OP) - and uses 14MB of RAM for an account in 3,000 rooms spanning 350K users (i.e. my personal one). This is an 100x improvement on Element Web which uses 1.4GB for the same account, although there's also a lot of optimisation that can be done there too.

If I was going to criticise Matrix, I'd focus more on the fact that there are still a lot of papercuts on Element's UX which are holding us back. We're painfully aware of this though and are trying to fix as rapidly as we can.

it’s a entirely new codebase; probably best way to visualise progress is to look at the contributor graphs at https://github.com/vector-im/hydrogen-web

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