Upload files to "/"

post_money_economy_full.md

@@ -0,0 +1,183 @@
+# Building a Post‑Money Economic System with Your Software/Data Infrastructure
+
+## TL;DR
+Your stack—self‑sovereign Passports (DIDs), signed & encrypted items, per‑item RBAC, short‑lived key grants, and federated discovery—already gives you everything needed to coordinate **needs, offers, capacities, and outcomes** **without money or trade**. Add four schemas (Need, Offer/Capacity, Assignment, Outcome) and a fairness‑based allocator, and you get a practical, auditable, privacy‑preserving economy of *use* rather than *exchange*—running comfortably on $5/mo nodes.
+
+---
+
+## 1) Goals & Principles
+- **No money, no trade:** Allocate by **purpose and fairness**, not price.
+- **Use rights, not ownership:** Access is granted via **time‑bound, scope‑bound capabilities** (Assignments).
+- **Privacy by default:** Share only minimal metadata for discovery; keep details encrypted until authorized.
+- **Local autonomy + federation:** Each node sets policy and chooses peers; coordination emerges from consented links.
+- **Auditability without surveillance:** Everything is **signed**; access is **key‑gated**; changes are traceable with lightweight logs.
+
+---
+
+## 2) Mapping Your Infrastructure to a Post‑Money Economy
+
+| Your capability | Economic role |
+|---|---|
+| **Passports (DIDs)** for users & nodes | Stable identity for rights & duties; no email/finance required |
+| **Categories & Items** (JSON‑Schema) | Typed records for **Needs**, **Offers/Capacity**, **Assignments**, **Outcomes** |
+| **Zanzibar‑style RBAC + caveats** | Rules for who may **request, view, allocate, steward** |
+| **Encryption + short‑lived key grants** | Only authorized parties can actually **use** a resource |
+| **Federation + authority pointers** | Cross‑node discovery with **source‑of‑truth** checks |
+| **Projections** (audience‑specific fields) | Searchable summaries without leaking secrets |
+| **Signed events & tombstones** | Tamper‑evident lifecycle, revocation, and cleanup |
+
+---
+
+## 3) Core Schemas (minimal set)
+
+### 3.1 Need
+A request for access or assistance.
+```json
+{
+  "title": "Laptop for coursework",
+  "summary": "2 weeks for class project",
+  "category": "need.device@v1",
+  "window": {"from": "2025-09-01", "to": "2025-09-15"},
+  "constraints": {"os": "linux-ok", "battery": ">3h"},
+  "priority": "normal|urgent",
+  "visibility": "public|node|group|direct",
+  "discoverable": true
+}
+```
+
+### 3.2 Offer / Capacity
+Availability of resources, skills, time, or space.
+```json
+{
+  "title": "3 laptops available",
+  "category": "offer.device@v1",
+  "units": 3,
+  "requirements": {"purpose": "study", "careAgreement": true},
+  "window": {"from": "2025-09-01", "to": "2025-12-31"},
+  "visibility": "node|group|public",
+  "discoverable": true
+}
+```
+
+### 3.3 Assignment (Use Permit)
+The non‑transferable grant that authorizes use.
+```json
+{
+  "category": "assignment@v1",
+  "needId": "…",
+  "offerId": "…",
+  "assignee": "did:key:…",
+  "resourceRef": {"itemId": "…", "version": 2},
+  "window": {"from": "…", "to": "…"},
+  "conditions": {"careAgreement": true},
+  "status": "active|completed|revoked"
+}
+```
+
+### 3.4 Outcome
+What happened afterward (learning & accountability).
+```json
+{
+  "category": "outcome@v1",
+  "assignmentId": "…",
+  "result": "completed|partial|failed",
+  "notes": "Returned in good condition.",
+  "maintenance": {"needed": false}
+}
+```
+> All records are **signed** by the issuer’s Passport. Private fields (e.g., lock codes, credentials) live only in the **encrypted payload**, released via a key grant when authorized.
+
+---
+
+## 4) Lifecycle Without Prices
+
+1. **Publish Needs & Offers**  
+   People create **Needs**; groups publish **Offers/Capacity**. Nodes federate only **projection fields** (title, tags, short summary, timestamps)—never secrets.
+
+2. **Discover & Match**  
+   Members search locally and across peers for items their node may see. Matching can be manual (stewards) or automated (policy engine).
+
+3. **Allocate (Fairness, not markets)**  
+   The **allocator** (policy + algorithm) chooses which Needs get which Offers and emits **Assignments**. Example policies: **max‑min fairness**, **round‑robin**, **weighted lottery**, **needs‑based priority**, **quotas/cooldowns**.
+
+4. **Access (Key‑Gated)**  
+   When an Assignment is active, the assignee requests a **short‑lived key grant**. The node checks RBAC and returns a sealed DEK, enabling the client to decrypt resource details.
+
+5. **Use → Return → Outcome**  
+   During the window, the user can decrypt and use the resource. On completion, they (or stewards) record an **Outcome** and any maintenance needed.
+
+6. **Revocation / Change**  
+   If circumstances change, rotate keys and update RBAC; future access stops immediately. Public→private flips re‑key the item and remove it from public indices.
+
+---
+
+## 5) Federation Without Markets
+
+- **Authority pointer**: every shared item carries a signed pointer to the **authority node** (and ACL revision).  
+- **Remote search**: ask peers to search on your node’s behalf, returning **stubs** your node can show.  
+- **Mirrored indices** (optional): peers export signed, projection‑only docs for items visible to your node; you index locally for low‑latency search.  
+- **On open**: your node still requests a **Key Grant** from the authority; unauthorized users learn nothing.
+
+---
+
+## 6) Governance & Fairness (policy, not payment)
+
+- **Roles**: requester, steward/maintainer, allocator (human/automated), auditor.  
+- **Policy examples (Cedar/OPA)**:  
+  - Eligibility & visibility (who may request/offer)  
+  - Fairness (caps per person, priority cohorts, cooling‑off periods)  
+  - Stewardship (return checks, maintenance duties)  
+  - Conflicts (deterministic tie‑break, seeded randomness)  
+- **Transparency**: publish anonymous queue stats and policy versions; keep **signed** Assignment/Outcome logs (history, not currency).
+
+---
+
+## 7) Privacy & Safety
+
+- **Least disclosure** via projections: search works without exposing secrets.  
+- **Encrypted‑at‑rest** for all items; only **short‑lived** key grants unlock details.  
+- **Revocation** with per‑version keys; deny new grants after policy changes.  
+- **Auditability** with signatures, versioning, and tombstones.
+
+---
+
+## 8) Example Scenarios
+
+- **Tool Library** — Needs (jobs), Offers (tools), Assignments (time slots), Outcomes (condition). Allocation: round‑robin + urgent‑repair priority; access via smart‑lock codes delivered as encrypted secrets.  
+- **Community Transport** — Needs (rides), Offers (drivers/vehicles), Assignments (routes). Allocation: max‑min fairness + safety checks; keys unlock car‑share boxes.  
+- **Compute Commons** — Needs (GPU hours), Offers (capacity windows), Assignments (job permits). Allocation: fair‑share scheduler; credentials delivered via key grant.  
+- **Space Sharing** — Needs (meeting room), Offers (rooms), Assignments (bookings). Allocation: quotas/cooldowns; door codes disclosed only to assignees.  
+- **Childcare Network** — Needs (time slots), Offers (care capacity), Assignments (sessions). Allocation: vetted caregivers + weighted lottery for prime times.
+
+---
+
+## 9) Minimal MVP (1–2 sprints)
+
+1. **Schemas**: Need, Offer/Capacity, Assignment, Outcome (+ projections).  
+2. **Allocator v1**: weighted lottery with quotas per person/node.  
+3. **Assignment→Access glue**: issuing an Assignment mints RBAC + key grant; on end, revoke.  
+4. **Search**: local + remote‑peer search on projection fields.  
+5. **Federation**: signed inbox/outbox; authority pointers; key‑grant endpoint.
+
+---
+
+## 10) Success Metrics (not price‑based)
+
+- **Fill rate of Needs** (per category, time‑to‑assignment).  
+- **Fairness indicators** (variance in access; max‑min score).  
+- **Stewardship health** (on‑time returns, maintenance backlog).  
+- **Privacy incidents** (zero leakage beyond projections).  
+- **Utilization** (capacity used vs available; bottlenecks identified).
+
+---
+
+## 11) Why This Works on $5 Nodes
+
+- Single Rust binary with **SQLite (WAL)** and **Tantivy**; in‑process RBAC; mTLS/onion.  
+- Crypto (Ed25519/X25519/XChaCha20) is **lightweight**; key grants are **tiny**.  
+- Mirrored indices use **projection‑only** fields to stay small and fast.
+
+---
+
+### One‑Sentence Summary
+With signed identities, encrypted items, fine‑grained permissions, federated discovery, and fairness‑based allocation, your system provides the building blocks for a **coordinated, auditable, privacy‑preserving economy of *use*—no prices or trade required.**