Merge remote-tracking branch 'origin/master' into docs

.gitconfig

@@ -12,6 +12,12 @@
 	alias = ! git config --get-regexp ^alias\\. | sed -e s/^alias\\.// -e s/\\ /\\ =\\ / | grep -v ^'alias ' | sort
 [commit]
 	gpgSign = true
+[push]
+	signed=true
+[merge]
+	verify-signatures = true
+[pull]
+	verify-signatures = true
 [submodule]
 	recurse = true
 [diff]

docs/libraries.md

@@ -95,7 +95,7 @@ Libraries are best dealt with as [Git submodules].
 
 [build libraries]:https://git-scm.com/book/en/v2/Git-Tools-Submodules
 
-Git submodules leak complexity and surprising and inconvenient behavior
+Git submodules leak complexity and surprising and inconvenient behaviour
 all over the place if one is trying to make a change that affects multiple
 modules simultaneously.  But having your libraries separate from your git
 repository results in non portable surprises and complexity.  Makes it hard
@@ -134,19 +134,29 @@ tag, not by branch, and the names of branches are only used to
 communicate a particular project on the submodule to other people
 working on that project as their master project.
 
-Branch names are not useful within a submodule, though
-submodule may well be, from the point of view of the primary
-developers, not a submodule but a module in its own right, used as
-a submodule in many different modules, so for them, branch names
-will be useful.  But when you are modifying the submodules in a
-project as a single project, making related changes in the module
-and submodule, the names belong in the primary project module,
-Within the submodule, commits are nameless with detached head,
-the name in primary module naming a group of related commits in
-several submodules, which commits do not usually receive
-independent names of their own, even though the commits have to
-be made within the submodule, not in the containing module which
-names the complete set of interrelated commits.
+Branch names within a submodule, though very useful when you working
+on a submodule, are not useful to the project as a whole, and except for the
+primary fork name, should be temporary and local., not pushed to the
+project repository, But when you are modifying the submodules in a
+project as a single project, making related changes in the module and
+submodule, the shared names that are common to all developers belong in
+the primary project module,and when you have done with a submodule, 
+
+```bash
+git switch --detach
+```
+
+Within the submodule, commits are nameless with detached head, except
+when you are working on them, the name in primary module naming a
+group of related commits in several submodules, which commits do not
+usually receive independent names of their own, even though the commits
+have to be made within the submodule, not in the containing module
+which names the complete set of interrelated commits.
+
+The submodule commits may well belong to different branches and tags in
+the superproject, but in the submodules, they are nameless in that all the
+submodule commits wind up attached to the same branch, your submodule tracking
+branch.
 
 In this case, working on submodules as part of a single larger project, you should set
 
@@ -182,19 +192,24 @@ Make sure things still work.  Get everything working.  (You do have unit test, r
 then:
 
 ```bash
-git submodule foreach --recursive 'git push origin HEAD:«your-tracking-branch»'
 git submodule foreach --recursive 'git switch --detach'
+git submodule foreach --recursive 'git push origin HEAD:«your-tracking-branch»'
 ```
+You pull a named release of the project that is a submodule of your project
+from `upstream`, diddling with it to make it work with your project, then
+you push it to `origin` as a nameless commit, though you probably gave the
+various commits you made while working on it temporary and local names
+with `switch -c yet-another-idea`
 
 All of which, of course, presupposes you have already set unit tests,
 upstream, origin, and your tracking branch appropriately. 
 
-Even if your local modifications are nameless in your local
-submodule repository,  on your remote submodule repository they
-need to have a name to be pushed to, hence you need to have a
-tracking branch in each of your remote images of each of your
-submodules, and that tracking branch will need to point to the root
-of a tree of all the nameless commits that the names and commits
+Even if your local modifications are nameless in your local submodule
+repository,  on your remote submodule repository they need to have a name
+to be pushed to, hence you need to have a tracking branch in each of your
+remote images of each of your submodules, and that tracking branch will
+need to point to the root of a tree of all the nameless commits that the
+names and commits
 in your superproject that contains this submodules point to.
 
 You want `.gitmodules` in your local image of the repository to
@@ -241,7 +256,7 @@ means you can incorporate unlimited amounts of stuff, and Git only has to
 check the particular module that you are actually working on.
 
 Maybe subtrees would work better if one was working on a project where
-several parts were being developed at once, thus a project small enough
+several parts wer e being developed at once, thus a project small enough
 that scaling is not an issue.  But such projects, if successful, grow into
 projects where scaling is an issue.  And if you are a pure consumer of a
 library, you don't care that you are breaking the git model, because you are

docs/rootDocs/README.md

@@ -91,6 +91,13 @@ unless you tell `gpg` to trust the key that is in the root directory as
 Never check any Gpg key related to this project against a public
 gpg key repository. It should not be there.
 
+`gitconfig` disallows merges unless you have told `gpg` to trust the public
+key corresponding to the private key that signed the tip of the root.  So part
+of the pull request process is getting the puller to trust your public key, and
+you will not be able to pull updates unless you tell `gpg` to trust the key that
+is in the root directory as `public_key.gpg`.
+
+
 Never use any email address on a gpg key related to this project
 unless it is only used for project purposes, or a fake email, or the
 email of an enemy.  We don't want Gpg used to link different email

docs/social_networking.md

@@ -263,46 +263,17 @@ 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.
 
 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.
+ have instead for its repository name system a distributed name system, but
+ a Kamelia distributed hash table will come under hostile attack.
 
-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.
+ So rather than a system relying on nearest neighbour by hash distance, nearest neighbour by social distance.
 
-<<<<<<< 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
@@ -315,6 +286,18 @@ repository.
 Each repository contains all the material the poster has approved, resulting
 in considerable duplication, but not enormous duplication.
 
+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

libsodium

@@ -1 +1 @@
-Subproject commit 012e892841ed6edc521f88a23b55863c7afe4622
+Subproject commit f333ea1beb9a61dcf61449faf7854f0bb676fe82

mpir

@@ -1 +1 @@
-Subproject commit 7e09c025f6061863e58a2cc0a0aefa8b5fa8496b
+Subproject commit 33be9007f95b85230da2330ef3ed525896370cc2

wxWidgets

@@ -1 +1 @@
-Subproject commit 14c6b431626b817bd7564f4ee3480299307533fa
+Subproject commit ddcb0472347dd08b76a34cc25db5ec0cc29f9abb