82 lines
4.4 KiB
Markdown
82 lines
4.4 KiB
Markdown
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.
|
|
|