Overview
ArtRiver is, almost by definition, a distributed system, intended to allow for for a combination of local-first, peer-to-peer and semi-centralized functionality (as made ubiquitous by Git), for individuals or circumstances that require such.
An individual should be able to launch a project, which can be written to, so to speak, by any node they choose to allow, or be made publicly available.
Every node that is invited will have the entirety of the project state and history written to it, so that they can reproduce states of the project that proceeded the state it was in when they were given access to it 1.
Peer nodes can exchange changes from TimeShores to be applied between each ArtRiver as they wish, before finalizing it into the Glacier state according to their collaborative agreements 2.
This allows for unrestrained creative exploration, collaboration, innovative attribution, without sacrificing control of their IP (in fact this can be enhanced through fine-grained rules executed by the ACE (Access Control Engine).
Core Distributed Foundations
As a local first, peer-to-peer tool for singular and collaborative projects, it's feasible ArtRiver will leverage at minimum, one or more, the following concepts, tools or technologies.
Content-Addressable Storage: In a meaningful sense, CAS is a prerequisite, due to the end goals of ArtRiver. Software objects such as files, logs, and metadata can be hashed to produce indexes that makes replication and verification minor tasks.
CRDTs: One of the highest aspirations for ArtRiver as a collaborative tool is to allow artists to exchange, store and retrieve changes, be they granular or specific to only a portion of the project (or its files). Operation-based CRDTs 3 allow for guarantees that replicas can be made consistent from divergent states, without regard to the order in which operations are received, syncing isolated units of change as opposed to the entirety of the projects state 4.
Networking and Inter-process Communication
ArtRiver will require a robust networking layer, and will no doubt rely on libp2p and the broader ecosystem for implementing core parts of peer to peer networking, such as peer discovery, NAT traversal, and transports.
Inter-process Communication is going to be one of the more interesting and perhaps involved concepts to leverage here: the full fledged implementation is going to need to communicate with DAWs, their internal plugins, the network, as well as the operating system. This will require further research and experimentation, but for now (g)RPC will be used to transport data over the wire, and intra-machine IPC will explore tried and true methods, such as concurrency primitives (locks, mutexes, etc) and IPC techniques and concepts (message queues, shared memory).
Consensus, Failure and Fault Tolerance
A number of the most prominent consensus algorithms come with high implementation complexity, due to the consistency capabilities it provides. At present it is not unreasonable to assume ArtRiver will not have to meet such an exacting standard, due to the use of CRDTs (or related concepts), making leader elections and voting unnecessary.
By way of the P2P+CRDT model, nodes going offline pose no problem as synchronization occurs upon rejoining the network: should said network contain a partition, there is no risk of split brain. Lastly, content-addressing resolves a number of issues, such as data corruption, malicious code/data, and potentially even provenance.
It has occurred to me, creatives may wish to share a project from a given point only, and not have previous states accessible to future collaborators. In all likelihood this functionality will be provided by the ACE.↩
This, again, will likely be handled by the Access Control Engine, however it also can present a consensus issue, that will have to be resolved.↩
An area of contention here will be that changes to audio may not always be operations that satisfy associativity, commutativity, and idempotency. When they are and aren't and how to handle that if so requires further research.↩
I will admit, there is a bit of shiny new thing syndrome here, but not so much that I won't ditch them if necessary.↩