Public Architecture and Trust Model

The public record lives in Git

Zenmemes stores every canonical public fact as a small plain-text file in the content repository: posts, public keys, identity bootstrap records, approvals, reactions. Git tracks how that repository changes.

The SQLite read model and the static HTML release make the site fast to read. Both are derived. Delete them and you can rebuild them from the canonical files.

An operator can archive the repository, open any record directly, or rebuild a read model from scratch. The canonical post record defines the public post format. The production deploy runbook says which pieces are canonical and which are derived.

Your browser holds your private key

Your browser can generate and keep an OpenPGP private key when you set up an identity; instances can also enable automatic guest-key preparation. The site receives the public key, its fingerprint, and the signatures it needs to verify your signed public writes. It does not need your private key to publish or verify your identity.

Your visible identity is an openpgp:<fingerprint> value tied to the stored public key. The identity bootstrap record specifies how a public key, fingerprint, username, and first accepted identity event bind together. Readers can check the identity material and the record history themselves, with no opaque account database to trust.

Identity and access are separate

A saved key, a published identity, a signed action, an authenticated viewer session, and membership approval are different states. An identity hint only helps select presentation. Public browsing does not require a key; members-only content requires an authenticated approved identity. Documentation and the site's entry/recovery routes remain available before approval.

The Authentication Modes and Access reference explains the site settings, access matrix, action-specific permissions, and recovery when a session expires or a browser key is missing. It is the current authentication reference; older session plans retain historical alternatives.

Where secrets live

No secrets go in the public content repository, the application source, the public assets, or these docs. Member private keys stay in the browser. They never enter the forum record or the application checkout.

Operators can still hold server-side secrets. Optional LLM features need provider credentials, and that private configuration sits outside public/ and outside Git. Private queues, LLM exchanges, and other operational state stay out of the public record too. You still have to trust the operator with that private state.

What visitors can inspect

• This site renders the same Markdown documentation committed with the application, and each page shows its exact source path.

• The Tools (source unavailable) page links to repository and read-model backups; on members-only instances, these require authenticated approved access.

• Activity and source views show canonical record and commit context where it is available, subject to the instance's access policy.

• The CLI reference and runbooks describe rebuild, backup, signature-audit, and release procedures.