183 lines
8.4 KiB
Markdown
183 lines
8.4 KiB
Markdown
# 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.**
|