wpuckering

I know right? The free tier would be enough to handle most anything and would take a tremendous load off of the origin server with proper Cache Rules in place. I can’t remember which instance it was, but one of the big ones started to use Cloudflare but then backtracked because of “problems”. When I saw that, I couldn’t help but think that they just didn’t know what they were doing. My instance is currently behind Cloudflare, and I’ve had no problem whatsoever with anything.

However, that’s come with other tradeoffs in useability, speed, and fediration experience.

Like what? If properly configured none of the things listed should negatively impact hosting a Lemmy instance.

sure I’ll be adding an exception/rule for that, but it’s not a straight forward task.

It honestly should be to someone who would be hosting any public web application using Cloudflare. Cloudflare makes all of this quite easy, even to those with less experience.

Heck, the removal of websockets will require quite a few changes in my Cloudflare config.

What config are you referring to? In the Cloudflare console? For websockets changing to a REST API implementation there should be nothing at all you need to do.

Sure, someone truly concerned with security knows to do this, but that’s definitely not going to be everyone

And it shouldn’t have to be everyone, only those who take on the responsibility of hosting a public web application such as a Lemmy instance.

No matter the capabilities inherent in what you choose to host, the onus rests on the owner of the infrastructure to secure it.

Everyone should be free to host anything they want at whatever level of security (even none) if that’s what they want to do. But it’s not reasonable nor appropriate to expect it to be done for you by way of application code. It’s great if security is baked in, that’s wonderful. But it doesn’t replace other mitigations that according to best practices should rightfully be in place and configured in the surrounding infrastructure.

In the case of the captcha issue we’re discussing here, there’s more than enough appropriate, free solutions that you can use to cover yourself.

There’s nothing stopping instance owners from incorporating their own security measures into their infrastructure as they see fit, such as a reverse proxy with a modern web application firewall, solutions such as Cloudflare and the free captcha capabilities they offer, or a combination of those and/or various other protective measures. If you’re hosting your own Lemmy instance and exposing it to the public, and you don’t understand what would be involved in the above examples or have no idea where to start, then you probably shouldn’t be hosting a public Lemmy instance in the first place.

It’s generally not a good idea to rely primarily on security to be baked into application code and call it a day. I’m not up to date on this news and all of the nuances yet, I’ll look into it after I’ve posted this, but what I said above holds true regardless.

The responsibility of security of any publicly hosted web application or service rests squarely on the owner of the instance. It’s up to you to secure your infrastructure, and there are very good and accepted best practice ways of doing that outside of application code. Something like losing baked in captcha in a web application should come as no big deal to those who have the appropriate level of knowledge to responsibly host their instance.

From what this seems to be about, it seems like a non-issue, unless you’re someone who is relying on baked in security to cover for your lack of expertise in properly securing your instance and mitigating exploitation by bots yourself.

I’m not trying to demean anyone or sound holier than thou, but honestly, please don’t rely on the devs for all of your security needs. There are ways to keep your instance secure that doesn’t require their involvement, and that are best practice anyways. Please seek to educate yourself if this applies to you, and shore up the security of your own instances by way of the surrounding infrastructure.

The main advantage to me is that I can work with Invidious as a backend, and whatever I configure there will reflect in Clipious as a client. So as I subscribe to new channels in Invidious, add or update playlists, etc, Clipious will reflect these changes accordingly. Advantages of selfhosting Invidious that indirectly benefit Clipious are of course built-in adblocking by virtue of how Invidious works, SponsorBlock support, and the ability to cache static assets, such as video thumbnails for faster load times, using a reverse proxy (Nginx is what I use). There’s a lot more we could dive into beyond this, such as no Google account requirement (for enhanced privacy).

One area where the SmartTubeNext and YouTube ReVanced combo has the advantage is the convenience of being able to cast from your handheld device to your TV. Clipious/Invidious has no casting ability. But I can totally live without that.

I just stood up a selfhosted Invidious instance the other day, and I replaced YouTube ReVanced with Clipious (an Invidious client for Android) on my phone. No ads, SponsorBlock built-in, no need for a YouTube/Google account to create subscriptions, playlists, etc. And it’s highly performant since I run it behind a reverse proxy with some custom caching configuration for things like thumbnail images, static assets, etc.

Clipious can also be installed on an Android TV (has an actual Android TV interface). I’m going to end up installing it on mine, but I’m also using SmartTubeNext at the moment, which does require a YouTube/Google account for subscriptions, playlists, etc, but does have no ads, built-in SponsorBlock, and a slew of other great features. I’ll be keeping both around, since I do sometimes like to cast to my TV, and SmartTubeNext allows for that (Clipious does not, at least at this time).

Unless YouTube somehow starts dynamically splicing in ads as part of the actual video stream, there’s always going to be a way to block ads, unless they do something pretty elaborate. But that’s probably not worth the effort on their end to go that far, since the vast, vast majority of people won’t know what to do to get around that, nor will they probably care enough to try. But I think it’s clear that DNS blocking using services such as AdGuard Home, PiHole, etc, are going to become less effective over time.

A spike in subscribers for a period doesn’t necessarily mean they’re making more money than before, even if the number of new signups offsets the cancellations.

I used to pay for the Premium plan, sharing with my parents, but downgraded to the Basic plan. My parents ended up getting their own Basic plan. So a single account essentially split into two, but the sum of both payments is now less than what it used to be for the single account. So Netflix gained an extra subscriber, but is now making less money from that pool of users.

It’s totally possible that some number of these new signups consist of people who did the same thing.

Basically, seeing a spike in new signups isn’t itself a measure of success. What matters is how much money they’re bringing in monthly going forward compared to previously.