Minimal Federated Trust-Bound Social Infrastructure (Ur-Protocol)

Complete Specification and Field Manual v0.5

Part I: Specification

0. Scope

Ur-Protocol defines a portable identity + small-group coordination substrate.

It is not:

a platform
a company service
a monolithic app
a global social graph

It is:

a protocol that allows many independent servers and many independent clients to coordinate small human groups safely and cheaply

The protocol guarantees:

identity continuity
social proof admission/recovery
group ordering/consistency
server replaceability
client replaceability

Everything else (UX, features, aesthetics) is out of scope.

0.1 Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

0.5 Foundational Premise: Human-First Infrastructure

This protocol assumes social networks are human relationships first, technical infrastructure second.

Consequences:

No technological substitute for human contact. If you lose touch with someone and cannot reach them through mutual contacts, you are out of contact. The protocol does not solve this. Telephones, email, and physical presence exist.

Reachability requires maintained relationships. Your trustees are not just recovery agents—they are the people who know how to find you. If you neglect these relationships, the protocol cannot compensate.

Discovery is a human problem. The protocol does not help strangers find each other. Meeting people requires the same mechanisms it always has.

Trust is social, not computational. Trustee collusion cannot be prevented cryptographically. You must choose trustees you actually trust. This is not a limitation—it is the point.

The protocol's role is to preserve and transport human trust relationships, not to replace them.

Systems that attempt technological solutions to social problems become platforms. This protocol refuses that path.

Security Implications

This human-first premise creates attack resistance that purely technical systems cannot achieve:

No central point to compromise. There is no registry, directory, or authority to subvert.

Social verification defeats Sybil attacks. You cannot fake being someone's actual friend.

Collusion requires real-world betrayal. Attackers must corrupt actual trusted relationships, which does not scale.

No technical bypass for social proof. There is no password to steal, no email to phish, no admin to bribe.

Fragmentation is a feature. Compromising one group, server, or home gains nothing elsewhere.

Reachability requires relationship maintenance. Attackers cannot passively monitor a directory for targets.

The attack surface reduces to: "compromise multiple real humans who personally know the target." This is espionage-grade effort for individual targeting. It does not scale to mass attacks.

0.6 System Overview

┌─────────────────────────────────────────────────────────────────┐
│                         CLIENTS                                 │
│              (PWA, native apps, CLI, custom)                    │
│                    UX only — no authority                       │
└─────────────────────────────────────────────────────────────────┘
                              ↕
┌─────────────────────────────────────────────────────────────────┐
│                          HOMES                                  │
│                  (independent servers)                          │
│              storage + transport + federation                   │
│                 ┌───────────────────┐                           │
│                 │    GROUP HOMES    │                           │
│                 │ (canonical state  │                           │
│                 │  for each group)  │                           │
│                 └───────────────────┘                           │
└─────────────────────────────────────────────────────────────────┘
                              ↕
┌─────────────────────────────────────────────────────────────────┐
│                        PROTOCOL                                 │
│         (shared truth: signatures, events, federation)          │
└─────────────────────────────────────────────────────────────────┘
                              ↑
                     NEVER CROSSES THIS LINE
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│                   IDENTITY & TRUST                              │
│                   (client-local only)                           │
│                                                                 │
│   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐        │
│   │  keypair    │    │  trustees   │    │  threshold  │        │
│   │  (Ed25519)  │    │  (pubkeys)  │    │   (k-of-n)  │        │
│   └─────────────┘    └─────────────┘    └─────────────┘        │
│                                                                 │
│              AUTHORITATIVE — NEVER ON SERVERS                   │
└─────────────────────────────────────────────────────────────────┘

Authority flows upward only. Identity and trust are local. Everything above serves them.

1. Non-Negotiable Invariants

If any invariant is violated, the system collapses into platform capture.

1.1 Identity is portable

Users MUST retain identity across:

servers
apps
devices

1.2 Trust roots are client-sovereign

Servers MUST NOT:

change trustees
change recovery rules
seize identity

