tilde.club/docs/community.md

Website, signups, and community tools

A working shell and a place to publish are enough to start. Add community tools when someone will maintain them. Each operator application needs its own code, service identity, writable data, update procedure, and backup entry.

Source repositories

These public repos provide parts of the tilde.club setup. Review the code and its revision before deployment; a public checkout is not necessarily identical to a local production copy.

Component	Source
Website and wiki	tildeclub/site
Home skeleton	tildeclub/tilde.etcskel
Account creation	tildeclub/makeuser; the collected live script has local integrations.
First-login wizard	tildeclub/welcome
Gopher daemon	tildeclub/Fossor
Gopher root content	tildeclub/gopherhole
Gemini root content	tildeclub/geminipage
MOTD	tildeclub/motd
Terminal wiki helper	tildeclub/wiki-cli
Recent-page listing	tildeclub/recently-updated
Botany	tildeclub/botany
Terminal blogging	tildeclub/ttbp
Forum client	tildeclub/ttrv
Helpdesk	tildeclub/helpdesk
File sharing	tildeclub/share

Deploy the website deliberately

Stage tildeclub/site outside the web root, select and record a revision, then review domains, contact addresses, signup behavior, JSON data, helper scripts, and web dependencies. The collected host's main root is /usr/share/nginx/html; configure its own PHP handler before deploying a PHP front page. The static bootstrap example deliberately does not execute PHP.

Keep .git, credentials, local environment files, Composer's development artifacts, and diagnostics out of the served copy. In particular, the reviewed site checkout has a signup _probe.php mail diagnostic; do not deploy that as a public endpoint. Install each application's declared dependencies using its lockfile in a build/staging location and check its supported PHP version. Do not infer a database requirement merely because MariaDB runs on the machine.

Make code root-owned and grant the backend write access only to the files it must update. Avoid making the entire document root writable by nginx or giving an operator application the same writable identity as every member's PHP. Test error pages, forms, mail submission, and file ownership on the target host.

The wiki has its own source/ Markdown and Makefile in the site repo. Review that build file, install its declared tools, and build in staging. Check that generated pages, local links, feeds, and navigation are present before syncing the output. A successful checkout is not a completed wiki deployment.

Signup requests are data

The reviewed website sends a request to the operator and records pending usernames and a suggested makeuser command in files beneath /var. The collected account script later removes the processed pending entry. Neither step is a transaction across the Unix account, mail, ZNC, helpdesk, and signup queue.

For a new host, reserve service/admin names, validate the username and contact address, parse the supplied SSH public key with OpenSSH, and review the request. A useful key-file check is:

ssh-keygen -lf /root/pending/member.pub

Keep that pending directory private. Construct privileged invocations from validated arguments or structured records. Do not paste an emailed shell command into a root terminal without inspecting its quoting and values, and do not execute a web-writable queue as a shell script.

The public form should handle duplicate requests, concurrent writes, invalid keys, rate limiting, CSRF where applicable, and mail failures. Trust forwarded client-address headers only from a configured trusted proxy. Keep request data and contact addresses out of the document root and define their retention. Running a signup form is not a reason to give the web process passwordless sudo.

First contact and support

Give the member a short welcome with:

• The hostname, username, SSH instructions, and host-key verification path.
• Where their pages live and which publishing services are enabled.
• First-login/MFA instructions and a recovery contact.
• Chat, mail, quotas, rules, and how to request help or packages.
• What account data is public and how to request removal.

The existing script emails a generated password and copies it to local mailboxes. That is its recorded behavior, not a requirement for a new installation. Choose an enrollment process consistent with your credential and mailbox-retention policy, and ensure temporary credentials are changed before normal use.

Keep MOTD concise. Put longer help in the wiki or a local help command, and publish an independent status/contact path for when the host is unavailable. Respect the difference between a maintenance notice and a public announcement of a new member's account; make the announcement policy clear.

Optional apps

Install apps under separate operator-managed paths and identities. Record the revision and dependency lockfile, local socket or port, reverse-proxy route, backup data, and a restart/restore test. If an app requires secrets, load them from protected config or the service environment, never from a public checkout.

For cgit, only expose repositories deliberately marked public, validate the user and repository mapping, and test path traversal. For Botany and similar shared apps, test whose files the backend can read and write. Keep IRC bot rate limits and reconnection behavior within the network's policy. Treat browser terminals and relay sockets as authenticated services, not harmless static content.

The older utilities retained under api/ and pages/ are not used as an automatic install system. Their current limitations and safer deployment rules are documented in the API notes and connection-list notes.