8.4 KiB
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.
{
"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.
{
"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.
{
"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).
{
"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
-
Publish Needs & Offers
People create Needs; groups publish Offers/Capacity. Nodes federate only projection fields (title, tags, short summary, timestamps)—never secrets. -
Discover & Match
Members search locally and across peers for items their node may see. Matching can be manual (stewards) or automated (policy engine). -
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. -
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. -
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. -
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)
- Schemas: Need, Offer/Capacity, Assignment, Outcome (+ projections).
- Allocator v1: weighted lottery with quotas per person/node.
- Assignment→Access glue: issuing an Assignment mints RBAC + key grant; on end, revoke.
- Search: local + remote‑peer search on projection fields.
- 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.