Sophia Host

What separates a capable organization from a collection of individuals is not talent — talent is rarely the constraint.

It is the infrastructure through which knowledge stops being lost, effort stops being duplicated, and each person's work begins to compound on what others have already solved — infrastructure that, when closed, imposes a ceiling on that process, because what cannot be examined cannot be improved, and what cannot be improved will eventually be the reason you fall behind.

Independent operation, shared foundation. That is what this infrastructure makes possible.

IRC

Web

Two tools, distinct purposes. The wiki holds knowledge — structured, searchable, owned by whoever writes it. The project board holds work — tasks, coordination, and the thread that connects both. Together they form the connective tissue between what people know and what people do.

Knowledge Base

A knowledge base that fragments across tools or depends on individual discipline tends toward entropy. Most platforms assume information flows downward, producing orderly systems that are brittle in practice — those closest to the work rarely have the access or incentive to keep them current, and the knowledge that actually moves an organisation remains outside.

Basilar inverts this. Flat files make the system portable and recoverable; page‑ and group‑level access controls allow private, shared, and open material to coexist natively, without workarounds. Contribution does not require permission, privacy does not require separation, and structure emerges from use rather than being imposed beforehand. This is not merely more convenient. It is more honest about how knowledge actually moves between people.

Project

Project coordination runs on Kanboard. Tasks carry their full context — links to relevant wiki pages, IRC channels, and reference material — so that the work and the knowledge that informs it remain connected rather than scattered. It is used for tasks, for structured discussion within those tasks, and for bringing together people who need to understand the same problem before they can solve it.

Gopher

Gopher is not a legacy choice. It is the correct one for a system where documentation must be honest about what it is: plain text, under version control, served without transformation.

The same files that live in the repository exist in /var/gopher and in user home directories. There is no conversion, no rendering pipeline, no separate layer to maintain — what is written is what is served. Users who prefer a web interface reach the same content through a terminal session via ttyd, with cgо handling the connection. The interface changes; the files do not.

This is what it means for documentation to be part of the system rather than about it.

gophernicus

Gophernicus is installed from ports and runs under its own unprivileged user, managed by inetd — nothing persistent, nothing beyond what the task requires. It serves only world-readable files from the designated document root; access is determined by the filesystem itself. The full configuration, including flag choices and their rationale, is documented and available through the Gopher space.

Email

Internal communication, correctly configured. The mail system receives external post without issue — tested against the major providers — but that is not its purpose. It exists for internal exchange, signed and encrypted by default, between accounts on the same system.

smtpd

The mail transfer agent is OpenSMTPD — base system, no substitution warranted. It listens on ports 25, 465, and 587, with TLS required on submission and offered on inbound. Outbound mail is DKIM-signed. Inbound mail without valid rDNS, or with mismatched forward-confirmed rDNS, is marked as junk before it reaches any user. Virtual users are handled through a passwd table; delivery passes to Dovecot over LMTP. Each decision in the configuration — relay rules, listener posture, IPv6 handling — is examined and recorded in the accompanying documentation, not left to assumption.

dovecot

Dovecot handles IMAP and LMTP. It receives mail from OpenSMTPD over a local LMTP socket and stores it in maildir format under /var/vmail, organised by domain and user. Authentication uses the same passwd file as smtpd, with passwords hashed using bcrypt. TLS is required on all client connections. The protocol surface, active listeners, and login class configuration are each set to what the system requires and documented accordingly — nothing is left enabled by default without examination.

Shell

Remote access, handled without excess. The configuration below defines how sophia.host provides shell access: one port, one address, one method of authentication. Nothing is left open that does not need to be.

sshd

SSH listens on port 1337 — a deliberate choice that avoids the constant noise of automated scans on the default port. It is bound to a single IPv4 address, with IPv6 explicitly absent rather than merely unconfigured; root login and password authentication are both disabled. Access requires an SSH key, and the daemon enforces correct permissions on all relevant files through StrictModes. The full configuration is available through the Gopher space.

Read how to create a user account on the server.

Dev

Due to US politics, git will no longer be supported on many platforms. Because of this, and because of the Unix alternative got, we will phase out git.

Code publishing and access control, without incidental complexity. The tools below handle what each one is built for — public distribution, authenticated access, and readable presentation — each operating within its own boundary.

Visit the git page for instructions on using sophia.host git services.

git-daemon

git-daemon serves public repositories over the native Git protocol — fast, anonymous, and read-only. It handles public distribution without authentication overhead or unnecessary configuration surface.

gitolite

Gitolite manages authenticated access to private repositories over SSH. It determines precisely who can read or modify which code, with configuration that is simple enough to audit and strong enough to rely on.

cgit

cgit provides a web interface for browsing the public repositories in /var/git. It has no access to private Gitolite repositories — the separation is architectural, not configured — and presents code over HTTPS without adding weight to the stack.

Network

TLS

TLS termination is handled by relayd — base system, no external dependency. It accelerates SSL/TLS for all services and forwards to the appropriate backend by inspecting the Host header. Each subdomain holds its own keypair; certificate files are symlinked into the paths relayd expects under /etc/ssl and /etc/ssl/private. Both IPv4 and IPv6 are handled by separate relay definitions sharing the same protocol block. Protocol constraints and health check behaviour are defined explicitly in the configuration and documented — commented options exist in the record precisely because the decision to include or exclude them was made consciously, not deferred.