arch-choot

To be fair, USDC & USDT are centralized by Circle and Tether respectively, and they can freeze funds.

Less true for ETH (though in the past it forked after DAO hack to revert the txns), and I think never for BTC / XMR.

I've been using DS4F+Pi with great results, but I think one thing that helps is at the end of my prompt I'll tell it how to verify it, e.g. "Make sure the compose file works by running it locally (use self-signed certs if required)".

The argument could be made that "the model should be smart enough to figure it out" , and maybe DS4 isn't. But with just a bit of steering you can get the correct result for like 1/10th the cost, or even cheaper.

I run a rust webserver on a €4 VPS from hetzner that serves 300M (million) requests a day. Way cheaper than doing that on _any_ "serverless" request-based platform, I think.

Could you clarify a bit more what you mean by "Domain Fronting is why ECH exists"?

Because even with ECH, you (TLS client) can set any public_name you want, but the innerSNI can be something else.

Or is that what you mean; since the providers can "ignore" the OuterSNI, they can rely on the InnerSNI to still route traffic?

An example for the hub:

``` echo -e "GET / HTTP/1.1\r\nHost: www.pornhub.com\r\nConnection: close\r\n\r\n" | openssl s_client -connect 66.254.114.41:443 -quiet ```

This works for most ISPs in India, but if you set the SNI it'll get a TCP reset

\> This makes the spec entirely meaningless for small servers and basically requires shifting hosting to shared hosts/massive CDNs to provide any protection against SNI snooping.

Actually you can setup ECH on your server, and configure the public_name to be something like `cloudflare-ech.com` , so clients would indeed use that in the OuterSNI, connect to you, without you needing to use CF. And middleboxes might think they are indeed connecting to CF (though CF publishes their IP ranges so this could be checked elsewhere).

Should've added this was back in like 2018 or so. Setting up DoH was harder than enabling SNI, and from my testing back then they were hard filtering on SNI (e.g. I used OpenSSL CLI to set the SNI to `pornhub.com` and connect to "known good" IPs, it'd still get reset).

Funnily enough, not setting the SNI and connecting the the origin IP, and then requesting the page worked fine.

Those are great domains for this kinda thing! Thanks for the idea

Just bare wireguard on 51820? I think I had tried that but no luck; but I don't remember for sure.

Sorry if its a bit unclear; the first part was HKG -> LHR when I kinda discovered it (9th May), and then the HTTPS proxy test was my flight back LHR -> HKG (18th May)

Ah right, if they also impose IP restrictions this would not work