Finished first editing pass on the "paper".

doc/Paper/Paper.tex

@@ -23,12 +23,12 @@ the details of backing up user data and implementing access controls to facilita
 safe sharing. However, because these are closed systems, users are forced to trust that
 the operators are benevolent, and they lack any real way of ensuring that the access
 controls they prescribe will actually be enforced. There have been several systems proposed
-as an alternative to the conventional model, but these systems suffer from several shortcommings.
+as an alternative to the conventional model, but these systems suffer from several shortcomings.
 They either assume the need for cloud storage providers (Blockstack) or implement all operations
 using a global blockchain, limiting performance (Filecoin). Blocktree takes a different approach.
 
 The idea behind blocktree is to organize a user's computers into a cooperative unit, called a
-blocktree. The user is said to own the blocktree, and they wield soveriegn authority over it.
+blocktree. The user is said to own the blocktree, and they wield sovereign authority over it.
 The artifact granting them this authority is the root private key for the blocktree. Measures for protecting
 this key and delegating its authority are important design considerations of the system.
 The owners of blocktrees are encouraged to collaborate with each other to replicate data by
@@ -102,7 +102,7 @@ specified when they are issued. These intermediaries can then delegate this trus
 A block is considered valid if it contains a valid writecap, it was signed using the key
 corresponding to the first writecap's public key, and this signature is valid.
 
-Blocks are used for more than just orgnaizing data, they also organize computation. A program
+Blocks are used for more than just organizing data, they also organize computation. A program
 participating in a blocktree is referred to as a node. Multiple nodes may be run on
 a single computer. Every node is attached to the blocktree at a specific path. This information
 is recorded in the directory where the node is attached. A node is responsible for the storage of
@@ -144,7 +144,7 @@ cryptosystem. In blocktree the compromise of a node key is handled by re-keying
 the block where the node was attached. Specifically, this means that a new block key is generated for
 each block, and the readcap for the compromised node is removed. This ensures that new writes to
 these blocks will not be visible to the holder of the compromised key. To ensure that writes
-will not be allowed, the root directory contains a revokation list containing the public keys
+will not be allowed, the root directory contains a revocation list containing the public keys
 which have been revoked by the tree. These only need to be maintained until their writecaps
 expire, after which time the list can be cleaned. Note that if the root private key is compromised or lost,
 then the blocktree must be abandoned, there is no recovery. This is real security, the artifact
@@ -227,7 +227,7 @@ determine the set of nodes which contain the fragments of any given path.
 
 In order for the node which stored a fragment to receive its next payment, it has to pass
 a time-bound challenge-response protocol initiated by the node that owns the fragment.
-The owning node select a leaf in the Merkel tree of the fragment and sends the index of
+The owning node select a leaf in the Merkle tree of the fragment and sends the index of
 this leaf to the storing node. The storing node then walks the path from this leaf back to
 the root of the Merkle tree, and updates a hash value using the data in each node it traverses.
 It sends this result back to the owning node which verifies that this value matches its
@@ -374,10 +374,11 @@ it would be inadvisable for the root private key to be stored on a user's mobile
 address this mailbox directories are created.
 
 For each contact two directories are created: the inbox and the outbox. The user creates a readcap
-for another user's root key and adds it to the outbox. The inbox is a symbolic link to the user's
-outbox in the blocktree of the other user. Thus each user
+for another user's root key and adds it to their outbox. The inbox for the other user is a symbolic
+link to the user's outbox in the blocktree of the other user. Thus each user
 can write messages into their own blocktree at a location where the other party knows how
-to find them. But, in order for a node to read these messages it requires a its own readcap. Only the root
+to find them. But, in order for a node to read these messages it requires a its own readcap.
+Only the root
 nodes can issue this readcap as only they have access to the root key. Once permission has been
 granted to a node, a root node can use the root key to decrypt the readcap issued to it, and then
 encrypt it using the public key of the node. The resulting readcap is then stored in the header
