Fantastic, thank you

Wow thank you, this is the most useful reply I’ve received so far!

This means I don’t need to mess around with QBT’s “proxy” settings? I was pretty confused since the only options available are SOCKS/SOCKS5 and HTTP, but I’m guessing that’s a different kind of proxy than what I need…

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.

Yes I already have that set up with Wireguard, what I’m figuring out is how to route traffic through it.

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.

Thank you for the links, I had found a few of these but some are new. The basic idea is there, I’ll see if any of these can work for us. I’m growing more convinced though that hosting a whole app for this super simple use case might not be worth it, I think we might pivot to just hosting a really basic static page for it.

This is way too overkill for what we need. I’m sorry, I’ve been intentionally vague about the context for this but I guess it’s too unclear. We’re an activist group planning a protest. We might have to get this set up literally tomorrow and every penny comes out of (mostly my) pocket. We’re also all paranoid about opsec and anonymity, which is why the requirement about avoiding corporate services is there. Perhaps I should have posted this in a privacy focused comm instead, I apologize.

It’s pretty overkill for what we need, and it would still fall under “corporate” for us. At that point I could just go for the static Notion page which I can get live in 5m for free.

We can set up all of those but again, that’s kinda expensive for us rn. What’s the benefit of using a CMS like Joomla versus wishthis, or even a basic Caddy/Nginx webserver with a static page?

I believe you need root to access those, plus a file manager that supports it (I use Mixplorer which does). Otherwise, as someone else suggested, you can access them from a computer over ADB or MTP.

They’re insufferable commies who keep attacking other parts of the Fediverse by… uh… commenting on posts and… ehm… responding aggressively to bigoted content. They’ve got all these sick ass stickers that we don’t and they keep flexing them in our replies which drives me crazy.

Their instance is an authoritarian distopia where queer people feel safe and they don’t waste time debating the same wrong liberal talking points every time. Also you can just call someone a dumbass if you disagree with them: a totalitarian nightmare.

Worst of all they go around straight up bullying other Fediverse users: right now I’m locked in a bathroom stall that a Hexbear user shoved me into. I’ve been here for an hour missing my maths class, and I’ve had to drink the toilet water. My tummy is starting to hurt. Stay away from Hexbear users…

This is such an amazing article, The Verge’s staff is still capable of some excellent journalism.

I had high hopes when I tried it out but frankly it’s been almost unusable for me. Terrible performance, laggy UI, plenty of bugs, long loading times for songs…

I don’t know if something in my mobile environment was messing with it but I use quite a few indie FOSS apps still in beta and none of them worked as badly as Spotube did. I’d love to go back to it if it improves, but for now it’s just not worth the UX pain.

Edit: forgot to mention. The idea of sourcing tracks from YouTube is cool but causes loads od trouble in practice. I’ve found remixed versions streamed as the original, tracks with the intro from the music video, tracks with sound effects from the music video, and tracks that just cannot be streamed cause they aren’t on YouTube. I know there’s a feature to pick which version to stream, but it’s quite a bit of UX friction and it didn’t work often enough to be a showstopper.

Even if its configured correctly to totally obfuscate the data and the final endpoint of the traffic it’s still blatantly obvious that a VPN is in use.

Which is why Chinese users don’t use standard VPNs, they use obfuscated proxies with protocols like Shadowsocks and V2Ray, which mask the tunneled traffic as innocuous HTTPS traffic.

Other people in that thread have pointed out that it isn’t showing posts being delivered to Threads despite the block. That should be testable with other instances, but not Threads since it’s not receiving any content from Mastodon at the moment. The concerning thing there is the user still being able to view content from people they’ve blocked, but that seems to be a bug if it’s reproducible.

In the EU companies can’t scrape personally identifiable information without consent, even if it’s already publicly available. IANAL, and there’s probably ways they can sneak around the GDPR, but at least it’s not a free for all. It’s unclear though how it works for federation. It’s definitely not the same legally though.

The reason for not directly federating content to Threads isn’t so nobody there can ever see my amazing posts, it’s so Meta can’t easily profile me. Scraping public posts on a different platform would probably be illegal, at least in the EU, and reposts don’t give them a lot of data about me. Federating content, however, would give them most of the same data that Mastodon has on me without even having to ask.