|
|
@@ -1,3 +1,99 @@
|
|
|
+### Project Road Map
|
|
|
+In broad strokes, theses are the phases of development.
|
|
|
+
|
|
|
+## Phase 1: Foundations
|
|
|
+* Definition of the main data types.
|
|
|
+* Definition of the binary format used to serialize all data structures.
|
|
|
+* Creation of a cryptographic abstraction layer which will defer to openssl for the time being.
|
|
|
+This module will include type definitions for hashes, keys and signatures. It will define
|
|
|
+functions for:
|
|
|
+ 1. Symmetric encryption and decryption.
|
|
|
+ 2. Asymmetric encryption and decryption.
|
|
|
+ 3. Asymmetric signing and verification.
|
|
|
+ 4. Higher level functions for operating on blocks, read caps and write caps.
|
|
|
+* Implementation of a block manager for persisting blocks to disk and retrieving them when needed.
|
|
|
+We need to make sure the page cache is being used while doing IO here.
|
|
|
+* Implementation of a cache for block keys.
|
|
|
+* Definition of an RPC interface for sending commands to and receiving responses from a node via
|
|
|
+ stdin.
|
|
|
+* Creation of a crate called `harness` for running nodes as child processes and communicating with
|
|
|
+them. This crate must define high level functions for:
|
|
|
+ 1. Preparing a directory for a new node.
|
|
|
+ 2. Starting a node.
|
|
|
+ 3. Sending commands to a node.
|
|
|
+* Creation of a crate called `test-harness` which uses `harness` to write tests for nodes. This
|
|
|
+crate should be capable of starting multiple nodes to test their interaction.
|
|
|
+
|
|
|
+## Phase 2: Networking
|
|
|
+* Definition of the data structures sent as messages over the network.
|
|
|
+* Implementation of a listener in the node which processes these messages.
|
|
|
+* Notifying other nodes when a block has been written.
|
|
|
+* Implementing distributed locking via leader election.
|
|
|
+
|
|
|
+## Phase 3: Programming Interface
|
|
|
+* Define a package format for user code. This should consist of a WebAssembly binary along with
|
|
|
+a manifest containing metadata about it, such as which principal authored it and which
|
|
|
+permissions the app is requesting. This manifest must be cryptographically signed.
|
|
|
+* Define an API for user code and which exposes the following capabilities:
|
|
|
+ 1. Read and write blocks (with permissions checks).
|
|
|
+ 2. Send messages to other nodes (which may or may not be in the same tree).
|
|
|
+ 3. Lock a file for exclusive access.
|
|
|
+ 4. Register a callback for when a file is modified by someone else.
|
|
|
+ 5. Make HTTP requests.
|
|
|
+ 6. Register callbacks to handle HTTP requests.
|
|
|
+ 7. Open arbitrary network sockets.
|
|
|
+(Should this API extend WASI?)
|
|
|
+* Implement a crate which can run WebAssembly code in a sandbox.
|
|
|
+* Define an IPC interface between the sandbox and the node.
|
|
|
+
|
|
|
+## Phase 4: Blockchain
|
|
|
+* Define the data structures needed to construct a blockchain.
|
|
|
+* Implementation the mining algorithm in the node networking module.
|
|
|
+* Implementation of the logic needed to determine the level of redundancy desired for a given block.
|
|
|
+* Implementation an abstraction layer for Erasure Encoding. Define high level functions for creating
|
|
|
+Fragments from a Block.
|
|
|
+* Implementation of the advertising, negotiation and agreement process by which nodes store
|
|
|
+fragments with other nodes.
|
|
|
+* Implementation a Fragment manager in node which handles persisting fragments to the
|
|
|
+filesystem and retrieving them when needed.
|
|
|
+* Registering an endpoint (IP address and port) for a principal.
|
|
|
+* Creation of an index which is created from the block tree and which allows efficient look up of
|
|
|
+node IP addresses and the holders of the fragments created by a given path. This index is updated
|
|
|
+every time a new block is added.
|
|
|
+* When a new block is added, the transaction fees from it are collected and new currency is created
|
|
|
+for each new fragment which is stored. These funds are then transferred to the principal who
|
|
|
+mined the new block.
|
|
|
+
|
|
|
+## Phase 5: Integration
|
|
|
+* A webapp which provides a user interface for nodes. This should be able to:
|
|
|
+ 1. Create a new root key.
|
|
|
+ 2. Backup and restore a password protected root key to external storage.
|
|
|
+ 3. View and approve write cap requests.
|
|
|
+* Creation of a linux distribution to run the node and webapp.
|
|
|
+* A FUSE filesystem daemon for mounting a block tree in a filesystem.
|
|
|
+* An Android app which runs a node.
|
|
|
+
|
|
|
+## Phase 6: Essential Applications
|
|
|
+* App for visualizing and managing a block tree.
|
|
|
+* A contacts app.
|
|
|
+* An object oriented database.
|
|
|
+* A micro-blogging app.
|
|
|
+* A picture/video app.
|
|
|
+* A voice/video chat app.
|
|
|
+
|
|
|
+## Phase 7: Hardware
|
|
|
+* Design and manufacture a router with a hard drive that runs the linux distribution created
|
|
|
+previously.
|
|
|
+* Create a custom Android distribution which runs a node on start up.
|
|
|
+* Design and manufacture a phone which runs this Android distribution.
|
|
|
+
|
|
|
+## Phase 8: The Multiverse
|
|
|
+* Create an app which functions as a server for a metaverse. This app will manage objects in a
|
|
|
+metaverse.
|
|
|
+* Create a client that run under Windows. The client will be responsible for rendering the object
|
|
|
+data it receives from the app and updating objects based on user input. This client must have VR
|
|
|
+and mouse and keyboard support.
|
|
|
+
|
|
|
### Outline of paper
|
|
|
|
|
|
*Overview
|
Matthew Carr