Upload files to "/"
This commit is contained in:
parent
211eb72e08
commit
f9762aa36a
1 changed files with 183 additions and 0 deletions
183
post_money_economy_full.md
Normal file
183
post_money_economy_full.md
Normal file
|
|
@ -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.**
|
||||
Loading…
Add table
Reference in a new issue