Added the design directory

Added the beginning of a write up for sockets
Extensively rewrote proof_of_share

docs/design/mkdocs.sh

@@ -0,0 +1,7 @@
+#!/bin/bash
+set -e
+cd `dirname $0`
+docroot="../"
+banner_height=banner_height:15ex
+templates=$docroot"pandoc_templates"
+. $templates"/mkdocs.cfg"

docs/design/navbar

@@ -0,0 +1,7 @@
+<div class="button-bar">
+  <a href="vision.html">vision</a>
+  <a href="scalability.html">scalability</a>
+  <a href="social_networking.html">social networking</a>
+  <a href="Revelation.html">revelation</a>
+</div>
+  

docs/design/peer_socket.md

@@ -0,0 +1,30 @@
+---
+# katex
+title: >-
+	Peer Socket
+sidebar: false
+notmine: false
+...
+
+::: myabstract
+[abstract:]{.bigbold}
+Most things follow the client server model, so it makes sense to have a distinction between server
+sockets and client sockets.  But ultimately what we are doing is passing messages between entities
+and the revolutionary and subversive technologies, bittorrent, bitcoin, and bitmessage are peer to
+peer, so it makes sense that all sockets, however created wind up with same properties.
+:::
+
+# factoring
+
+In order to pass messages, the socket has to know a whole lot of state.  And in order handle messages, 
+the entity handling the messages has to know a whole lot of state.  So a socket api is an answer
+to the question how we factor this big pile of state into two smaller piles of state.
+
+Each big bundle of state represents a concurrent communicating process.  Some of the state of this
+concurrent communicating process is on one side of our socket division, and is transparent to
+one side of our division. The application knows the internals of the some of the state, but the 
+internals of socket state are opaque, while the socket knows the internals of the socket state, but
+the internals of the application state are opaque to it.  For each of them, it is a pointer.  For the 
+socket code, a pointer to void, for the application code, a pointer to the opaque class peer::socket
+
+$$\lfloor{(h-1000)/4096}\rfloor*4096$$

docs/proof_of_share.md

@@ -10,11 +10,10 @@ protocol to the corporate form:]{style="font-size:150%"}
 The proof of share crypto currency will work like
 shares. Crypto wallets, or the humans controlling the wallets,
 correspond to shareholders.
-Peer computers in good standing on the blockchain, or the humans
-controlling them, correspond to company directors.
-CEO.
 :::
 
+# the problem to be solved
+
 We need proof of share because our state regulated system of notaries,
 bankers, accountants, and lawyers has gone off the rails, and because
 proof of work means that a tiny handful of people who are [burning a
@@ -113,6 +112,10 @@ lawyers each drawing \$300 per hour, increasingly impractical.
 Proof of work is a terrible idea, and is failing disastrously, but we
 need to replace it with something better than bankers and government.
 
+Proof of stake, as implemented in practice, is merely a
+central bank digital currency with the consensus determined by a small
+secretive insider group (hello Ethereum).
+
 The gig economy represents the collapse of the corporate form under the
 burden of HR and accounting.
 
@@ -120,6 +123,88 @@ The initial coin offering (in place of the initial public offering)
 represents an attempt to recreate the corporate form using crypto
 currency, to which existing crypto currencies are not well adapted.
 
+# How proof of share works
+
+One way out of this is proof of share, plus an incomplete,
+imperfect, and far from bulletproof proof of spacetime
+(disk access and cpu bandwidth) and an even more grossly imperfect
+and gameable proof of connectivity. You have a crypto currency
+that works like shares in a startup. Peers have a weight in
+the consensus, a likelihood of their view of the past becoming the
+consensus view, that is proportional to the amount of 
+crypto currency their client wallets possessed at a certain block height,
+$\lfloor(h−1000)/4096\rfloor∗4096$, where h is the current block height,
+provided they maintain adequate data, disk access,
+and connectivity. The trouble with this is that it reveals
+what machines know where the whales are, and those machines
+could be raided, and then the whales raided, so we have to have
+a mechanism that can hide the ips of whales delegating weight
+in the consensus to peers from the peers exercising that weight
+in the consensus. And in fact I intend to do that mechanism
+before any crypto currency, because bitmessage is abandonware
+and needs to be replaced.
+
+Plus the peers consense over time on a signature that
+represents human board, which nominates another signature that represents
+a human ceo, thus instead of informal secret centralisation with
+the capability to do unknown and possibly illegitimate things
+(hello Ethereum), you have a known formal centralisation with
+the capability to do known and legitimate things.  Dictating
+the consensus and thus rewriting the past not being one of those
+legitimate things.
+
+## algorithm details
+
+Each peer gets a weight at each block height that is a
+deterministically random function of the block height,
+its public the hash of the previous block that it is building its block
+on top of, and the amount of crypto currency (shares)
+that it represents, with the likelihood of it getting a high weight
+proportional to the amount of crypto currency it represents.
+
+Each peer sees the weight of a proposed block as
+the median weight of the three highest weighted peers
+that it knows know or knew of the block and its contents according to
+their current weight at this block height, plus the weight of
+the median weighted peer among up to three peers
+that were recorded by the proposer
+as knowing to the previous block that the proposed block
+is being built on at the previous block height, plus the
+weight of the chain of preceding blocks similarly.
+
+When it synchronizes with another peer on a block,
+both record the other's signature as knowing that block
+if it has a record of less than three knowing that block,
+or if the other has a higher weight than one of the three,
+and they also synchronize their knowledge of the highest weighted three.
+
+This algorithm favors peers that represent a lot of shares, and also
+favors peers with good bandwidth and data access, and peers that
+are responsive to other peers, since they have more and better connections
+thus their proposed block is likely become widely known faster.
+
+If only one peer, the proposer, knows of a block, then its weight is 
+the weight of the proposer, plus previous blocks but is lower than
+the weight if any alternative block whose previous blocks have the 
+same weight, but two proposers.
+
+This rule biases the consensus to peers with good connection and
+good bandwidth to other good peers.
+
+If comparing two proposed blocks, each of them known to two proposers, that
+have chains of previous blocks that are the same weight, then the weight
+is the lowest weighted of the two, but lower than any block known to 
+three.  If known to three, the median weight of the three. If known to
+a hundred, only the top three matter and only the top three are shared
+around.
+
+It is thus inherently sybil proof, since if one machine is running
+a thousand sybils, each sybil has one thousandth the share
+representation, one thousandth the connectivity, one thousandth 
+the random disk access, and one thousandth the cpu.
+
+# Collapse of the corporate form
+
 The corporate form is collapsing in part because of [Sarbanes-Oxley],
 which gives accountants far too much power, and those responsible for
 deliverables and closing deals far too little, and in part because HR