add file browser component and widget

examples/file_browser_demo/mock-server/mock_files/README.md

@@ -0,0 +1,3 @@
+# File Browser Demo
+
+This is a sample file for testing the file browser component.

examples/file_browser_demo/mock-server/mock_files/design.md

@@ -0,0 +1,59 @@
+# 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.

examples/file_browser_demo/mock-server/mock_files/documents/notes.txt

@@ -0,0 +1 @@
+Sample notes file content.

examples/file_browser_demo/mock-server/mock_files/documents/report.md

@@ -0,0 +1,3 @@
+# Sample Report
+
+This is a sample markdown report.

examples/file_browser_demo/mock-server/mock_files/images/placeholder.txt

@@ -0,0 +1 @@
+Placeholder for image files.

examples/file_browser_demo/mock-server/mock_files/projects/config.json

@@ -0,0 +1 @@
+{"name": "sample-project", "version": "1.0.0"}

examples/file_browser_demo/mock-server/mock_files/projects/design.md

@@ -0,0 +1,59 @@
+# 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.

examples/file_browser_demo/mock-server/mock_files/projects/project1.md

@@ -0,0 +1,3 @@
+# Project 1
+
+Sample project documentation.

examples/file_browser_demo/mock-server/mock_files/projects/system_requirements_spec.md

@@ -0,0 +1,50 @@
+# System Requirements Specification
+
+## Objective
+
+To define the core requirements for a system that fulfills the goals of decentralized backend ownership — enabling individuals and organizations to control, operate, and interact through their own backend environments without relying on centralized infrastructure.
+
+## Functional Requirements
+
+### 1. **Isolated Execution Contexts**
+- Each user or peer must operate within a distinct, logically isolated execution context.
+- Contexts must not be able to interfere with each other's state or runtime.
+
+### 2. **Cross-Context Communication**
+- Peers must be able to initiate interactions with other peers.
+- Communication must include origin metadata (who initiated it), and be authorized by the target context.
+
+### 3. **Delegated Execution**
+- A peer must be able to send code or instructions to another peer for execution, under the recipient's policies.
+- The recipient must treat the execution as contextualized by the caller, but constrained by its own local rules.
+
+### 4. **Ownership of Logic and Data**
+- Users must be able to inspect, modify, and extend the logic that governs their backend.
+- Data storage and access policies must be under the control of the peer.
+
+### 5. **Composability and Modifiability**
+- System behavior must be defined by open, composable modules or scripts.
+- Users must be able to override default behavior or extend it with minimal coupling.
+
+## Non-Functional Requirements
+
+### 6. **Security and Isolation**
+- Scripts or instructions from external peers must be sandboxed and policy-checked.
+- Each execution context must enforce boundaries between data and logic.
+
+### 7. **Resilience and Redundancy**
+- Failure of one peer or node must not impact others.
+- Communication must be asynchronous and fault-tolerant.
+
+### 8. **Portability**
+- A peer’s logic and data must be portable across environments and host infrastructure.
+- No assumption of persistent centralized hosting.
+
+### 9. **Transparency**
+- All logic must be auditable by its owner.
+- Communications between peers must be observable and traceable.
+
+### 10. **Scalability**
+- The system must support large numbers of peer contexts, potentially hosted on shared infrastructure without compromising logical separation.
+
+These requirements define the baseline for any system that claims to decentralize backend control and empower users to operate their own programmable, connected environments.

examples/file_browser_demo/mock-server/mock_files/projects/why.md

@@ -0,0 +1,34 @@
+# Rethinking Backend Ownership
+
+## Motivation
+
+Modern applications are powered by backends that run on infrastructure and systems controlled by centralized entities. Whether it's social platforms, collaboration tools, or data-driven apps, the backend is almost always a black box — hosted, maintained, and operated by someone else.
+
+This has profound implications:
+
+- **Loss of autonomy:** Users are locked out of the logic, rules, and data structures that govern their digital experience.
+- **Opaque control:** Application behavior can change without the user’s consent — and often without visibility.
+- **Vendor lock-in:** Switching providers or migrating data is often non-trivial, risky, or impossible.
+- **Security and privacy risks:** Centralized backends present single points of failure and attack.
+
+In this model, users are not participants in their computing environment — they are clients of someone else's backend.
+
+## The Vision
+
+The purpose of this initiative is to invert that dynamic. We aim to establish a paradigm where users and organizations **own and control their own backend logic and data**, without sacrificing connectivity, collaboration, or scalability.
+
+This means:
+
+- **Local authority:** Each user or organization should have full control over how their backend behaves — what code runs, what data is stored, and who can access it.
+- **Portable and interoperable:** Ownership must not mean isolation. User-owned backends should be able to interact with one another on equal footing.
+- **Transparent logic:** Application behavior should be visible, inspectable, and modifiable by the user.
+- **Delegation, not dependence:** Users should be able to cooperate and interact by delegating execution to each other — not by relying on a central server.
+
+## What We Stand For
+
+- **Agency:** You control your digital environment.
+- **Decentralization:** No central chokepoint for computation or data.
+- **Modularity:** Users compose their backend behavior, not inherit it from a monolith.
+- **Resilience:** Systems should degrade gracefully, fail independently, and recover without central orchestration.
+
+This is about building a more equitable and open computing model — one where the backend serves you, not the other way around.

