One Rust crate. A desktop app and a server. No accounts.

Architecture at a glance

There is one crate at src/. No Cargo workspace, no sub-crates, no separate server repository. Cargo features decide what gets compiled in, and the same source tree produces the desktop app and the server binary.

cargo build --release --features native                       # desktop app
cargo build --release --features relay --no-default-features  # headless server

HumanityOS              # full desktop app: renderer, game, GUI, embedded relay
HumanityOS --headless   # server only, no GPU, listens on :3210

Identity and cryptography

There are no accounts, no passwords, and no home server. An identity is a keypair derived from a BIP39 seed phrase on your own machine. Servers store what you publish and verify your signatures. They never hold a credential that could be used to become you.

Client and server implementations are locked together by cross-language known-answer tests, so the browser, the desktop app, and the server agree byte for byte on key derivation and on the message envelope. The canonical inventory lives in the repository, in the Cryptography section of CLAUDE.md, and it is updated in the same commit as any change.

Federation

A server is a place with its own channels, members, and operator. Federation is a bridge between the same room on two servers, and both operators have to opt in: a peer relationship on each side, plus a per-channel toggle. There is no global admin, no registry, and no authority that can revoke a server's membership.

• Trust is not transitive. A trusting B and B trusting C does not make A trust C. Every operator picks their own peers, so one compromised hub cannot chain into everything.
• Discovery, not auto-join. GET /api/federation/servers exposes a node's peer graph, and clients render it as a browsable directory. Adding a server is always the user's choice.
• Rooms outlive servers. A room carried by two or more of your servers is shown once, merged, in a section called the Commons. Sending picks a healthy carrier at send time, so if one carrier goes down mid-conversation the next message routes through another.
• Deduplication is by origin server, sender, and timestamp, so a message that arrives twice through two bridges is shown once.
• Trust tiers 0 to 3 record how much an operator has verified a peer, and whether that peer publicly adopted the Humanity Accord. Tiers are per operator, never global.

Federation shares identities, discovery, and bridged rooms. It does not hand your database to anyone. Rooms you do not federate stay on your machine.

Run your own node

The desktop build and the server are the same program, so any computer that can run the app can host a node. One command starts a relay with an embedded database and no dependencies to install.

HumanityOS --headless

PORT=3210                      # optional, default 3210
DATABASE_PATH=data/relay.db    # optional, default data/relay.db

• On a LAN it is finished right there. No domain, no certificate, no port forwarding. Everyone on the same network connects to your local address.
• For a public node, scripts/provision-vps.sh builds the whole stack from a bare Debian 12 install, nginx and TLS included. The floor is 1 GB RAM, 1 core, and 20 GB of disk. On the live server the relay measures at roughly 20 MB of memory and half a percent of one core.
• Browser chat on your own domain needs one variable, ALLOWED_ORIGINS. The WebSocket origin check, CORS, and the content security policy are all built from that list, so the site runs under your name, not ours.
• You become the first admin by typing /claim <code> with the one-time code the relay prints on first start. From then on, administration happens inside the app rather than over SSH.

Your server, your rules

One binary can be a chat server, a shared game world, a market directory, and a backup host for other people's encrypted data. You probably do not want all of that, so the features block in data/server-config.json switches each capability on or off.

"features": {
  "chat": true, "game": true, "market": true, "vault_backup": true,
  "uploads": true, "tasks": true, "voice": true, "live_video": true,
  "federation": true, "push": true
}

A disabled feature is refused rather than hidden: the endpoint answers 403 and names the feature, so a modified client cannot use it anyway. The live manifest is published on /api/server-info so clients and peers can see what a node offers before trying to use it. Health, identity, and moderation endpoints are always served, so you cannot lock yourself out of your own machine.

Full walkthrough: docs/admin/SELF-HOSTING.md.

The Market is a directory of signed objects

Providers and offerings are signed objects, not rows a server owns. You sign them with the same identity you chat with, the server validates them against the public schemas in schemas/provider.toml and schemas/offering.toml, and other nodes can replicate and verify them without trusting the node that served them.

• Only you can publish into your shop. An offering signed by a key that does not own the referenced provider entry is rejected.
• Re-running the import is the workflow. An offering is identified by provider plus your own stable SKU, so a repeat import publishes a fresh revision instead of a duplicate, and refreshes the entry. Offerings expire on a time to live, 30 days by default, so the directory does not fill with ghosts.
• Settlement is directory-only, by design. Any other settlement mode is refused. The platform lists and introduces, it never moves money and holds no funds.
• Every market view is a query over the same public object endpoint, so anything the app can show, a script can fetch.

curl "https://united-humanity.us/api/v2/objects?object_type=offering_v1"

node scripts/import-offerings.mjs \
  --server https://united-humanity.us \
  --seed-file seed.txt \
  --provider provider.json \
  --offerings offerings.json

Any HumanityOS node answers the same query for its own directory. Details: docs/admin/market-importer.md.

Contribute, or just watch

The work is done in the open, released into the public domain, and shipped in small versioned increments. Humans and AI agents are both first-class contributors, and the onboarding documents say so explicitly.