diff --git a/README.md b/README.md index 932a3fe..f184079 100644 --- a/README.md +++ b/README.md @@ -1,14 +1,14 @@ 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! -Or similarly, to perform more computations in a given amount of time! +- 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! +- Or similarly, to perform more computations in a given amount of time! How can we structure the application? --- @@ -29,25 +29,25 @@ Application will need its own core operational data store. This can be achieved 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. +- 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?