examples/file_browser_demo/mock-server/mock_files/sample.txt

@@ -0,0 +1 @@
+This is a sample text file.

examples/file_browser_demo/mock-server/mock_files/system_requirements_spec.md

@@ -0,0 +1,50 @@
+# System Requirements Specification
+
+## Objective
+
+To define the core requirements for a system that fulfills the goals of decentralized backend ownership — enabling individuals and organizations to control, operate, and interact through their own backend environments without relying on centralized infrastructure.
+
+## Functional Requirements
+
+### 1. **Isolated Execution Contexts**
+- Each user or peer must operate within a distinct, logically isolated execution context.
+- Contexts must not be able to interfere with each other's state or runtime.
+
+### 2. **Cross-Context Communication**
+- Peers must be able to initiate interactions with other peers.
+- Communication must include origin metadata (who initiated it), and be authorized by the target context.
+
+### 3. **Delegated Execution**
+- A peer must be able to send code or instructions to another peer for execution, under the recipient's policies.
+- The recipient must treat the execution as contextualized by the caller, but constrained by its own local rules.
+
+### 4. **Ownership of Logic and Data**
+- Users must be able to inspect, modify, and extend the logic that governs their backend.
+- Data storage and access policies must be under the control of the peer.
+
+### 5. **Composability and Modifiability**
+- System behavior must be defined by open, composable modules or scripts.
+- Users must be able to override default behavior or extend it with minimal coupling.
+
+## Non-Functional Requirements
+
+### 6. **Security and Isolation**
+- Scripts or instructions from external peers must be sandboxed and policy-checked.
+- Each execution context must enforce boundaries between data and logic.
+
+### 7. **Resilience and Redundancy**
+- Failure of one peer or node must not impact others.
+- Communication must be asynchronous and fault-tolerant.
+
+### 8. **Portability**
+- A peer’s logic and data must be portable across environments and host infrastructure.
+- No assumption of persistent centralized hosting.
+
+### 9. **Transparency**
+- All logic must be auditable by its owner.
+- Communications between peers must be observable and traceable.
+
+### 10. **Scalability**
+- The system must support large numbers of peer contexts, potentially hosted on shared infrastructure without compromising logical separation.
+
+These requirements define the baseline for any system that claims to decentralize backend control and empower users to operate their own programmable, connected environments.

examples/file_browser_demo/mock-server/mock_files/why.md

@@ -0,0 +1,34 @@
+# Rethinking Backend Ownership
+
+## Motivation
+
+Modern applications are powered by backends that run on infrastructure and systems controlled by centralized entities. Whether it's social platforms, collaboration tools, or data-driven apps, the backend is almost always a black box — hosted, maintained, and operated by someone else.
+
+This has profound implications:
+
+- **Loss of autonomy:** Users are locked out of the logic, rules, and data structures that govern their digital experience.
+- **Opaque control:** Application behavior can change without the user’s consent — and often without visibility.
+- **Vendor lock-in:** Switching providers or migrating data is often non-trivial, risky, or impossible.
+- **Security and privacy risks:** Centralized backends present single points of failure and attack.
+
+In this model, users are not participants in their computing environment — they are clients of someone else's backend.
+
+## The Vision
+
+The purpose of this initiative is to invert that dynamic. We aim to establish a paradigm where users and organizations **own and control their own backend logic and data**, without sacrificing connectivity, collaboration, or scalability.
+
+This means:
+
+- **Local authority:** Each user or organization should have full control over how their backend behaves — what code runs, what data is stored, and who can access it.
+- **Portable and interoperable:** Ownership must not mean isolation. User-owned backends should be able to interact with one another on equal footing.
+- **Transparent logic:** Application behavior should be visible, inspectable, and modifiable by the user.
+- **Delegation, not dependence:** Users should be able to cooperate and interact by delegating execution to each other — not by relying on a central server.
+
+## What We Stand For
+
+- **Agency:** You control your digital environment.
+- **Decentralization:** No central chokepoint for computation or data.
+- **Modularity:** Users compose their backend behavior, not inherit it from a monolith.
+- **Resilience:** Systems should degrade gracefully, fail independently, and recover without central orchestration.
+
+This is about building a more equitable and open computing model — one where the backend serves you, not the other way around.