Running a public Xudanu server: terms to consider

Notes for operators. Not legal advice — adapt to your jurisdiction and situation.

Your server, your rules

The software ships without terms of use because it doesn't get to decide them — you do. If your server is private (you and a few collaborators), you may need nothing formal at all. If it is public, a short terms-of-use page is worth having before strangers arrive. The demo server's terms are one example: xudanu.com terms of use.

The three things every public server should state

Content ownership and licence. Authors keep copyright; you need a grant to store, serve, transclude, and verify content — that grant is what makes the system's features lawful to operate.
Moderation rights. The operator may remove rule-breaking content and revoke access. Say so up front; the admin console and content policy settings exist to back it up.
No warranty, no availability promise — unless you intend to offer one.

Things worth stating that are specific to this system

The server never handles money. This is a hard design rule of the protocol, not just a policy — fees and settlement live outside the system, if anywhere.
Per-work licences govern reuse (ARR / Transcopyright / CC-BY / CC-BY-SA / Public Domain). Transclusion compliance warnings are enforced by the client; your terms should point authors at setting licences deliberately.
Attribution is public by design. Authorship is cryptographically displayed. A privacy note that says so plainly is better than silence.

Your data, your responsibility

All data lives in your container volume or data directory — nothing leaves your machine, and the Xudanu project has no access to, control over, or responsibility for servers it does not operate. Back up your data directory; the snapshot format and backup/restore steps are in the documentation.

Defaults that help

edit_policy: owner-only (set via admin console) network/external links: off by default content filter: on (1 MB text cap)

Review these in the admin console before going public. The server directory, federation, and cross-server features are all opt-in — leave them off until you mean them.

Identity models — your choice per server

Identities are created in-app by default: no email, no external accounts, pseudonymous by design. If you want externally accountable identities instead (or as well), enable OAuth sign-in — per provider, by setting credentials at startup:

In-app only (default) — set nothing. OAuth routes answer "not configured"; the sign-in buttons never appear.
GitHub — XUDANU_GITHUB_CLIENT_ID + XUDANU_GITHUB_CLIENT_SECRET
Google — XUDANU_GOOGLE_CLIENT_ID + XUDANU_GOOGLE_CLIENT_SECRET

The app detects what your server has configured (via /health) and shows exactly those buttons. Callback URLs: https://your-host/auth/github/callback and https://your-host/auth/google/callback. Setting credentials is the toggle — remove them and restart to disable.

Getting GitHub credentials (5 minutes)

GitHub → Settings → Developer settings → OAuth Apps → New OAuth App
Name and homepage as you like; callback URL as above
Register → copy the Client ID; click Generate a new client secret and copy it immediately (shown once; regenerating invalidates the old one)
Leave wildcard matching, device flow, and token expiry unchecked

Getting Google credentials (10 minutes)

console.cloud.google.com → pick or create a project
Search the console for Google Auth Platform → Get started: app name, logo, support email; audience External
Then Clients → Create client → type Web application → authorized redirect URI as above
Copy the Client ID (ends .apps.googleusercontent.com) and Client Secret (starts GOCSPX- — don't confuse the two)
The consent screen starts in Testing mode: only listed test users can sign in. When strangers should sign in, return to Audience → Publish app (basic profile scopes publish without review; users see an "unverified app" note they can click through)

Wiring it in

Set the four environment variables on the server process (Docker: an env_file beside your compose file works well) and restart. Verify with /health — it reports oauth_providers — and check the sign-in buttons appear. New users create an identity on first sign-in; the local in-app identity path remains available regardless.

Worth knowing

The server keeps a tamper-evident security log (chained, hash-verified) of administrative and protocol events — not document content. Disclosing it in your terms is a trust feature, not a burden.
EU operators: identities are pseudonymous, but if people use your server, personal-data rules may apply to you — consider a short privacy note alongside your terms.