From f9762aa36a5a9ac7dfc907f2f0e02ae4d1ae857f Mon Sep 17 00:00:00 2001 From: continuist Date: Thu, 21 Aug 2025 14:09:18 -0400 Subject: [PATCH] Upload files to "/" --- post_money_economy_full.md | 183 +++++++++++++++++++++++++++++++++++++ 1 file changed, 183 insertions(+) create mode 100644 post_money_economy_full.md diff --git a/post_money_economy_full.md b/post_money_economy_full.md new file mode 100644 index 0000000..5b41700 --- /dev/null +++ b/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.**