1.3 Servers are disposable

Any server MAY disappear without identity loss.

1.4 Clients are optional

No single app SHALL be required.

1.5 Hosting is trivial

Implementations MUST run on commodity hardware at hobby-expense levels.

1.6 No global discovery or reputation

Trust MUST arise from local social relationships only. Implementations MUST NOT provide global user directories, reputation scores, or algorithmic discovery.

2. Layer Model

Identity & Trust   (authoritative, local)
        ↓
Protocol           (shared truth)
        ↓
Homes/Servers      (storage/transport only)
        ↓
Clients/UIs        (replaceable views)

Authority decreases as you go down.

3. Layer A — Identity (Client-Sovereign)

3.1 Identity Primitive

Each identity is:

Ed25519 keypair
public key = identity
signatures = proof

Implementations MUST NOT require:

username authority
email
passwords
registry
blockchain

3.2 Identity Bundle (local, authoritative)

Stored only on client devices:

identity_keypair
trustees[] (public keys)
threshold k
trust_epoch
optional delegations

Properties:

MUST be encrypted by OS keystore or equivalent
MUST be signed by identity key
MUST NOT be server-authoritative

Rule: Servers MAY cache but MUST NOT be authoritative. If server controls this data, server controls user, and protocol is invalid.

3.3 Identity Pointer Document (IPD)

Defines current home.

identity_pubkey
current_home_uri
ipd_epoch
signature

Higher epoch MUST win in conflicts.

Used for:

migration
continuity proof

Propagated via:

direct contact
trustee caches
old server redirect (OPTIONAL)

No central directory SHALL exist.

3.4 IPD Recovery Failure Mode

If a user cannot locate another user's current IPD through cached trustees or direct contact, the relationship is dormant until re-established through out-of-band communication.

This is intentional.

The protocol does not guarantee perpetual reachability. It guarantees identity continuity when contact is maintained.

This is how human relationships work.

4. Layer B — Trust (Social Proof)

4.1 Purpose

Replace:

passwords
email recovery
admin approval

With:

peer signatures

4.2 Mechanism

Threshold signatures.

Examples:

3-of-5 trustees approve join
3-of-5 approve recovery

Implementations MUST support configurable k-of-n thresholds.

4.3 Trustee Rotation

Trust list MUST be mutable.

Rotation:

MUST be signed by identity key
MUST increment trust_epoch
MUST replace trustees atomically

4.4 Compromise Controls

OPTIONAL mechanisms (implementation-defined):

panic lock (raise threshold temporarily)
cooldown on recovery
dual requirement (device + trustees)

Protocol acknowledges:

Trustee collusion cannot be cryptographically prevented. This is a social boundary.

5. Layer C — Groups (First-Class Entity)

Groups are explicit protocol objects.

5.1 Group Object

group_id
group_home
membership_set
roles
policy
event_log

5.2 Canonical Authority

Each group MUST have exactly one Group Home.

Group Home responsibilities:

MUST assign strictly monotonic sequence numbers
MUST store authoritative membership
MUST mint canonical group events

Other servers:

MAY relay
MAY cache
MUST NOT mint canonical events

5.3 Ordering Model

Per-group single sequencer.

Properties:

strong ordering inside group
eventual delivery outside group

No global ordering.

Avoids:

CRDT complexity
multi-writer conflict resolution

5.4 Consistency Model

eventual consistency for transport
strong consistency for canonical group state

Clients MUST treat Group Home's log as truth.

5.5 Membership

Canonical membership MUST live at Group Home.

Users MAY reside on any home.

Servers MAY cache membership but MUST NOT be authoritative.

5.6 Group Migration

Group MAY move homes via Group Move Certificate:

group_id
new_group_home
epoch
admin/member threshold signatures

If old home dead/hostile:

group MAY fork
new home becomes canonical

Forking is acceptable and expected.

5.7 Group Home Criticality

The Group Home is critical infrastructure for that group while active.

If Group Home dies:

