I've updated to 0.18.0 as well and can see your comment
reinar
joined 2 years ago
Generated wireguard config with nat-pmp enabled in ProtonVPN panel, put keys and endpoints to my vpn client (gluetun docker image), used https://github.com/soxfor/qbittorrent-natmap image to interactively update port from qbittorrent settings on proton through natpmpc.
https://github.com/soxfor/qbittorrent-natmap/issues/13 - I've set up my docker-compose pretty much by this example (ignore "unreliability" feedback, OP probably has some issues upstream - image itself is working). If you are using this, remove all upnp/nat-pmp checkboxes from qbittorrent, this image is your nat-pmp client.
Speaking of clients: this setup is for sure extremely ugly, but native implementation of nat-pmp in libtorrent for some reason is not doing what's needed, maybe because qbittorrent tries to use upnp/nat-pmp simultaneously. What I see is an error message from upnp client ("no router found" - understandable) and complete silence from nat-pmp.
They are now refunding past their 30-day money back period if you didn't use cash. Just got a refund for a top-up made in February.
https://lemmy.dbzer0.com/post/21703
I ended up buying ProtonVPN. Port forwarding required a bit of trickery with natpmpc image to set up in my case (headless wireguard gateway for dockerized services), however now it's fine and working.
Speeds are at least 800Mbps download (which is maxing out my uplink, vpn is likely to be capable for more), didn't have a chance to test upload.
They are claiming ProtonVPN port forwarding only works with Windows, however this is only relevant if you are using protonvpn app.
You can still generate wireguard config with nat-pmp support.
https://protonvpn.com/support/port-forwarding-manual-setup/
I'm not interested in their app at all since it's going to run as headless docker gateway for qbittorrent/radarr/sonarr/other shit anyway, but - it seems like they support proper NAT-PMP which is massive.
https://protonvpn.com/support/port-forwarding-manual-setup/
Wow wtf I didn’t know this.
https://mullvad.net/en/blog/2023/5/29/removing-the-support-for-forwarded-ports/
They already disabled the possibility to add new port forwards and will remove any existing ones completely on 1st of July.
it's most likely coming from postgres, db server tends to be the main resource hog.
Yes, big instances are not ready to handle the traffic and could go down - see lemmy.ml
Are all these thousands of lemmy servers useless?
almost. It's actually worse than that - when you subscribe to a community from your server it will fetch like 20 posts and that's it, you'll get only new stuff after that, so there's no possibility to do a full mirror of selfhosted, for example, if you started your instance today and didn't fetch posts and comments manually.
ActivityPub per se is just a spec on s2s/s2c communication, which is not a great thing since in many cases it assumes single source of truth, which potentially puts huge load on more popular instances.
I think a quick and dirty hack to this could be the following - each linked instance may maintain cache of announces (so there would be benefit of just forwarding original http signed requests w/o being afraid of malicious actor), which your instance could pull, this way you could populate your mirror without overloading the original source.
Distributed activities propagation though... Let's say there are some design steps involved to make this truly distributed, however I feel like it's possible.
it's not much, any non-micro vps from decent provider will do. For precise recommendations it'd be better to know where most of your users are located, latency is a bitch.