# 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.