[yebyen]

Man, I just wrote you a big long explanation of how you can update your filesystem even if your parent ship is gone, with shell command examples, but then my battery died before I had a chance to post it, and I'm totally not rewriting it now because I'm sure you don't care that much, and the real punchline is all of this information is about to be obsolete anyway.

The long and the short is, there are carriers (I have one), who are enumerated in the source code (like by public keys) and they are not dependant on each other, except for the sake of being able to route to child ships. So if ~zod is down, and everyone depends on ~zod, the network is indeed hosed. Everyone with active links can continue talking to each other, but nobody new can find anyone, and nobody can find anyone new. Every ship depends on a carrier for routing.

By convention, every time you launch from your pier, you get a new random port number and any ship that was looking for you at your old address needs to hear about your new address from a higher-up ship.

So it is distributed, but finitely distributed. There are only 256 carriers allowed, and they are the only ships that are really independent. Though there has been talk about fleshing out how ships can be separable from their "sein" domain, or parent ships, currently almost everyone is from the same lineage and thus depends on the same pair of servers for pretty much everything regarding the network.

This "centralized" design is indeed a core feature of the network, and it even relies on DNS to be bootstrapped, another centralized system. Now, can you show me a decentralized system that doesn't need any of that? I don't know exactly how magnet links or tor, or freenet work, but I am skeptical that they are honestly less centralized than this when it comes to bootstrapping.

[yebyen]

Follow-up: As I suspected, regarding magnet links

> 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.

[roboben]

Thank you very much for your long explanation. I really do care because I really like the idea of this. (Even I don't understand everything for now)

The question is: Why is my pier not trying to reach any of the available carriers then but only ~zod?

[yebyen]

Your submarine "needs" ~zod to be found by anyone because:

   try=> ->-<
   ... (your submarine)
   try=> (sein ->-<)
   ~zod

... ~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.

[bufo]

What about something inspired by SFS (see section 2.4 and 3.7 in this IPFS paper)? http://static.benet.ai/t/ipfs.pdf

[yebyen]

I will check it out. I was indeed hoping someone who knows the answer will come along and say "haven't you heard about this..."