Merge branch 'master' of cpal.pw:~/wallet into cmake

docs/social_networking.md

@@ -264,57 +264,47 @@ 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.
+ approved links and reply-to links – but not every spammer, scammer, and
-
+ shill in the world can fill your feed with garbage.
-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 Kamelia distributed has
-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.
-
-The Distributed hash table key will be:\
-<<<<<<< Updated upstream
-`human readable area of interest name/#public key of zooko name/ 
-=======
-`#public key of zooko name/ 
->>>>>>> Stashed changes
-human readable branch name/#hash  of data item`\
-so that items that are likely to be looked up together will likely be near
-each other on the same physical disk, and transmitted over the same
-network connection.   When someone approves of a text, then it goes into a
-repository he controls or has write access to, and gets a corresponding key
-in the distributed hash table.
-
-<<<<<<< Updated upstream
-=======
-Which is not exactly a distributed hash table, for a hash table relies on the uniform distribution of hashes for its efficiency, and, because we want things likely to be looked up together at the same network address on the same physical machine, this is a very non uniform distribution.  But it will still be efficient, because by the time you walk the network past the zooko
-key, you will seldom have very far to walk.  Walk the network to the end of
-the zooko  key, you are at a machine to which that identity has write
-access, and thus, he has the authority and incentive to make things work.
-
-Rather than being a distributed hash table, this is a distributed patricia tree. 
-But it will work if the person who controls a particular Zooko name
-structures the data under his name in accordance with the characteristics of
-the lookup process, and if he does not, other people will fail to find the material in his repositories, and that is his problem, which he can  fix.
-
->>>>>>> Stashed changes
-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
-repositories out there is enormous and the number of hashes in each
-repository is enormous, so this algorithm and data structure will scale, and
-the responses to that thread that they have approved, by people you are not
-following, will be commits in that repository, that, by pushing their latest
-response to that thread to  a public repository, they committed to that
-repository.
-
-Each repository contains all the material the poster has approved, resulting
-in considerable duplication, but not enormous duplication.
 
+-## Algorithm and data structure.
+-
+-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 Kademlia 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.
+-
+-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.
+-
+-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
+-repositories out there is enormous and the number of hashes in each
+-repository is enormous, so this algorithm and data structure will scale, and
+-the responses to that thread that they have approved, by people you are not
+-following, will be commits in that repository, that, by pushing their latest
+-response to that thread to  a public repository, they did the equivalent of a
+-git commit and push to that repository.
+-
+-Each repository contains all the material the poster has approved, resulting
+-in considerable duplication, but not enormous duplication.
+-
 The underlying protocol and mechanism is that when you are following
 Bob, you get a Bob feed from a machine controlled by Bob, or controlled
 by someone that Bob has chosen to act on his behalf, and that when Bob