> The first time a client joints the DHT network it generates a random 160-bit ID from the same space as infohashes, and then bootstraps its connection to the DHT network using hard-coded addresses of clients controlled by the client developer.
This sounds really quite like the process of creating a submarine, and reaching out to the carrier ~zod. The fact that the init process is hardcoded to trust ~zod doesn't change that you can really init your ship's filesystem from any other ship, provided you can reach it.
Carriers are all found through the existing DNS infrastructure. Other ships are able to be reached "in-band" by asking a carrier for an introduction. Without this seed or hardcoded list (or by conducting a brute-force search), or some kind of broadcast mechanism, bootstrapping a distributed network is not actually possible.
... ~zod is your parent ship. Without him, you simply have no forwarding address.
If your batz wizardry is sufficient and ~zod is not there (both of these are things that we are not counting on being true when you run Urbit for the first time) you will still get the same result in your terminal, you can reach out and contact other carriers and their friends, even without ~zod. They just can't find you. And you need to find another way to bootstrap your clay (filesystem) if you care about having local clay.
Think about the difficulty of coordinating multiple stakeholders, compared to the ease of explaining the "benevolent dictator" model that most of computing is really based on today. If the only thing that ~zod needs to do is point submarines at one another and facilitate the existence of other signing ships under his domain, that's very easy. Doing those things without ~zod's cooperation will require some further thought and more explanation.
I am a carrier owner (~del) and I count on ~zod to make it easy for new subs to find me. It's very convenient this way. But, anyone who knows how to type:
:~del/main=/bin/hi ~dalnel
... can also reach out to my carrier and run "hi" (become mmy neighbor) to find ~dalnel with my help, and exchange keys with him (~dalnel is the cruiser, like ~zod's ~doznec).
~zod never needs to get involved. There is, however, no magic under the hood. My carrier ~del works exactly the same way, except he is not preferred in the same way by the submarine client implementation.
> The first time a client joints the DHT network it generates a random 160-bit ID from the same space as infohashes, and then bootstraps its connection to the DHT network using hard-coded addresses of clients controlled by the client developer.
This sounds really quite like the process of creating a submarine, and reaching out to the carrier ~zod. The fact that the init process is hardcoded to trust ~zod doesn't change that you can really init your ship's filesystem from any other ship, provided you can reach it.
Carriers are all found through the existing DNS infrastructure. Other ships are able to be reached "in-band" by asking a carrier for an introduction. Without this seed or hardcoded list (or by conducting a brute-force search), or some kind of broadcast mechanism, bootstrapping a distributed network is not actually possible.