Design

Overview

This document outlines a system design that satisfies the specified requirements for decentralized backend ownership. It describes how to implement core capabilities like isolation, delegation, and open logic control — without introducing tight coupling or central dependencies.

Design Principles

1. Contextual Execution

Define a runtime model where each peer context is a named environment.
Execution is scoped to a context, and all operations are resolved within it.

Implementation Strategy:

Use a unified worker engine that can load and execute within a namespaced peer context.
Contexts are mounted via a virtual filesystem abstraction, one directory per peer.

2. Logical Isolation via Filesystem Namespacing

Each peer's execution environment is backed by a namespaced root directory.
All storage operations are relative to that root.

Advantages:

Easy enforcement of data boundaries
Works across shared processes

3. Script-Based Delegated Execution

Scripts are the unit of cross-peer interaction.
A script includes the caller (originating peer), parameters, and logic.

Design Feature:

A script sent to another peer is evaluated with both caller and target contexts available to the runtime.
Target peer decides whether to accept and how to interpret it.

4. Policy-Driven Acceptance

Each context has policies determining:
- Which peers may send scripts
- Which actions are allowed

Example: Policies written as declarative access control rules, tied to peer IDs, namespaces, or capabilities.

5. Open, Modifiable Logic

Use an embedded domain-specific language (e.g. Rhai) that allows:
- Peer owners to define and inspect their logic
- Script modules to be composed, extended, or overridden

6. Worker Multiplexing

Use a single worker binary that can handle one or many peer contexts.
The context is dynamically determined at runtime.

Design Note:

All workers enforce namespacing, even when only one peer is active per process.
Supports both isolated (1 peer per worker) and shared (many peers per worker) deployments.

Optional Enhancements

Pluggable transport layer (WebSocket, HTTP/2, NATS, etc.)
Pluggable storage backends for namespace-mounting (FS, S3, SQLite, etc.)
Declarative schema binding between DSL and structured data

This design enables decentralized application runtime control while supporting a scalable and secure execution model.

2.5 KiB Raw Blame History