59 lines
2.5 KiB
Markdown
59 lines
2.5 KiB
Markdown
# 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. |