I can only see this being effective if the Nginx instance isn’t also responsible for reverse-proxying the frontend traffic, and if it’s not running on the same server as the frontend or backend (ie. decoupled from the infrastructure serving the stack). Haven’t looked at the article yet but I’m assuming they would recommend provisioning the infrastructure with that decoupling, or it wouldn’t make much sense.
I know it’s been around for a long time, but I just heard about Real Debrid. My current setup is Wasabi + Rclone + Jellyfin, plus all the *arr services. What’s the benefit of Real Debrid over this setup, aside from cached torrents?
Same here, I’ve never had this problem, ever. I don’t even get how it’s possible to not know where your files are being saved if you are the least bit techsavvy.
I use Clipious, an Android client for Invidious, on my phone. I selfhost my own Indivious instance so this is perfect in that my phone never connects to YouTube directly, and I can save all my subscriptions in one place without a YouTube account.
On my Android TV I use Smart Tube Next. If I really need to cast, I also have YouTube ReVanced on my phone for just that, but I barely use it.
As soon as Clipious gets a proper Android TV interface, I’ll be set, as both devices can just connect to Invidious and let it do all the work.
The ending of Soma.
Wasabi is great and cheap for S3-compatible object storage.
Oh yeah for sure. It’s just a matter of time. Out of all of these options, some will just fade away (some already have within weeks of initial release), and some will remain and just continue to get better as the development community continues to get a better picture of where all of the action is, and starts to want to be a part of it.
You’re seeing that toast about versions since backend version 0.18.0 switched away from using a websockets-based API to a REST API, and the Jerboa client app is (in a not-so-descriptive way) warning you that the backend you are connected to isn’t aligned with the app version in terms of what it expects of the backed. This should go away pretty soon as more servers update their backend version and the Jerboa app update hits more devices.
Oh yeah for sure, everyone should work on whatever they want without restriction or obligation to be focusing on what someone else wants. And more often than not a pet project is a way to learn a new language or framework with the goal of self-development. That’s a great thing.
It’s just a thought I selfishly have sometimes when I see many apps in development for the same platform, I can’t help but wonder “if all of this effort were focused across fewer apps, could each of those be better than any of these current ones are individually today?” Of course the number of devs contributing to a project has no direct correlation when it comes to the quality or maturity of the product. That’s down to the management, skillset of the devs, etc. I’m well aware of all of that, and the pros and cons of the differences in scenarios.
Just thought I’d share the thought out there. In any case, Lemmy getting all of this attention will no doubt lead to the rise of at least a few solid mobile apps that will stick around and not fizzle out into development neglect within a couple of months.
It’s awesome to see Lemmy getting lots of love, and choice in the mobile app space is great for everyone. But some part of me also kind of wishes that rather than spreading so much development effort out over so many mobile apps, that more developers would jump in and contribute to polishing up the official open source Lemmy mobile app, Jerboa. I can’t help but feel that it would be nice to see a focused effort somewhere in bringing that one in particular up to snuff, as a sort of “reference” app. And have a few others floating around out there just for some diversity and testing innovative ideas.
Maybe it’s already that way, I don’t know. It kind of feels like there’s a new Lemmy mobile app announced every couple of days.
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.
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.
I have all my Nginx files separated and using include statements for organization, so I can’t quickly and easily post an example, but a good place to start looking is at the various proxy_cache directives.
To be more accurate, I actually self-host Vaultwarden, which is a Bitwarden-compatible server built in Rust. I highly recommend it, it’s quick and easy to setup, light-weight, and works with all of the Bitwarden apps, browser extensions, etc.
I have a single Nginx container that handles reverse proxying of all my selfhosted services, and I break every service out into its own configuration file, and use include directives to share common configuration across them. For anyone out there with Nginx experience, my Lemmy configuration file should make it fairly clear in terms of how I handle what I described above:
server {
include ssl_common.conf;
server_name lm.williampuckering.com;
set $backend_client lemmy-ui:1234;
set $backend_server lemmy-server:8536;
location / {
set $authentication "Authentication Required";
include /etc/nginx/proxy_nocache_backend.conf;
if ($http_accept = "application/activity+json") {
set $authentication off;
set $backend_client $backend_server;
}
if ($http_accept = "application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\"") {
set $authentication off;
set $backend_client $backend_server;
}
if ($request_method = POST) {
set $authentication off;
set $backend_client $backend_server;
}
auth_basic $authentication;
auth_basic_user_file htpasswd;
proxy_pass http://$backend_client;
}
location ~* ^/(api|feeds|nodeinfo|.well-known) {
include /etc/nginx/proxy_nocache_backend.conf;
proxy_pass http://$backend_server;
}
location ~* ^/pictrs {
proxy_cache lemmy_cache;
include /etc/nginx/proxy_cache_backend.conf;
proxy_pass http://$backend_server;
}
location ~* ^/static {
proxy_cache lemmy_cache;
include /etc/nginx/proxy_cache_backend.conf;
proxy_pass http://$backend_client;
}
location ~* ^/css {
proxy_cache lemmy_cache;
include /etc/nginx/proxy_cache_backend.conf;
proxy_pass http://$backend_client;
}
}
It’s definitely in need of some clean-up (for instance, there’s no need for multiple location blocks that do the same thing for caching, a single expression can handle all of the ones with identical configuration to reduce the number of lines required), but I’ve been a bit lazy to clean things up. However it should serve as a good example and communicate the general idea of what I’m doing.
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.
I’ve struggled with trying to find an alternative to Google Photos that actually works well enough, and reliably enough, for me to feel comfortable enough to fully replace it. I’ve tried everything on the Awesome Selfhosted list that would be a potential competitor, but nothing comes close to Google Photos. It’s honestly just such a solid product it’s really hard to find an open source/selfhosted replacement that works at least as well. And Google Photos is just so convenient when it comes to shared albums, it’s just slick.
My ideal solution would be to have Google Photos remain the source of truth, but have something else as a secondary backup. I looked into the idea of using Rclone to mount Google Photos and another backend (ie. Wasabi), and just replicating periodically from Google Photos to another location. But unfortunately at this time (and maybe forever), the Google Photos API doesn’t allow you to access photos/videos in their original form, only compressed. But I want the originals of course, so this doesn’t fly. The next thing I’ll be looking into when I have more time is automating Google Takeout periodically to fetch the original quality photos/videos, then upload to a backup location. But it’s such a janky idea and it rubs me the wrong way… But it might be the only way. Rclone would have been so perfect if only it could get the original quality content, but that’s on Google not enabling that capability.
Atheist here. Extraordinary claims require extraordinary evidence. Atheism is merely about trusting what’s been proven, or has some evidence backing the claim that can be verified without doubt. Being agnostic is being indecisive about everything, even things that are completely made up.