> Adding insults to injury, the vast majority of Tor relays are dominantly located in US and EU, and there are barely any Asian Tor operators like me, let alone

> Adding insults to injury, the vast majority of Tor relays are dominantly located in US and EU, and there are barely any Asian Tor operators like me, let alone exit node operators. Why does this matter? Wouldn't it just mean that you have one slow initial hop (AS client → EU/US exit node), and then a bunch of internal EU/US → EU/US hops that are fast? > That is why I think SPA and PWA, both client-side oriented application on such a low rate network like Tor hidden service, and abstracting server interaction as low overhead APIs such as gRPC and ttrpc, would be very useful as I was experimenting it before, but most people uses Tor Browser, they would likely be disabling JS with NoScript for...security reasons. Right, this is why I said "Tor with a public web gateway, plus an IPFS-hosted SPA." The site backend is hosted on Tor, but the user never realizes they're using Tor. And the site frontend doesn't need anonymity (it's just app code, there's nothing directly IP-infringing there, so nobody's going to actively purge/block the JS for it from their own IPFS node's cache) so it can and will end up widely p2p-cached. IPFS also means you get DNSLink, which means you can take any DDNS provider CNAME it to any IPFS gateway and end up with a memorable domain name to visit, where the inevitable whack-a-mole occurs only on the DNS level, not on the level of needing to run actual HTTP proxies.