Telegram has some pretty interesting ideas wrt censorship circumvention. I.e. you can still use Amazon, Google, Microsoft as an unblockable side channel to deliver proxy settings, same way domain fronting relies on them. And you can sponsor other people to setup proxies, making it hard to detect and suspend accounts used for censorship circumvention on Amazon and other hosting companies.
As a side channel dns over https still works even with tls to google.com and then putting Host: dns.google.com into the header. Frequent updates to applications and push notifications can be used as side channels too. You can also register a bunch of domain names ahead of time using hash of a current day, month, year and then let the app generate domains names to query on the fly and query them over normal dns. The censor would need to reverse engineer the app to figure out the domain generation algorithm.
To make proxies hard to enumerate you can shard the mapping of ids/phone_numbers to proxies in a such way, that each id receives multiple proxies using multiple different sharding schemes. This not only makes it harder to enumerate, but also lowers the chances of someone else obtaining the same set of proxies as the censor and rendering the app unusable. Changing IPs then forces the censor to chase you, but never really catch you to censor the app.
But I do think building peer-to-peer network instead of proxies is a better idea for circumvetion.
Given its an open source app, it should be reasonably easy for the censor to reverse engineer the algorithmically generated domains. Frequent tiny updates would be an interesting solution though. Now that most mobile apps can deliver just deltas to save bandwidth it'd be viable.
I realize now, that it's possible to even dynamically deliver a bytecode of a domain generating algorithm itself or pretty much any circumvention logic by embedding a tiny interpreter into the app.
You don't need to deliver bytecode, just a new seed for the algorithm. Even 64 bits is more than sufficient to ensure that they can't enumerate all possible seeds.
As a side channel dns over https still works even with tls to google.com and then putting Host: dns.google.com into the header. Frequent updates to applications and push notifications can be used as side channels too. You can also register a bunch of domain names ahead of time using hash of a current day, month, year and then let the app generate domains names to query on the fly and query them over normal dns. The censor would need to reverse engineer the app to figure out the domain generation algorithm.
To make proxies hard to enumerate you can shard the mapping of ids/phone_numbers to proxies in a such way, that each id receives multiple proxies using multiple different sharding schemes. This not only makes it harder to enumerate, but also lowers the chances of someone else obtaining the same set of proxies as the censor and rendering the app unusable. Changing IPs then forces the censor to chase you, but never really catch you to censor the app.
But I do think building peer-to-peer network instead of proxies is a better idea for circumvetion.