@@ -390,14 +391,11 @@ the message just serves as a notification that new mail is available.
 
 \subsection{Social Network}
 Building a social network on top of the contacts app is fairly straight-forward. Once
-an contacts entry has been created for a person, most interactions between the user and that
-person can be implemented via messages passed between their mailboxes. For example, when the
-user sends a direct message to the person a message is placed in the outbox for that person
-and a blocktree message is sent to the root cluster of their blocktree. If this message was
-meant for a group of people it could placed in the outboxes of each one. These messages need
-not be restricted to text, images, video, or any other kind of data could be included in them.
-If a large amount of data is to be shared this way (for instance a video), then it makes sense
-to only include the blocktree path to it in the notification messages sent to the recipients.
+a contacts entry has been created for a person, most interactions between the user and that
+person can be implemented by sending mail. For example, when the
+user sends a direct message to a person mail is placed in their outbox
+and a blocktree message is sent to the root cluster of their blocktree. If the user wishes to 
+send a message to a group of people, mail is sent to each one.
 
 This same mechanism can be used to implement status updates. When a user updates their status,
 they send mail to each of their "friends". The social networking app running on each of the contacts'
@@ -409,14 +407,14 @@ is a symbolic link to a single status update block. This symbolic link contains
 readcap for the status update block.
 
 Comments and likes on status updates are implemented by sending mail to the user who posted the
-update. When one of the user's nodes recieves this mail, it then updates the block containing
-the status update with the new comment, or increments the like counter (dislikes should not be supported IMHO).
-It then sends a blocktree message to the people this status update was shared with notifiying them
+update. When one of the user's nodes receives this mail, it then updates the block containing
+the status update with the new comment, or increments the like counter.
+It then sends mail to the people this status update was shared with, notifying them
 that the data has changed.
 
-\subsection{An ecomerce website.}
+\subsection{An e-commerce website.}
 The previous two examples show how to build decentralized versions of existing web applications,
-but blocktree also excells at building traditional web applications. Imagine an ecommerce website,
+but blocktree also excels at building traditional web applications. Imagine an e-commerce website
 with multiple warehouses, all of whose inventory is to be visible to customers of the site. Part
 of the design consideration for the site is that the warehouses need to be able to update their
 inventory even when their internet service goes down, and that these updates need to be visible
@@ -427,45 +425,53 @@ nodes attached to it that are physically located at each warehouse. The inventor
 is then maintained in the warehouse's directory, satisfying the first requirement. Now, in order to
 enable efficient queries of the overall available inventory, the data from each of the warehouses
 needs to be merged. This is accomplished by creating another directory containing the merged data.
-In event sourcing terms this is called a read-model. This directory will have another cluster of nodes attached
-which will act as web servers. These nodes will subscribe to events published by the warehouse
-clusters, events indicating chaging levels of inventory, and digest this information into a format
-that can be efficiently queried. When a warehouse goes offline, it previous levels of inventory are
-still recorded in the read-model, so queries can still be answered using the cluster best knowledge
-of the warehouse. Once the warehouse comes back online, then the events that were recorded by the
+In event sourcing terms this is called a read-model. This directory will have another cluster of
+nodes attached which will act as web servers. These nodes will subscribe to events published by the
+warehouse clusters, events indicating changing levels of inventory, and digest this information into
+a format that can be efficiently queried. These nodes will also publish events to the warehouses
+when orders are placed, cancelled or amended.
+
+When a warehouse goes offline, its previous inventory counts are
+still recorded in the read-model, so queries can still be answered using the cluster's best
+knowledge of the warehouse. Once the warehouse comes back online, then the events that were recorded by the
 warehouse cluster while it was offline can be replayed to the web server cluster, and their read-model
 can be brought up to date.
 
