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.

deleted by creator

Thank you for laying it all out there. It sounds like you’re doing it the right way 🙂

Thank you for providing some context for this. It kind of sounds like a fork might not have been necessary if Ernest was willing to make @melroy a maintainer. Do you know if there’s any philosophical reason he wasn’t willing to do that? Real life stuff comes and goes, but it seems silly to halt the “official” project that others are relying on and still wanting to improve upon and thereby force a fork. As it stands right now, it sounds like it will be awkward for Ernest to come back in and try to restart work on kbin and will be increasingly awkward the more that mbin progresses, becomes the standard, and the code bases diverge.

It’s kind of interesting to watch in open source which projects survive and which get forked and essentially made irrelevant. It basically becomes a referendum on the vision of the original individual or team and how well they’re serving the collective user base. If they aren’t accepting PR’s and competently managing development, they’ll likely be forked. So I’m glad to see that folks are making progress with mbin and I can’t help thinking that its entire existence is probably due to individuals not being able to agree on a roadmap for the platform. If anybody has any info on any drama that led to this, I’d be curious to read about it.

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.

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.

You’d think so, but this has been possible the whole time and nobody has offered to invite us thus far.

> 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.

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.

You can run headless or do what the person I was responding to recommended and put it behind an authenticated portal, but that’s not really going to stop other instances and clients from accessing the same resources that op is hoping to limit access to except in the most basic case of people casually browsing op’s Lemmy instance through op’s own lemmy-ui.

Edit, but to be clear, what I was responding to and my response didn’t directly address op’s specific concern (which I kind of misunderstood myself before just now rereading) that outside/guest users shouldn’t be able to search for communities from other instances and I think it’s a fair concern because just searching for a community from another instance brings in posts and could be a vector for spam/abuse.

Wouldn’t this do basically nothing to prevent a 3rd party client from browsing your instance without authentication? I don’t know that there’s much that can really be done about this because you need open APIs for other instances to be able to access the content of your instance in order to make federation possible. That said, it’s an important consideration that anybody running a single person instance should consider. If you run a single person instance, people can learn a lot about you just by seeing which communities are available on your instance. The only way to obfuscate your actual interests is to have a dummy account subscribe to all the top communities on the biggest instances. (Which, honestly, this isn’t a bad strategy to employ anyway if you’re wanting a fresh All feed).

I’m honestly trying to figure out how the hell Meta is going to make money on this venture. The genie is out of the bottle for the Fediverse. If they try to show ads on Threads, people will presumably just get an account on a Mastodon instance and follow who they want from Threads…

Are you installing from scratch, docker, or Ansible? I know in Ansible the default nginx config has been wrong for a week or so, but just got fixed this morning.