diff --git a/README.md b/README.md
index e5eaff9..fcee75e 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,58 @@
-# rhizome-network
+What are the benefits we seek by networking?
+---
+
+Another node can provide accountability -- are we accessible to the outside world? Do our results agree with others?
+Schedule a task to be performed when we may not be available -- nodes can coordinate and attempt to ensure the task is performed!
+Store backup copies of our data -- if we consider some data valuable, we want to protect its continuity! -- integrity, availability
+We can benefit from innovations that others may share with us! -- algorithms, data, commentary
+We have a potential audience for our contributions -- we may be heard and can receive feedback
+Networking can help us handle more demand for our services
+than we can provide with a single node, or even with all the nodes we can muster!
+
+How can we structure the application?
+---
+
+Each node may have
+- storage read, write
+- network egress, ingress
+- system RAM read, write
+- CPU operations, cycles
+- graphics RAM read, write
+- GPU operations, cycles
+
+Application will need its own core operational data store. This can be achieved by a variety of means.
+- in-memory
+- on disk -- json, sqlite, leveldb
+- separate db -- postgres, redis, etc...
+
+Nodes should be able to engage in clustering configurations, perhaps especially those in close physical/virtual proximity.
+
+So let's take an example node with some local storage, RAM, CPU, and network.
+Let us take as the foundation of our data model, the "rhizomatic database" structure, which can be summarized as follows: 
+
+We establish a key space which we refer to as "domain entities".
+Each domain entity is identified by a unique key, e.g. a UUID;
+A node may curate one or more collection of "deltas".
+Each delta contains a set of "pointers".
+To obtain views of the domain entities, "lossless" or "lossy" reducers may be applied to a (filtered) set of deltas.
+Each pointer contains a "local context", "target", and "target context".
+Each domain entity is modeled as having a set of "properties", where each property is a key-value pair.
+Pointers are interpreted as assertions about the values of domain entiity properties.
+A lossless view shows all the values asserted by each relevant delta in the (filtered) set.
+A lossy view uses a given reducer to resolve each requested domain entity property to a value.
+
+The first domain entities we need to model are our network peers -- other possible rhizome nodes.
+There is a balance to manage. We must not make unwarranted assumptions about out network peers.
+However, we are seeking a situation where we benefit by mutual trust among at least some network peers.
+So we will want to keep track of information we gather that may affect our evaluation of the trustworthiness of a given peer.
+That also raises the question of how we want to think about identifying peers.
+Of course, asymmetric key cryptography: we identify a peer by using their public key to check their signatures.
+
+Applications will interface with one or more nodes, and use the information obtained to make decisions;
+including the option of further participation in the network; how clear is the distinction between node and application?
+I think this base layer of rhizome nodes should integrate into the storage, computation, and networking...
+Services can interface with the rhizome layer; the rhizome network may be used to support other functionality.
+The service may also perform some rhizome network function, perhaps indirectly supporting other services.
+
+
 
-Specifying the rhizomatic protocol by which nodes may interact
\ No newline at end of file