in-flight events MAY be lost
group MUST migrate or fork
acceptable loss is implementation-defined

This is not server disposability violation. Groups can move. Identity persists regardless.

6. Bootstrapping

6.1 Genesis Group

Single creator MAY create group.

Group SHOULD become socially active after reaching membership threshold (implementation-defined, RECOMMENDED: 5 members with valid trustee sets).

6.2 Zero-Trust Onboarding

Protocol does not solve stranger discovery.

OPTIONAL mechanisms (out of scope but expected):

QR links
invitations
public lobby groups

Public groups are explicitly low-trust and outside small-group guarantees.

6.3 Cold Start

A new user with zero contacts MUST either:

know someone already in the system, or
join a public/low-trust entry point, or
start a new group with people they know in the physical world

There is no technological solution to "I know nobody." This is correct.

7. Layer D — Homes (Servers)

7.1 Responsibilities

Servers MUST provide:

storage
transport
federation
PWA hosting

Servers MUST NOT provide:

identity authority
trust authority
group authority (except if Group Home for specific groups)

7.2 Deployment

Each instance runs:

API server
database
object storage
PWA frontend
federation endpoints

Cost target: €30–50/month

7.3 Replaceability

Implementations MUST allow users to:

export identity
migrate
rejoin elsewhere

Servers are homes, not owners.

8. Layer E — Clients (Plural)

8.1 Principle

Protocol defines truth.

Clients define UX only.

No client is authoritative.

8.2 Consequences

Anyone MAY implement:

mobile client
web client
accessibility client
custom UI
CLI

All MUST interoperate via protocol.

Official app is reference implementation only.

9. Client Deployment

9.1 Primary: PWA

PWA is canonical client.

Capabilities:

install to home screen
fullscreen
push notifications
offline cache
camera/files

Properties:

cannot be delisted
no approval required
trivial mirroring

9.2 PWA Platform Notes

Android/Desktop: Full PWA support including push.

iOS: Web Push requires:

PWA added to home screen
explicit user permission
iOS 16.4+

iOS PWA push is functional but less reliable than native. This is acceptable. System MUST NOT depend on perfect push.

9.3 Secondary: Native Wrappers

OPTIONAL.

Used for:

polish
store discovery
more reliable push

System MUST function without them.

If app store removal occurs, PWA continues.

10. Core Flows

Join

Friends approve → identity created locally

Daily Use

Sign events → Group Home sequences → servers relay

Move Home

Update IPD → propagate to trustees → migrate

Recovery

Trustees rebind key to new device

Exit

Export identity → delete local data → continue elsewhere or stop

All flows MUST complete without server permission.

11. Failure Modes

Failure	Effect
Server dies	Migrate
Hostile server	Migrate
App delisted	Use PWA
Client disappears	Use another
Device lost	Social recovery
Group home dies	Migrate/fork group
Contact lost	Re-establish out-of-band
Project abandoned	Forks continue

Nothing is existential.

12. Explicit Non-Features

Implementations MUST NOT include:

blockchain
tokens
reputation scores
global feeds
algorithmic discovery
ads
growth mechanics
centralized identity
heavy consensus protocols

These violate invariants or attempt technological solutions to social problems.

13. Federation (Deferred)

Federation wire protocol requires separate specification covering:

wire format
server discovery
event authentication
replay prevention
relay behavior

This document defines semantics. Wire protocol is implementation scope.

14. Event Schema (Deferred)

Event structure requires separate specification covering:

event types
required fields
signature structure
versioning

This document defines architecture. Schema is implementation scope.

15. Summary

Ur-Protocol is:

client-sovereign identity + socially verified trust + per-group canonical sequencing + disposable homes + plural clients

It behaves like:

email
small forums
group chats

Not like:

Facebook
Instagram
global platforms

It is intentionally:

boring
cheap
forkable
hard to capture
hard to attack

Part II: Field Manual

16. Orientation

Why Platforms Fail

Most online social systems are built as platforms. This manual is about how not to build one.

