Leaderboard

Not to mention that Wireguard is superior when it comes to mobile devices. They tend to often roam between wifi and cellular (or two in case of dual SIM). Wireguard is well prepared for such a scenario.

Not true unless the mobile carrier somehow restricts or throttles UDP traffic. Generally UDP is far superior to TCP performancewise, mobile or not. And wireguard requires UDP and will not even connect if UDP is blocked by the carrier.

Wow, been that long. Checked my profile & looks like I've been using your service for 10 of those 13 years, so far. You are definitely an appreciated & necessary part of my "digital" life, transactions & interactions as much as the traditional internet & mobile phone services we are all dependent on more & more to do practically anything through telecommunications. I don't always feel it daily, but I know how very hard all the staff are working for themselves & the service they provide to AirVPN customers. Could never fathom all the difficulties & challenges to maintain, expand & defend this service & the equipment/staff involved. You are all true warriors & I hope to continue to support/subscribe to your efforts because they benefit all of us.

Hello, I'm one of the Mullvad refugees. While I tried it for a few weeks now, using a peer-to-peer protocol without a forwarded port was just too slow and often it was even impossible to establish connections to peers. And although I'm very happy with your service and the general scope of the API, there are some things that are broken or that I'm missing: Setting device names and descriptions via the API. Assigning ports to devices via the API (preferable by ID and name, but most importantly by ID), maybe also claiming ports via the API. In my tests calls to the configuration generator API with "resolve=on" would only work for IPv4 endpoints, not for IPv6 endpoints. It would be great if this also worked for IPv6 addresses. It seems a bit strange to me that adding a device returns a longer ID, while the other parts of the API which use the ID seem to truncate it to 50 characters. Why isn't the truncated ID returned uniformly? It would be nice for my use-case to also have the configuration generator optionally return JSON. The current configurations are to be consumed by wg-quick and while using wg-quick (either to load them or to transform them to wg rules) or parsing them and using them with wg is easy enough, it would just be nice to have the additional option. Maybe with some nice clean key names like "public_key". Example request for the mentioned IP resolution problem: curl -H "Api-Key: <REDACTED>" "https://airvpn.org/api/generator/?protocols=wireguard_1_udp_1637&servers=europe&device=default&resolve=on&iplayer_entry=ipv6" -o AirVPN_Europe_UDP-1637.conf This will properly resolve the hostname to an IP when "iplayer_entry=ipv4" (or the empty default) is set, but just pass the hostname through when "iplayer_entry=ipv6" is specified.

No, if all peers were not reachable BitTorrent would not work at all. The reason is trivial, just study how the protocol works. Actually there are many "dead torrents" not because there are no peers with the complete file, but because those peers in the swarm are active but not reachable. You have the impression that torrenting works even if some peers in a swarm are unreachable only because there are peers which are reachable in that swarm, so unreachable nodes (leechers) can keep leeching. This is the essence of the claims "you can keep torrenting even without remote port forwarding": yes, provided that parasites in a swarm can leech thanks to the effort of others. Maybe you should study how the protocol works before insulting. We're momentarily locking this thread, too many off topics are making it confusing. Kind regards