-One of the advantages of this approach is that the cluster of webservers need not be physically
-close to each other. In fact they could be spread over several datacenters, or even in different
+One of the advantages of this approach is that the cluster of web servers need not be physically
+close to each other. In fact they could be spread over several data centers, even in different
 cloud providers. This allows for greater fault tolerance and reliability. Of course, running a
-consenus cluster over a larger area means more latency and thus reduced performance, but if
-the workload is read-heavy, and writes can be handled in the warehouse clusters, then this
+consensus cluster over a larger area means more latency and thus reduced performance, but if
+the workload is read-heavy, and writes can be handled mostly in the warehouse clusters, then this
 tradeoff may be worthwhile.
 
 I hope this example shows that having a standard format for data and the federation of servers,
 can provide designers with much greater flexibility, even if they do not care about decentralization
 or their user's privacy.
 
-\subsection{The Metaverse}
+\subsection{The Open Metaverse}
 As a final example I'd like to consider a platform for recording spacial information. The key insight
 that enables this is very general: blocktree enables the creation of distributed tree-like data structures.
 For instance, its straight forward to imagine creating a distributed hashtable implemented as a red-black tree.
-This impedence match between efficient query structures and the design of blocktree is one
-of the reasons why I believe it is so useful. The particular datastructure germane to building the metaverse
+This impedance match between efficient query structures and the design of blocktree is one
+of the reasons why I believe it is so useful. The particular data structure germane to building the metaverse
 is the Binary Space Partition (BSP) tree.
 
 I don't see the metaverse as being one world, but rather many. Each world would be hosted by its own blocktree.
-The world will have a directory in the blocktree, that directory will be the root of a BSP. Thinking of worlds
-like ours, those that can be resonably approximated as the surface of a sphere, we can impose the usual latitude
+The world will have a directory in the blocktree, that directory will be the root of a BSP. read
+access to the world is controlled by adding readcaps to this directory. If the world is to be
+publicly accessible, then then its block can be stored in plaintext.
+
+Thinking of worlds
+like ours (those that can be reasonably approximated as the surface of a sphere) we can impose the usual latitude
 and longitude coordinate system. We can then define parcels in the world by specifying the polygonal boundary as
-a set of these coordinates (more preciesely, the parcel is the convex hull of this set of points). These parcels
-are then recorded as blocks in the world's directory, whose path is determined by its virtual location. If a parcel
+a set of these coordinates (more precisely, the parcel is the convex hull of this set of points). These parcels
+are then recorded as blocks in the world's directory, whose path is determined by its virtual location using
+the BSP algorithm. If a parcel
 is owned by the same user who owns the world, then the data contained in the parcel is stored in
-the same blocktree. However, if a parcel is to be owned by another user, then a symbollic link is created
+the same blocktree. However, if a parcel is to be owned by another user, then a symbolic link is created
 pointing to a block in the owner's blocktree. They can then write whatever data they want into this block, defining
-the contents of their parcel. Collaboration on a single parcel is accomplished by issuing a writecap to
-another user. 
+the contents of their parcel. Collaboration on a single parcel is accomplished by issuing a read and writecap to
+another user.
 
 It's easy to imagine that one world would be more important than the rest and that he creation of a metaverse 
 representation of Earth will be an important undertaking. The hierarchical nature of permissions in blocktree
@@ -481,7 +487,7 @@ In this paper I have given the outline of a decentralized method of organizing i
 and trust in a way that I hope will be useful and easy to use. The use of cryptographic primitives for
 implementing access control were discussed, as well as methods of protecting private keys. A blockchain
 and corresponding cryptocurrency was proposed as a means of incentivizing the distribution of data.
-Erasure coding was used to ensure that distributed data could be reslient to the loss of nodes and
+Erasure coding was used to ensure that distributed data is resilient to the loss of nodes and can be
 reconstructed efficiently. A programming environment based on WASM and WASI was proposed as a way
 of providing an interface to this data. APIs for defining protocol contracts and efficient web servers
 were indicated. APIs for constructing supervision trees were mentioned as a means for building reliable