I indeed have a domain name pointing to the VPS IP, with Caddy managing TLS. Other apps are exposed this way, and I will do the same for the qBittorrent WebUI as well. I like having Caddy as a single gateway where I can apply security configs and monitor all traffic, I was hoping I would be able to pass torrent traffic through it as well but everybody seems very much against it.

I already have wireguard setup as you describe so I guess I'll just give up on passing torrent traffic through the proxies and just open a localhost port on the qBittorrent container...

Resetting the "time since last being told I don't know shit on the internet" back to 0 once again...

I already have an existing and working setup used for other apps, it's close to the one described in this blogpost. Yes, it's complicated and inefficient, but it has reasons to be. I want to keep my qBittorrent configuration as close to this setup as reasonably possible for consistency. If your point is that it's counterproductive to follow this setup then... fair enough. I can just route traffic from the VPS to an exposed port on the local qBittorrent container over Wireguard, but that wasn't my preferred solution.

Running a torrent client through a proxy doesn’t isolated a process.

I was talking about network isolation, not process isolation.

make sure your traffic is routing there properly

That was pretty much what I was asking for help with.

I have already set up all of that. My setup is similar to the one in this blogpost and it's already working for various apps that only use HTTP. What I'm trying to do is to also route BitTorrent traffic (TCP/UDP) over the same setup without opening up entirely new paths.

I'm guessing what you mean is setting up port forwarding in Wireguard...

The thing is ideally I would want all connections in and out of my homeserver's Docker network to go through the local Caddy proxy, so the app containers are isolated. That still means having at least the local Caddy acting as a TCP proxy, even if the VPS Caddy is bypassed. If that's too much of a hassle though I can instead just expose a port on the qBittorrent container directly to the homeserver's localhost, and forward that with wireguard to the VPS.

By "set up wireguard to route through the VPS" you mean having wireguard forward a port from the VPS to a port on the homeserver at its wireguard IP address?

qBittorrent will still need to publish the right IP address to peers though, right? So I will need to configure the proxy VPS's IP address in qBittorrent...

Also that means binding a port on the qBittorrent container directly to the homeserver localhost. I've managed to keep the app containers isolated so far and it'd be nice to keep that, but if proxying the traffic is too annoying I guess I can just say fuck it and go with it.

Ah ok this I'm not sure about. I mean, Lemmy added instance blocks as well in the latest release (0.19), but it seems that, unlike Mastodon, this only hides the content from you and doesn't prevent your content from being sent to that instance. It does seem like a pretty big oversight, but I haven't found a discussion about this. There might be good reasons why it's this way.

I don't have the same phone and it's in general pretty difficult to fix a brick without being able to tinker with it. I can give you some pointers though...

First off, this guide is for a model A525F, but your title says your phone is an A526B. If that's correct there's a chance the files you tried to flash were for a different model number and that's what went wrong. Make sure you download the right files for your exact model number rather than trusting the ones your guide provides.

Secondly, to be honest, this guide does not seem very trustworthy. When doing this kind of thing every little step matters, a single misplaced reboot might screw up the whole process. Also, you're downloading and installing on your phone some files from some random website, that's a big risk. The thing is: you don't need a shitty guide for your exact model. For future reference, you're better off with a good, detailed guide for your general vendor (Samsung). XDA forums are usually the place to look. Always find the files you need by yourself, don't just flash whatever some random website makes you download. Go to the official download pages for Samsung stock OS or TWRP and get the files from there, making sure they match your exact model number.

If you're 100% sure that the firmware you're trying to flash is the correct one for your model, you can try avoiding Odin and use adb flash directly. There's plenty of guides on how to do that going around. You might not need TWRP either at that point. Getting familiar with adb is always useful.

Oh sure, didn't mean to imply that Chinese people weren't smart enough to think for themselves. I was just making the point that neither western media nor Chinese media is helping at all to create space or goodwill for critical exchange and debate across boundaries and firewalls (which, to be fair, is not surprising).

Glad to see there are actually Chinese netizens on Lemmy, by the way.

Oh cool, didn't know about the plugins.

Yeah I wasn't majorly worried, just checking.

Thanks. How does that work though? iTunes points it to the RSS feed of the individual results?

And do you know if there are any privacy risks associated with depending on iTunes?

I understand the logic, and you're right to think about how improve Lemmy's scalability. But I'm not sure if this is the way to go.

If you build a dedicated federation proxy for an instance, you've really just slightly moved the problem. The federation proxy is going to have the same scalability issues, and if anything the total load goes up.

If you build multi-instance hubs, you suddenly introduce a lot of new issues.

• Security: I think Lemmy checks the source of an update to verify that it comes from the legitimate host. You would have to introduce some kind of signatures to verify that the activity originated from the legitimate host.
• Privacy: now your users have to trust the hub owners with their data, not just the instance.
• Motive: who would be running the hubs, and why? They would have to be even bigger that the instances, and there would be much less incentive to do it.