# 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.**