Still figuring how to handle names

docs/libraries.md

@@ -386,6 +386,10 @@ OK, provided our primary repo is not co-opted by the enemy.
 
 # Installers
 
+Looking at cmake, choco, deb, git, and rust crates, I see a development
+environment being born, as people irregularly and ad hoc integrate with
+each other's features.
+
 Wine to run Windows 10 software under Linux is a bad idea, and
 Windows Subsystem for Linux to run Linux software under Windows 10
 is a much worse idea – it is the usual “embrace and extend” evil plot by

docs/social_networking.md

@@ -264,36 +264,100 @@ of a million shills, scammers, and spammers.
 So, you can navigate to whole world’s public conversation through
 approved links and reply-to links – but not every spammer, scammer, and
 shill in the world can fill your feed with garbage.
-## Algorithm and data structure.
-
- So rather than a distributed hash table structured by hash distance,
- nearest neighbour by social distance.
-
--## Algorithm and data structure.
+## Algorithm and data structure for Zooko name network address
 
 For this to work, the underlying structure needs to be something based on
 the same principles as Git and git repositories, except that Git relies on
 SSL and the Certificate Authority system to locate a repository, which
 dangerous centralization would fail under the inevitable attack.  It needs to
- have instead for its repository name system a distributed hash
-table within which local repositories find the network addresses of remote
-repositories on the basis of the public key of a Zooko identity of a person
-who pushed a tag or a branch to that repository, a branch being a thread,
-and the branch head in this case being the most recent response to a thread
-by a person you are following.
+find the network addresses of remote repositories on the basis of the public
+key of a Zooko identity of a person who pushed a tag or a branch to that
+repository, a branch being a thread, and the branch head in this case being
+the most recent response to a thread by a person you are following.
 
-So the hashes of identities are tracked by the distributed hash table, but the
-hashes of posts are not, because that would result in excessive numbers of
-lookups in a table that would very quickly hit its scaling limits.  The hashes
-of posts are tracked by the repository of the feed that you are looking at, so
-require only local lookup, which is faster and less costly than a distributed
-lookup.  This is equivalent to a fully distributed hash table where the key is
-not hash of post, but global name of area of interest, zooko nickname,
-zooko public key followed by his human readable thread name (branch
-name or tag name in git terminology) followed by hash of post, so that
-items that are likely to be looked up together are likely to be located
-physically close together on the same disk and will be sent along the same
-network connection.
+We want to support a zooko identity for a machine whose owner wants
+anyone in the world to be able to connect to, perhaps because he wants an
+audience for his ideas, or for what he is selling.  And we also want to
+support machines for which the connection information is a shared
+secret, distributed on a need to know basis.
+
+And we do not want a central authority with the capability to decide
+what that address is.
+
+For the normal case, zooko identity with public connect information, the
+controller of the machine makes public a small number of other zooko
+identities which have publicly accessible connect information, and very
+long lived network addresses, so that lots of entities are going to have their
+current network address cached, which identities  he promises to regularly
+inform of his current network address.  And those entities make public
+what they know of that network address, how recently they were informed
+of it, the likelihood of that network address suddenly changing, and
+apparent uptime of the entity whose network address they are reporting on.
+
+The final authority for each such item of information is the Zooko
+signature of the entity that wishes to be found, and the Zooko signatures of
+the other entities that he keeps informed.  Thus, the authority over the
+informations is fully distributed.
+
+But in order to collect, distribute, and efficiently obtain this potentially
+very large pile of data, there has to be a fair bit of centralization in
+practice.  Git source code distribution provides a model of how to handle
+this without dangerous or harmful centralization, or a central point of
+failure.
+
+For any one library on Git, there are an enormous number of branches.  But
+in practice, everone winds up following one branch of that library, and if
+you make changes in it, and want your changes included, you have to get
+the man (and it is always a man) who runs that branch to pull your branch
+into his.  And that is the centralization that is needed for efficient
+distribution of data.  But if he is not doing a very good job, some people,
+and eventually everyone, eventually winds up following a repository with a
+different name, reflecting the fact that a different man is running it.  And
+that is decentralization that is needed to prevent misconduct or single point of failure.
+
+So, if someone is providing the service of making other people's network
+addresses publicly available, he has to get that one man to pull his data.
+Or get another man, whose data is pulled by that one man, to pull his data.
+
+The reason git repositories scale is that the one man who in fact controls
+the one repository that matters the most trusts several other men, each of
+whom trust several others, and so information percolates through many
+trusted people, eventually into the central repository, where everyone sees it.
+
+Perhaps that one man might fail to include some zooko identity data for
+wicked reasons, that he does not want people to hear what those people are
+saying, that he wants to get between the man who wishes to speak, and the
+man who wishes to hear.  Then some people will start pulling an additional
+branch that does include those people, and eventually everyone winds up
+pulling that branch, and after a while not pulling the old branch, and
+eventually nearly everyone will do the same.
+
+On the other hand, that one man might fail to include some zooko identity
+data because he thinks it is a pile of sybils, shills, scammers, and
+entryists, and the pile is too large, wasting too much disk space and
+bandwidth, and if he is right, most people will not want that useless
+misinformation cluttering up their disks.  Or some people might disagree,
+and pull a branch that does include those questionable identitities.
+
+Once our system starts to attract substantial use and attention, a vast pile
+of sybil Zooko identities will appear, whose network addresses seem to be
+located all over the world, but a very large proportion of them will in fact
+be located on one computer in the bowels of the State Department or
+Harvard, and to avoid collecting and distributing a hundred gigabytes of
+this worthless and meaningless information will require human judgement
+and human action, which judgment and action will have to be done by a
+rather small number of humans, who will thus have rather too much
+power, and their failures rather too great consequences.  But, following the
+way that git is designed and in practice  used, we do not have to give them
+unlimited power, nor allow them to be a central point of failure.
+
+### runningt in schism, with many approximately equal branches
+
+Under attack, the system may well schism, with no one source that lists all
+or most Zooko identities that people are interested in contacting, but it
+should, like git, be designed to schism, and work well enough while
+schismed.  That is what makes Git centralization truly decentralized.
+Sometimes, often, there is no one authoritative branch, and things still work.
 
 The messages of the people you are following are likely to be in a
 relatively small number of repositories, even if the total number of