To be clear, you’re not going to find many displays that can reach 4,000 nits yet. A lot of HDR content actually is mastered for 1,000 nits and that’s considered kind of the target for the mid-high range OLEDs right now. My pretty much top of the line QD-OLED Samsung S95C maxes out at something like 1350 nits. A 1000 nit capable Steam Deck OLED has plenty of range in luminance for HDR to be effective there. And I’m sure it’s got pretty good color reproduction which is the other big aspect of HDR.

One thing we haven’t talked about is the possibility that the Steam Deck is enhancing SDR content with dynamic tone mapping to such a degree that it’s difficult to tell the difference when you actually enable true HDR. I’d really have to see this with my own eyes to be able to say with more certainty what’s going on.

Yeah, the difference should be easily visible assuming one has quality source material and a nice display. I was kind of assuming OP was talking about using the Steam Deck in docked mode, but maybe that was a bad assumption.

I stopped paying for YouTube the moment Google killed Google Play Music and forced YouTube Music on me. Now Google gets no money from me and Apple does because they still offer a true music library service.

Tell me you’re Gen Z or Alpha without telling me you’re Gen Z or Alpha.

For sure, hands are generally getting better, but they are still a persistent problem. Mostly you need a prompter who isn’t lazy and is actually looking at the outputs.

I was able to get video streaming with audio working on Discord using pipewire, but it was a massive pain in the ass and somewhat unreliable. I don’t have a lot of experience with Jitsi, but I trust others’ recommendation there

Calibre is a fantastic and underrated tool.

I see, well I guess the real question is whether it can be improved at the server/protocol level and my answer is I don’t know. There’s some handshaking that clearly has to occur between your instance and the other instance to load the initial community state and I don’t know where that process can be optimized. I think I’ve seen people mention tools that have been created to automatically subscribe a dummy account on your instance to all the communities on the largest instances to kind of bootstrap the process for other users, but I don’t have a link to such a tool handy.

Edit, and there’s never going to be a guarantee that your server can talk to their server until you try clicking the link because the other server could be overloaded, down, or blocking your server.

What you’ve described is exactly how it’s supposed to work. Once a user has subscribed to an external community from your instance, it should load immediately for any users afterwards.

Why not? Plasma is much more usable out of the box for many users including myself. GNOME’s out of the box experience is really lacking IMHO and requires me to install and configure several extensions just to get what I consider to be a functional UI. I know they have this vision for how they want people to use their OS, but that vision is not aligned with how I actually want to use it. The best way distros can vote against the design choices of GNOME is by making something else the default. The problem I have is that I generally prefer GNOME’s app suite to KDE’s, so that makes the decision a bit more complicated for me.

Personally, I think it’d be nice if you could self-host just the bridge instances and connect them with beeper yourself, so that the part that isn’t e2e encrypted is running on software you can validate and hardware you control.

I 100% agree this would be a great solution. That’s what I thought this page was going to be at first until I kept reading and realized it’s just a config guide for the Matrix Ansible setup. I wish they didn’t say “self host Beeper” on that page at all because self hosting Matrix has absolutely nothing to do with the Beeper service other than their devs built the bridges that they’re showing you how to set up with Matrix.

I’m not sure where this text is that you’re referring to.

It’s almost not even fair to say they’re merely contributing back to the upstream bridges. Most of the bridges would not exist at all without the Beeper developers.

It’s also kind of funny that the section of their website you quoted still has language that implies you have to pay for Beeper when it’s been free for months at this point. The primary reason to self host Matrix at this point is for privacy and complete control. And self hosting Matrix is only free if you use existing hardware and I would recommend a cloud instance for most people.

Beeper’s server set up is actually a lot more complicated than just standard Synapse at this point. When they say you can “self host Beeper” that’s really not accurate at this point at all. All of their 3rd party chat bridges are dynamically spun up on a per user basis with hungryserv and those servers operate in parallel with a synapse server for Matrix interoperability all behind a roomserv server. Here’s a presentation that one of their lead developers created regarding their new architecture.

Afaik, that isn’t in effect yet, but will become a major factor next year.

What do you mean by nefarious exactly? I don’t get the impression that it’s evil…

As long as they don’t try to mandate that tech companies provide encryption backdoors, have at it.

It’s actually pretty sad that there are probably going to be some braindead Hollywood execs who completely missed the point of the movie and unironically pitch something like this.

As long as they didn’t staple the wire or something.

E2EE only exists up to the bridge, not the whole way to your client

I just want to clarify that most bridges can be set up to have E2EE between the Matrix client and the bridge (regardless of whether the bridge supports encrypted chats on the bridged service because not all do, e.g. Facebook), but it is true that the bridge itself has to decrypt and translate between Matrix and the 3rd party chat service, so as you mentioned trusting who hosts bridges or doing it yourself is really important.