This is not ideology. It is geometry.

Human trust has limits. Platforms ignore those limits.

Platforms try to:

scale infinitely
connect strangers
centralize identity
optimize engagement
monetize attention

When systems exceed trust limits:

reputation collapses
norms fragment
moderation industrializes
incentives distort behavior
extraction begins

This is not a leadership failure. It is structural.

Trust requires repeated relationships. Platforms replace repetition with anonymous flow. So they fail.

The Alternative

Instead of one giant system → many small systems

Instead of global identity → portable identity

Instead of discovery of strangers → relationships

Instead of scale → replication

This manual shows how to do that.

17. Mission

Operate digital social infrastructure that is:

small
cheap
forkable
boring
durable

Success looks like: people communicating for years without thinking about the software.

If it feels exciting or growth-oriented, you are rebuilding a platform.

18. Mental Model

Memorize this:

Identity = person
Home = mailbox
Group = room
Client = window

Rules:

people own identity
homes store data
rooms coordinate
clients display

If a server owns identity, you have rebuilt Facebook.

19. Minimum Viable System

You need surprisingly little:

portable identity (keys)
social recovery (friends)
one cheap server
small groups
web app (PWA)

Nothing else is required.

If something sounds complex, it is probably unnecessary.

20. Operational Invariants

Never violate these:

Identity is client-owned. Servers must not control accounts.

Servers are disposable. Any server may die without catastrophe.

Clients are replaceable. No single app is required.

Hosting stays cheap. If costs rise, incentives distort.

No global discovery. Trust is local only.

Split, don't scale. When large, clone.

21. System Architecture (Practical View)

You are running:

Identity layer: Ed25519 keys, stored locally, passkeys/WebAuthn

Trust layer: 3–5 trustees, threshold recovery

Group layer: each group has one canonical server (Group Home), per-group ordered log

Server layer: storage + transport only

Client layer: PWA primarily, native optional

22. Running a Community

Step 1 — Start with real people

Do not launch publicly.

Start with:

friends
class
club
project
neighborhood

Ideal size: 10–50.

Large from day one = platform dynamics.

Step 2 — Provision one small server

Requirements:

€5–10 VPS
1 CPU
1–2 GB RAM
20–50 GB disk
domain name

That's enough.

If you think you need Kubernetes, stop.

Step 3 — Install software

Note: Reference implementation pending. See Appendix F for suggested implementation stack.

Use software that provides:

identity-based auth
social recovery
per-group sequencing
PWA client
export/migration

Avoid software that includes:

feeds
discovery
ads
growth metrics
reputation scores

Step 4 — Bootstrap identity

First user (founder):

Generate identity locally (keypair created in browser/app)
No trustees initially
Create genesis group

Next 3–5 users:

Generate identities locally
Name founder + each other as trustees
Join genesis group

Group becomes socially active when 5+ members have valid trustee sets (3-of-5 threshold achievable).

Step 5 — Create small groups

Examples:

family
project
hobby
team

Avoid:

"everyone"
public megachats

Large rooms recreate platform failure modes.

23. Daily Operations

Hosting

Expect near-zero CPU for text-based communication.

Media-heavy groups will use more storage and bandwidth. Plan accordingly.

If CPU spikes unexpectedly, you likely added strangers or have a bot problem.

Backups

Back up:

database
media
config

Identity lives on devices. Server backup protects group history, not identity.

Updates

Slow and boring.

Feature churn destabilizes communities.

Moderation

Handled socially.

If you need dedicated moderators, the group is too big. Split.

24. Failure Playbook

Failure	Response
Server dies	Move to new server
Operator quits	Someone else hosts
App delisted	Use PWA
Client abandoned	Use another client
Device lost	Recover socially via trustees
Group conflict	Fork the group

Nothing should ever be catastrophic.

If it is, you centralized something you shouldn't have.

25. Security Reality

Protects against:

mass impersonation
centralized breaches
platform capture
surveillance chokepoints
Sybil attacks
credential theft

Does not protect against:

