I’m using Element. I haven’t noticed it being particularly slow and I am in a lot of rooms. But I’m also not a heavy user on my phone, most of my usage is desktop.

What slowness are you noticing? Browsing the interface, sending, receiving? Something else?

If you are on matrix.org then likely yes. It is well know for being slow. As the biggest homeserver by a good margin it really struggles in the performance department. The operations you describe are all those that need to wait on the server.

If you want the best experience the best option is to get a dedicated server. There are various hosts that you can buy from (such as Element https://element.io/personal-plans) or you can run your own.

However it is also possible to find other public homeservers and many are free but I can’t attest to their performance as I haven’t tried them.

my feeling is that it is reasonable to have the sender of the message set the terms here

This is fundamentally impossible thanks to the analog loophole. The receiver can always copy down the message to a notepad, or just remember it. Exposing this mutual agreement is staying honest and make sure that it is understood by everyone involved.

It is important to remember that disappearing messages (in any application) are only helpful for people who you trust currently. (And until the messages are deleted.)

I’ve been using Wayland every day for years with no issue (GNOME 3 on AMD graphics).

And the best part is that my OS isn’t actively hostile towards me (Windows) or at least want to control what I do with my computer (macOS).

They are just complying with the law here. As much as I don’t think Meta are great people I’d rather that they follow the law than make their own decisions. Of course we should also consider fixing these laws, but that isn’t really Meta’s responsibility.

If law enforcement knocks on my door with a valid warrant I’m going to comply. It would be nice to have some legal assistance to help validate the warrant but at the end of the day in this case it was almost certainly valid.

If this was about a murder rather than abortion people would be applauding Meta for helping catch the murderer. I think what people are actually mad about is the law, and they are using Meta as a scapegoat.

But at the end of the day E2EE is the best solution here. Don’t give private data to others, they can’t be trusted because they can be compelled by the law.

DPI? There are at least 4 expansions for that.

I don’t know if it is a huge issue but it is definitely a nice to have. There are a few examples I can think of:

1. I open the code in my IDE but build somewhere sandboxed. It would be nice if my IDE didn’t execute the code and can still do complete analysis of the project. This could also be relevant when reviewing code. Often for big changes I will pull it locally so that I can use my IDE navigation to browse it. But I don’t want to run the change until I finish my review as there may be something dangerous there.
2. I am working on a WebAssembly project. The code will never run on my host machine, only in a browser sandbox.
3. I want to do analysis on Rust projects like linting, binary size analysis. I don’t want to actually run the code and want it to be secure.
4. I want to offer a remote builder service.

I’m sure there are more. For me personally it isn’t a huge priority or concern but I would definitely appreciate it. If people are surprised that building a project can compromise their machine than they will likely build things assuming that it won’t. Sure, in an ideal world everyone would do their research but in general the safer things are the better.

Back in the day X was a great protocol that reflected the needs of the time.

1. Applications asked it to draw some lines and text.
2. It sent input events to applications.

People also wanted to customize how their windows were laid out more flexibly. So the window manager appeared. This would move all of your windows around for you and provide some global shortcuts for things.

Then graphics got more complicated. All of a sudden the simple drawing primitives of X weren’t sufficient. Other than lines, text and rectangles applications wanted gradients, rounded corners and to display rich graphics. So now instead of using all of these fancy drawing APIs they were just uploading big bitmaps to the X server. At this point 1/3 of what the X server was previously doing became obsolete.

Next people wanted fancy effects and transparency (like drop shadows). So window managers started compositing the display. This is great but now they need more control than just moving windows around on the display in case they are warped, rendered somewhere slightly differently or on a different workspace. So now all input events go first from X to the window manager, then back to X, then to the application. Also output needs to be processed by the window manager, so it is sent from the client to X, then to the window manager, then the composited output is sent to X. So another 1/3 of what X was doing became obsolete.

So now what is the X server doing:

1. Outputting the composited image to the display.
2. Receiving input from input devices.
3. Shuffling messages and graphics between the window manager and applications.

It turns out that 1 and 2 have got vastly simpler over the years, and can now basically be solved by a few libraries. 3 is just overhead (especially if you are trying to use X over a network because input and output need to make multiple round-trips each).

So 1 and 2 turned into libraries and 3 was just removed. Basically this made the X server disappear. Now the window manager just directly read input and displayed output usually using some common libraries.

Now removing the X server is a breaking change, so it was a great time to rethink a lot of decisions. Some of the highlights are:

1. Accessing other applications information (output and input capture) requires explicit permission. This is a key piece to sandboxing applications.
2. Organize the system around frames to avoid tearing except for when desired (X doesn’t really have the concept of a frame).
3. Remove lots of basically unused APIs like fonts, drawing and many others.

So the future is great. Simpler, faster, more secure and more extensible. However getting there takes time.

This was also slowed down by some people trying to resist some features that X had (such as applications being able to position themselves). And with a few examples like that it can be impossible to make a nice port of an application to Wayland. However over time these features are being added and these days most applications have good Wayland support.