add solid principle of owning your own data (not apps)

Author: devalbo

AGENTS.md

@@ -7,6 +7,7 @@ Context for AI assistants working on this repo.
 **tb-solid-pod** is a browser-based personal data pod inspired by the [Solid Project](https://solidproject.org/), built with [TinyBase](https://tinybase.org/) for reactive state and LocalStorage. It is **not** a real Solid server (no LDP, no WebID-TLS); it simulates Solid-style data (personas, contacts, groups, type indexes, file metadata) in a single-page app.
 
 - **Dual interface**: graphical UI (tabs, forms, lists) + CLI. The CLI runs in the **browser** (Terminal tab) and in **Node** (`npm run cli`); same commands, environment-specific persistence (LocalStorage vs `~/.tb-solid-pod/data/store.json`).
+- **App-neutral data store**: In the Solid vision, your data belongs to you—not to any particular app. This project embraces that principle: whether you prefer a browser UI (no install, instant access from any device with a modern browser) or a terminal app (scripting, automation, headless operation, CI/CD pipelines), you work with the same data through the same commands. The interface is a matter of preference and context; the data is yours regardless of how you access it.
 - **Unified CLI = Agent API**: The same CLI commands work as a programmatic API for AI coding agents. No custom SDK—agents issue CLI commands (`create-persona`, `list-contacts`, `export`) in browser or terminal. See [Principles and Goals](docs/PRINCIPLES_AND_GOALS.md) for the full vision.
 - **Data**: personas (WebID-style), contacts (including agents), groups (org/team/group) with membership of contacts and your personas, type indexes, virtual file system with metadata, settings/preferences.
 - **Stack**: React, TinyBase, Zod, Vite, TypeScript. Vocabularies: FOAF, vCard, Dublin Core, W3C Org, `@inrupt/vocab-*`.

DESIGN.md

@@ -330,6 +330,22 @@ Non-RDF resources like documents, images, etc.
 
 ## Design Considerations
 
+### 0. App-Neutral Data Store
+
+**Your data belongs to you—not to any particular application or interface.**
+
+This is a core Solid principle that the project embraces throughout its design:
+
+- **Browser UI benefits**: No install required, instant access from any device with a modern browser, familiar graphical interface for exploration and editing.
+- **Terminal app benefits**: Scripting, automation, headless operation, CI/CD pipeline integration, ideal for power users and AI agents.
+- **Same data, same commands**: Both interfaces access the same TinyBase store and use the same CLI command layer. Changes made in the terminal appear immediately in the browser UI and vice versa.
+- **Interface as preference**: The choice of browser or terminal is a matter of context and personal preference—not a constraint imposed by the data model. This mirrors Solid's vision where multiple apps can read and write the same pod data.
+
+This principle influences several design decisions:
+- The CLI command layer is the single source of truth for operations (see Principle 9 in PRINCIPLES_AND_GOALS.md).
+- Platform-specific behavior (file dialogs, clipboard) is isolated to adapters, not core logic.
+- Export/import uses a portable format that works regardless of how data was created.
+
 ### 1. Use Real IRIs
 
 Even though WebIDs won't resolve externally yet, use real URLs based on your domain:

README.md

@@ -50,13 +50,17 @@ This library provides a complete foundation for **user-owned social data** in we
 - **Graphical UI**: Tab-based navigation with forms and lists. Personas, Contacts, and Groups tabs each have a **Create random** button that opens the form with sample data for quick try-out.
 - **CLI Terminal**: Full command-line interface for power users
 
+### App-Neutral Data Store
+In the Solid vision, your data belongs to you—not to any particular application. This library embraces that principle: whether you prefer a browser UI (no install, instant access from any device with a modern browser) or a terminal app (scripting, automation, headless operation, CI/CD pipelines), you work with the same data through the same commands. The interface is a matter of preference and context; the data is yours regardless of how you access it.
+
 ## Benefits for Social Applications
 
 See [docs/PRINCIPLES_AND_GOALS.md](docs/PRINCIPLES_AND_GOALS.md) for the full rationale (why TinyBase, why Solid, what we commit to).
 
 | Benefit | Summary |
 |---------|---------|
 | **User Data Ownership** | Data in browser LocalStorage; export as JSON-LD anytime. |
+| **App-Neutral Access** | Same data, same commands in browser UI or terminal—your data isn't tied to one interface. |
 | **Interoperable Schemas** | FOAF, vCard, Dublin Core, Schema.org, W3C Org—portable to Solid/RDF systems. |
 | **Relationship Modeling** | Personas + contacts + groups support friend/follower, team, org, and agent patterns. |
 | **Offline-First** | TinyBase + LocalStorage; no network required for core features. |

docs/INTEGRATION_GUIDE.md

@@ -296,6 +296,8 @@ Settings are stored in TinyBase **values** (not tables):
 
 The CLI runs in **two environments**: (1) in-app Terminal tab in the browser, and (2) from a real terminal (Node.js).
 
+**App-neutral data access**: In the Solid vision, your data belongs to you—not to any particular application. Whether your users prefer a browser UI (no install, instant access from any device) or a terminal app (scripting, automation, CI/CD pipelines), they work with the same data through the same commands. The interface is a matter of preference; the data is theirs regardless of how they access it.
+
 ### In the browser
 
 ```tsx

docs/PRINCIPLES_AND_GOALS.md

@@ -93,6 +93,8 @@ This principle is about **democratizing development**: if you have a vision for
 
 The library includes a shared CLI built on [Ink](https://github.com/vadimdemedes/ink) (for Node terminal) and web-ink (for browser). This gives you:
 
+- **App-neutral data access**: In the Solid vision, your data belongs to you—not to any particular application. Whether you prefer a browser UI (no install, instant access from any device) or a terminal app (scripting, automation, CI/CD pipelines), you work with the same data through the same commands. The interface is a matter of preference; the data is yours regardless of how you access it.
+
 - **One command set**: `create-persona`, `list-contacts`, `add-to-group`, `export` work identically in the browser console and terminal.
 - **Human and agent interface**: The CLI is not just for developers—it's a stable API for AI coding agents to interact with the store programmatically.
 - **Interactive or scripted**: Use the CLI interactively for exploration, or script it for automation and testing.
@@ -302,6 +304,7 @@ See [SHORTCOMINGS.md](SHORTCOMINGS.md) for the full list.
 |-----------|-----------|
 | **Local-first** | Works from first page load, no server required. |
 | **Data sovereignty** | Users own and control their data. |
+| **App-neutral data** | Same data accessible via browser UI or terminal; your data isn't tied to one interface. |
 | **Sync later** | Connect a pod when ready; local data syncs to it. |
 | **Interoperable** | Standard vocabularies; data is portable beyond this app. |
 | **Offline-first** | No network needed for core features. |

docs/USE_CASES.md

@@ -29,6 +29,7 @@ Store setup and table layout are described in the [README Integration Guide](../
 - Environment-agnostic logic (same code works in browser and Node)
 - A stable API for AI agents and automation
 - **Testability**: Commands can be tested in isolation without UI, browser mocks, or complex fixtures. If it's easier to test in a small environment, it's easier to reason about the ramifications of changes.
+- **App-neutral data access**: In the Solid vision, your data belongs to you—not to any particular application. Whether users prefer a browser UI (no install, instant access) or a terminal app (scripting, automation, CI/CD), they work with the same data through the same commands. The interface is a matter of preference; the data is theirs regardless of how they access it.
 
 This doesn't mean CLI commands are the only way—direct store access is fine for simple cases or when you need fine control. But modeling your app's operations as commands gives you a composable, testable layer that works across all environments.