coercion
betrayal by trustees
device seizure
targeted state action

No system can protect against these. Accept this boundary.

26. Anti-Patterns

Never add:

❌ global search
❌ algorithmic feeds
❌ reputation scores
❌ monetization
❌ blockchain/tokens
❌ forced growth
❌ single official client

Each one recreates platform dynamics.

27. Deployment Guide

Goal

Bring a 20–50 person group online in one evening.

Requirements

VPS (any provider)
domain name
Docker or systemd
HTTPS (Let's Encrypt)

Minimal Stack

Server components:

API server (protocol implementation)
Database: PostgreSQL
Storage: local disk or S3-compatible
Client: bundled PWA

Steps

1. Provision server

Any VPS provider. Minimum specs:

1 vCPU
1 GB RAM
20 GB disk

2. Install prerequisites

apt update && apt install docker docker-compose

3. Deploy

git clone <reference-implementation-repo>
cd <repo>
cp .env.example .env
# Edit .env: set domain, storage path
docker compose up -d

Note: Reference implementation repository TBD. See Appendix F for implementation guidance.

4. Configure TLS

# Using certbot
apt install certbot
certbot certonly --standalone -d yourdomain.example

Configure reverse proxy (nginx/caddy) to terminate TLS.

5. Create founder account

Open https://yourdomain.example in browser
Generate identity (happens locally)
You are now founder with no trustees

6. Invite initial members

Share invite link (QR or URL)
First 5 people create identities
Each names 3–5 others as trustees
Founder adds trustees once others exist

7. Create first group

Founder creates group
Invite members
Group Home = your server

Done. Time required: 1–2 hours.

28. Day-2 Operations

Weekly:

Backup database
Backup media

Monthly:

Update software (if updates exist)
Test restore from backup

Yearly:

Rotate operators if needed
Review server costs

That's it.

If you need more operational overhead, you're over-engineering.

29. Platform Notes

PWA on iOS

iOS supports PWA with Web Push as of iOS 16.4.

Limitations:

Must add to home screen first
Push less reliable than native
Some UI polish differences

This is acceptable. The system functions. Users who need better push can use native wrapper if available.

PWA on Android/Desktop

Full support. No significant limitations.

30. Troubleshooting

Server overloaded

Split groups to another server.

Too many strangers

Make group private or invite-only.

Drama / conflict

Group is too big. Split into smaller groups.

Costs rising

Reduce media retention, not users. Or split to multiple smaller servers.

Lost contact with someone

Re-establish through phone, email, mutual friends, physical encounter. This is correct behavior, not a bug.

31. Design Heuristics

When making decisions, ask:

Does this make us bigger or smaller? → Choose smaller.

Does this add a dependency? → Reject it.

Can we fork tomorrow? → Answer must be yes.

Would email need this feature? → If not, probably remove it.

32. Expected Outcome

If you succeed, the system will feel:

quiet
boring
stable
unremarkable

No headlines. No growth metrics. No drama.

Just people talking.

That is success.

33. Final Rule

If you ever think:

"We should scale this."

Stop.

Start another small server instead.

Many small networks outlive one big one.

Always.

Part III: Appendices

Appendix A: Glossary

Identity: Ed25519 keypair. Public key is the identifier. Stored locally, never on server.

Trustee: A person (identified by their public key) authorized to participate in recovery or admission threshold signatures.

Threshold: The number of trustee signatures required (e.g., 3-of-5).

Home: The server where a user's data currently resides. Replaceable.

Group Home: The server that holds canonical state for a specific group. Authoritative for that group only.

IPD (Identity Pointer Document): Signed document indicating a user's current home. Used for migration and discovery.

Epoch: Monotonically increasing counter. Higher epoch wins in conflicts.

PWA (Progressive Web App): Web application installable to home screen with offline and push capabilities.

Genesis Group: First group created by a founder, before trustee network exists.

Fork: Creating a new group (or server) from an existing one when consensus breaks down. Expected and healthy.

Appendix B: Threat Model

In Scope (Protocol Defends Against)

Threat	Defense
Mass credential theft	No passwords to steal
Central database breach	No central database
Platform deplatforming	PWA + server migration
Sybil attacks	Social proof admission
Identity hijacking	Threshold recovery requires real relationships
Surveillance chokepoints	No central directory or registry
Vendor lock-in	Portable identity, plural clients

Out of Scope (Cannot Defend)

Threat	Reality
Device seizure	Physical security is user responsibility
Trustee collusion	Social problem, not technical
Targeted state action	No consumer system can resist
Coercion	No consumer system can resist
Rubber hose cryptanalysis	Out of scope for any protocol

The protocol optimizes for: mass attack resistance, platform capture resistance, long-term durability.

It does not optimize for: nation-state adversaries, targeted attacks on individuals.

Appendix C: Comparison to Existing Systems

System	Identity	Trust	Discovery	Capture Risk
Facebook	Platform-owned	Platform-mediated	Global	Total
Email	Domain-bound	Manual	Manual	Moderate (provider)
Signal	Phone-bound	Contact list	Phone numbers	Moderate (central server)
Matrix	Server-bound	Server-mediated	Federated directories	Moderate
Mastodon	Server-bound	Server-mediated	Federated	Moderate
Ur-Protocol	Client-owned	Social proof	None (human)	Minimal

Key differentiator: Ur-Protocol has no discovery mechanism. This is the feature, not the limitation.

Appendix D: Implementation Status

Protocol Specification: Complete (this document)

Federation Wire Protocol: Not yet specified

Event Schema: Not yet specified

Reference Implementation: Not yet available

This document is sufficient for:

architectural understanding
implementation planning
independent implementation attempts

This document is not sufficient for:

wire-compatible implementations (pending federation spec)
drop-in deployment (pending reference implementation)

Appendix E: Version History

Version	Date	Changes
0.1	—	Initial architectural sketch
0.2	—	Added group model, consistency semantics
0.3	—	Added human-first premise, security implications
0.4	—	Combined spec and field manual, added appendices
0.5	—	RFC-style normative language, implementation stack, system diagram

Appendix F: Suggested Implementation Stack

This appendix provides guidance for first implementers. These are recommendations, not requirements.

Backend

Language options (any suitable):

Go — good concurrency, single binary deployment
Rust — performance, memory safety
TypeScript/Node — ecosystem familiarity, rapid development

Selection criteria: Choose based on team expertise. Protocol correctness matters more than language choice.

Database

PostgreSQL

Proven reliability
JSONB for flexible event storage
Strong consistency guarantees

Avoid: eventually-consistent databases for canonical group state.

Object Storage

Options:

Local filesystem (simplest, sufficient for small deployments)
S3-compatible (MinIO for self-hosted, or any S3 provider)

Media storage is the primary cost driver. Plan retention policies accordingly.

Cryptography

libsodium (or language-native bindings)

Ed25519 for signatures
X25519 for key exchange (if encrypted transport needed)
Argon2 for any key derivation

Do not implement custom cryptography.

PWA Frontend

Framework options:

Svelte — small bundle, good performance
React — ecosystem, hiring familiarity
Vue — middle ground
Vanilla JS — smallest bundle, highest control

Selection criteria: Bundle size and offline capability matter more than framework features.

Required PWA Capabilities

Service worker for offline
Web Push for notifications
IndexedDB for local storage
WebAuthn/passkeys for key storage

Deployment

Minimum viable:

nginx (TLS termination)
  ↓
API server (single process)
  ↓
PostgreSQL
  ↓
Filesystem or S3

Containerized:

# docker-compose.yml structure
services:
  api:
    # protocol implementation
  db:
    image: postgres:16
  storage:
    # optional: minio for S3-compatible

Federation Transport

Until wire protocol is specified, implementations MAY use:

HTTPS POST for server-to-server
WebSocket for real-time client updates
Signatures on all federated messages

Implementations MUST verify signatures on all received events.

What NOT to Include

User analytics
Telemetry
A/B testing
Growth metrics
Email integration
OAuth/social login
Admin dashboards with user management

These create platform incentives. Resist them.

Appendix G: Normative Requirements Summary

For implementer reference, all MUST/MUST NOT requirements collected:

Identity

Servers MUST NOT store authoritative identity bundles
Servers MAY cache but MUST NOT be authoritative for identity
Higher IPD epoch MUST win in conflicts
No central directory SHALL exist

Trust

Implementations MUST support configurable k-of-n thresholds
Trustee rotation MUST be signed by identity key
Trustee rotation MUST increment trust_epoch
Trustee rotation MUST replace trustees atomically

Groups

Each group MUST have exactly one Group Home
Group Home MUST assign strictly monotonic sequence numbers
Group Home MUST store authoritative membership
Group Home MUST mint canonical group events
Other servers MUST NOT mint canonical events
Clients MUST treat Group Home's log as truth
Servers MAY cache membership but MUST NOT be authoritative

Servers

Servers MUST provide: storage, transport, federation, PWA hosting
Servers MUST NOT provide: identity authority, trust authority
Implementations MUST allow users to: export identity, migrate, rejoin elsewhere

Clients

All clients MUST interoperate via protocol
System MUST function without native wrappers
System MUST NOT depend on perfect push delivery

Non-Features

Implementations MUST NOT include: blockchain, tokens, reputation scores, global feeds, algorithmic discovery, ads, growth mechanics, centralized identity, heavy consensus protocols

End of Document

The protocol encodes a simple premise:

Human relationships are the foundation. Technology only carries them.

This is why it can persist.

Field Manual: Minimal Federated Trust-Bound Social Infrastructure

Minimal Federated Trust-Bound Social Infrastructure (Ur-Protocol)

Complete Specification and Field Manual v0.5

Part I: Specification

0. Scope

0.1 Notational Conventions

0.5 Foundational Premise: Human-First Infrastructure

Security Implications

0.6 System Overview

1. Non-Negotiable Invariants

1.1 Identity is portable

1.2 Trust roots are client-sovereign

1.3 Servers are disposable

1.4 Clients are optional

1.5 Hosting is trivial

1.6 No global discovery or reputation

2. Layer Model

3. Layer A — Identity (Client-Sovereign)

3.1 Identity Primitive

3.2 Identity Bundle (local, authoritative)

3.3 Identity Pointer Document (IPD)

3.4 IPD Recovery Failure Mode

4. Layer B — Trust (Social Proof)

4.1 Purpose

4.2 Mechanism

4.3 Trustee Rotation

4.4 Compromise Controls

5. Layer C — Groups (First-Class Entity)

5.1 Group Object

5.2 Canonical Authority

5.3 Ordering Model

5.4 Consistency Model

5.5 Membership

5.6 Group Migration

5.7 Group Home Criticality

6. Bootstrapping

6.1 Genesis Group

6.2 Zero-Trust Onboarding

6.3 Cold Start

7. Layer D — Homes (Servers)

7.1 Responsibilities

7.2 Deployment

7.3 Replaceability

8. Layer E — Clients (Plural)

8.1 Principle

8.2 Consequences

9. Client Deployment

9.1 Primary: PWA

9.2 PWA Platform Notes

9.3 Secondary: Native Wrappers

10. Core Flows

Join

Daily Use

Move Home

Recovery

Exit

11. Failure Modes

12. Explicit Non-Features

13. Federation (Deferred)

14. Event Schema (Deferred)

15. Summary

Part II: Field Manual

16. Orientation

Why Platforms Fail

The Alternative

17. Mission

18. Mental Model

19. Minimum Viable System

20. Operational Invariants

21. System Architecture (Practical View)

22. Running a Community

Step 1 — Start with real people

Step 2 — Provision one small server

Step 3 — Install software

Step 4 — Bootstrap identity

Step 5 — Create small groups

23. Daily Operations

Hosting

Backups

Updates