I have heard that Blockstack can not be disabled because of the fact that it has “censorship vectors both at the blockchain layer and P2P (Atlas layer)”.
Can we get a layman’s explanation of how this would work? Does it mean as long as there are p2p nodes with the Zonefile DHT, and bitcoin’s are being mined, Blockstack is impossible to take down?
Thanks for clarity on this topic because it’s a huge selling point for apps built on Blockstack.
Can we get a layman’s explanation of how this would work? Does it mean as long as there are p2p nodes with the Zonefile DHT, and bitcoin’s are being mined, Blockstack is impossible to take down?
As long as all of the following are true, you can use a Blockstack application:
When operating correctly, each Bitcoin node has a full copy of the blockchain, and each Blockstack node has a full copy of all of the zone files. As long as you can reach any such Bitcoin node and any such Blockstack node, you’ll have points 1 and 2 covered. Since users can run their Gaia hubs anywhere they want, something like a datacenter outage or a BGP screwup are unlikely to knock the entire system offline.
Also, a point of clarity–Blockstack does not use a DHT precisely because DHTs are easy to take down in practice (the system instead uses a much more resilient p2p network called the Atlas network). Bitcoin does not use a DHT either, for the same reasons.
In the near future, we’ll be making the system even more reliable by allowing users to run multiple Gaia hubs. For example, I should be able to run three Gaia hubs: two in different datacenters on different continents, and one on a personal server. As long as one is reachable, you’ll be able to read my data. We have a Github issue open here if you’re interested in contributing 
Won’t you need to get to the actual app code too?
So currently:
IPFS or some other resilient network:
stealthy.app + IPFS/similar
stealthy.app + HTTP
Or am I picking blueberries? I guess there’s actual some more general way to say all that.
Won’t you need to get to the actual app code too?
Yes. One idea Ryan had was to make it so the developer could store the application code in the Atlas network itself. Then, as long as you could reach any Blockstack node, you would have all such applications available locally. The downsides of course are that it’s comparatively much more expensive to store the application code this way (the developer needs to send 1 BTC transaction per 40K of code), and pushing updates require more Bitcoin transactions.
app is loaded from DNS+ IPFS or some other resilient network:
app is using blockstack name resolution stealthy.app + IPFS/similar
Unfortunately, IPFS is trivial to censor. IPFS uses a DHT for mapping hashes to IP addresses, so (1) the censor can always learn the set of IP addresses from the DHT and block them at the IP level, and (2) the censor can intentionally split the DHT by inserting sybil nodes into the victim’s peers’ routing tables that simply block the victim’s lookup requests to censored content or censored IP addresses. Moreover, attack (2) can be carried out by anyone—because anyone can run a DHT node and become the victim’s peer, the attacker doesn’t have to be someone who controls the victim’s ISP or controls the nation’s ingress/egress routers. These vulnerabilities are fundamental to the design of DHTs; this is the reason Blockstack uses the Atlas network instead.
Okay, fancy. But ‘some other resilient protocol’ then. The cool thing is that Blockstack can actually be protocol independent. But it needs to be implemented in the app runner ofc. Maybe this ‘substratum’ that implied blockstack has the wrong model because it doesn’t do infrastructure like they do (lol).
@jude Thanks for these detailed answers.
I have been thinking a lot about this recently.
Is there any way to prevent the following attack:
A censor uses the below APIs to get the unique Gaia hub URLs and blocks them all.
GET NAMESPACE NAMES
PROFILE SEARCH
A censor uses the below APIs to get the unique Gaia hub URLs and blocks them all.
As it stands, this is viable today. However, there is a straightforward and backwards-compatible protocol change that would make this kind of censorship a lot harder to carry out: allow a Blockstack Core node to mirror profiles as well as zone files. Then, as long as you can reach any Blockstack Core node that does this, you can resolve names to profiles.
The client resolver code could be altered to first try the Gaia hub(s) listed in the user’s zone file, and fall back to your Blockstack Core (and the transitive closure of its Atlas neighbors) if this fails. The Core nodes would be considered opportunistic secondary replicas—unlike the primary replicas (listed in the zone file), there’s no guarantee that the Core node will have the latest state. The name resolution protocol would need to be altered to provide a hint to the client if it fetches a profile from a Core node, so the client can know to expect stale data.
Well they could block these Core nodes too.
But then nothing else works too, and that’s the time when you’d need to spin up your own Core I guess.
I mean, if you block all internet by, say, pulling the plug, it also wouldn’t work. 
I wonder if we later should have really aggressive use-stale-if-unreachable caching for zone files. So p2p apps would continue to work even if core nodes are inaccessible. Though it carries other problems.
I’ve been thinking about this and bridging as I study Kademlia, Bittorrent and Webtorrent. The notion being distributing zone file data on torrent networks as a fallback.
Edit: Our iOS mobile prototype is already doing some caching of this variety for perf.