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!

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.

Algorithms

Multi-party Informed by peer model

JSON-Logic can encode condition expressions. It can also encode transformations, or other operations.

Composable, functional units -- no side-effects (need to think about data structures for this)

Algorithms encode rules for decisions. When executed, these decisions can lead to actions.

Provenance is a fundamental consideration in this system. We don't need to require certainty. Instead, we can quantify our uncertainty.

An example algorithm would be one for identity. An algorithm for performing a query. An algorithm for operating a service cluster; let's say a web service.

Context roots, being UUIDs, are the initial point of coordination with regard to domain entities. But also, provenance is indeed a fundamental consideration, and as such, the context is marshalled by applying a filter to a set of deltas, which may filter based on creator and host. Decisions about such filtering depends on the node's view of its peers.