168 lines
15 KiB
Markdown
168 lines
15 KiB
Markdown
---
|
||
title: Colophon
|
||
date: 2026-03-21
|
||
modified: 2026-03-21
|
||
status: "Draft"
|
||
tags: [meta]
|
||
abstract: On the design, tools, and philosophy of this site — and by extension, its author.
|
||
---
|
||
|
||
::: dropcap
|
||
A personal website is not a publication. It is a position. A publication presents work
|
||
in a finalized, immutable state, and carries with it some sort of declaration - "this is my most polished and prized work!";
|
||
a position is something you inhabit, argue from, and continuously
|
||
revise in public. This page explains the design decisions forming my broader **position** and why they took the form they did.
|
||
|
||
What follows is a colophon in the grand old sense: a printer's note at the end of the book,
|
||
recording how it was made, who made it, etc. The difference: here, the
|
||
printer and the author are the same person, and the process of making is itself not only *a* form
|
||
of argument, but *the only* form of argument permitted.
|
||
:::
|
||
|
||
---
|
||
|
||
## Typography
|
||
|
||
::: dropcap
|
||
You are reading this sentence in SPECTRAL, which is not only a font with particular personal importance to me, but also an exceedingly pleasing font to read. [OpenType]{.smallcaps} features — `smcp`, `onum`, `liga`, `calt` are used throughout the website, which necessitates our self-hosting setup.^[Google Fonts strips OpenType features during
|
||
subsetting for bandwidth. Self-hosting with `pyftsubset` preserves `smcp` (small
|
||
capitals), `onum` (old-style figures), `liga` (common ligatures), and the full optical
|
||
size range. The difference is visible: old-style figures sit on the baseline rather
|
||
than hanging above it, small capitals are drawn to match the x-height rather than being
|
||
shrunken full caps, and ligatures prevent collisions in letter pairs like *fi* and *fl*.]
|
||
:::
|
||
|
||
The UI and headers are Fira Sans. Variation is good, and moreover, humanist sans are rather ubiquitous (we have Frutiger to thank for this fact!) - perhaps I am making some type of statement by not choosing one of the more corporation variations of it, like the dreaded Calibri and Tahoma you might recognize from Microslop (formerly known as *Microsoft*) products. Code uses Jetbrains Mono, which is simply the font that I use within my editor. Code should look like code, simple as that.
|
||
|
||
The monochrome palette is an application of restraint grounded in my studies of Tools for Thought.
|
||
Color is often used to do work that typography
|
||
should do, such as demonstrating hierarchy, creating emphasis, etc. When those
|
||
functions are handled by weight, size, and spacing instead^[Color and saturation/hue are actually well known to be less effective than other means of distinguishment. I refer you to Tufte's *The Visual Display of Quantitative Information* for more.], color becomes available for the things it cannot be substituted for — and on a site with no data visualizations
|
||
requiring color encoding, those things turn out to be very few.^[The one exception is
|
||
the heatmap on the statistics page, which uses a four-step greyscale scale. Even there,
|
||
the encoding is luminance rather than hue.]
|
||
---
|
||
|
||
## The Build
|
||
|
||
This is a [Static Website](https://en.wikipedia.org/wiki/Static_web_page). For the purposes of this website, though the content is highly dynamic and iterated upon, the medium of expression is rather stable. There are numerous advantages to using a static webpage, many of which are focused at the Hetzner box from which this webpage is served. I use [Hakyll](https://jaspervdj.be/hakyll/) for reasons of performance, extensibility, and, of course given the underlying language Haskell, elegance! I had been wanting to do a project in Haskell ever since I took my undergraduate programming languages course,^[The programming languages course at Brown, somewhat infamous, is taught entirely with Racket, which is essentially a dialect of Lisp. The course itself is extremely focused within the functional paradigm as far as implementations go. I am aware that Racket itself, curiously, has some means by which static webpages can be built - the course infrastructure was produced this way, and this website has in a few places taken minor inspiration from it!] and Hakyll was more extensible and thus suitable than the alternative I was looking at most strongly, Hugo (in Go, a language with which I am intimately familiar). The philosophy of a static website is that the website is a program and the content is the source code^[Source code here **chiefly distinct** from mere markup language, like HTML.]. The step of compilation present in Haskell, which is outlined below, means that what you have here received in your browser is not merely a runtime rendering decision, but rather a deterministic artifact. By this step of compilation, the [Markdown](https://en.wikipedia.org/wiki/Markdown) in which I write these webpages is transformed to exactly what you currently see.
|
||
|
||
The [AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree) we use is heavily customized and modified. The chain is roughly markdown -> pandoc -> citations -> wikilinks -> preprocessing -> sidenotes -> smallcaps and dropcaps -> links -> images -> math. Mathematics with LaTeX requires a second pass and is rendered at build-time with KaTeX - no math rendering occurs in your browser. Samples from music are displayed as SVGs, generally typeset with Lilypond through some helper scripts I wrote to automate the process.
|
||
|
||
The semantic search model is a particularly intriguing aspect of the website. The model used is self-hosted, with weights served from the same origin. There are NO external API calls when you use this, in contrast to just about every other similar feature on other websites. This is essential for the privacy model that this site strives to achieve - see **Design Decisions** for more.
|
||
|
||
A full accounting of what this build process has actually produced is available at the [[Build]] page. It is generated automatically at each compile: corpus word counts, length distributions, tag frequencies, link analysis, epistemic coverage, repository metrics, and build timing — all computed from the same source tree that produces the content. Think of it as the build system reporting on itself.
|
||
|
||
{{build}}
|
||
|
||
---
|
||
|
||
## The Computing Environment
|
||
|
||
::: dropcap
|
||
[TODO: The organizing principle for this section: configuration is code, privacy is
|
||
a first principle, tools should be earned rather than merely used. These are not
|
||
preferences but positions, and this site is downstream of them.]
|
||
:::
|
||
|
||
### Desktop
|
||
|
||
[TODO: Gentoo Linux, Hyprland, Levshell (custom shell via Quickshell). Why Gentoo:
|
||
compilation for performance, fine-grained [USE]{.smallcaps} flag control, the
|
||
community. Why Hyprland: tiling window management as a productivity commitment.
|
||
[AMD]{.smallcaps} hardware throughout.]^[The personal computing setup is documented
|
||
in greater depth on the [[Me]] page. This section focuses on what is directly
|
||
relevant to how this site is built and maintained.]
|
||
|
||
### Laptop
|
||
|
||
[TODO: Arch Linux on ThinkPad P-series. Why Arch rather than Gentoo on battery-
|
||
constrained hardware. The continuity of the Hyprland environment across machines —
|
||
the same keybindings, the same visual language, the same muscle memory.]
|
||
|
||
### Editor
|
||
|
||
[TODO: Emacs. Everything written and coded in Emacs. The relationship between the
|
||
editor and the content — writing Markdown in Emacs with a Hakyll watcher running is
|
||
as close to a [WYSIWYG]{.smallcaps} experience as the workflow gets.]
|
||
|
||
### Privacy-First Computing
|
||
|
||
[TODO: Self-hosted email and [VPN]{.smallcaps}. LibreWolf over Firefox (the Chromium
|
||
monopoly and Mozilla's drift). GrapheneOS. The principle: privacy as a first principle
|
||
means building the infrastructure first, not bolting on settings after. The same
|
||
principle applies to this site — no tracking is not a policy decision, it is an
|
||
architectural one.]
|
||
|
||
---
|
||
|
||
## [AI]{.smallcaps} and This Site
|
||
|
||
::: dropcap
|
||
I will never use AI to write, whether for my personal communications with anyone or for pieces on this website. I take this extremely seriously - writing is religious in severity to me. The writing on this website is wholly human and wholly my own, to the extent that any writing can be.
|
||
:::
|
||
|
||
Much of the code that comprises the build system of this website was created in collaboration with AI. Rather than "vibe coding" proper, this was the result of an intensive engineering process where AI and I were equals in collaboration. Notably, all of the major architectural choices, design decisions, idiosyncracies, and elements of the tech stack were chosen entirely by me, and AI systems were only used to automate production of some (but not all) of the code that was required.
|
||
|
||
The commit history, of course, is available for you to view and licensed accordingly - see **No Tracking** for more.
|
||
|
||
---
|
||
|
||
## Design Decisions
|
||
|
||
### Sidenotes
|
||
|
||
The sidenotes are provided by a JavaScript file that was forked from the website of Gwern Branwen and authored by
|
||
Said Achmiz; I have simplified the script to fit the needs of this website and made some minor modifications.
|
||
|
||
|
||
### No Tracking
|
||
|
||
The site has no analytics, no visit counters, no fingerprinting, and no third-party
|
||
scripts.^[This is enforced at the nginx level via [CSP]{.smallcaps} headers, not just
|
||
by omission. The Content Security Policy prevents any script not explicitly whitelisted
|
||
from executing. The whitelist is short.] The Hetzner VPS that provides this content runs
|
||
only open source software, and my machines use *almost exclusively*^[It is nearly impossible to run an entirely free system, but in approximation, it is actually wonderfully easy.] the same. The code is licensed under MIT and hosted
|
||
on a public repository at this domain with a [GitHub mirror](https://github.com/levineuwirth/levineuwirth.org); you are welcome
|
||
to inspect it, fork it, or, more broadly, do whatever you please with it.
|
||
|
||
### Living Documents
|
||
|
||
The dominant convention of academic and professional publication is that a document, once released, is finished. It carries an implicit claim: *this is what I think, full stop.*^[This is particularly problematic in academia, where there is a long tradition of researchers whose work was eventually disproven taking an extreme defensive stance, usually rooted in [confirmation bias](https://en.wikipedia.org/wiki/Confirmation_bias).] I find this convention dishonest in proportion to how seldom it is actually true. Thinking is continuous; positions shift; evidence accumulates; people change their minds and rarely say so in public. This site operates under a different premise, one that I strive to operate all of my life under.
|
||
|
||
Every essay and post on this site carries an **epistemic footer** — a structured block that reports my current relationship to the work. The footer only appears when a `status` field is set in the document's frontmatter; standalone pages and very short items omit it. The full set of fields:
|
||
|
||
- **Status** — a controlled vocabulary describing where the work stands: *Draft*, *Working model*, *Durable*, *Refined*, *Superseded*, or *Deprecated*. A document marked *Working model* is not just unfinished — it is a position I currently hold but would not stake much on. A document marked *Durable* is something I expect to hold up. *Superseded* means I wrote a better version; *Deprecated* means I no longer endorse it.
|
||
|
||
- **Confidence** — an integer from 0–100, representing my credence in the central thesis. Not false precision: a rough honest assessment is more useful than no assessment at all. When a `confidence-history` list is present, a trend arrow (↑ ↓ →) is derived automatically from the last two entries — so you can see not just *what* I think but whether I am growing more or less confident over time.
|
||
|
||
- **Importance** — how much I think this matters, on a 1–5 dot scale (●●●○○). Useful for orienting a reader who has limited time.
|
||
|
||
- **Evidence** — how well-evidenced the claims are, on the same 1–5 scale. An essay with high importance and low evidence is a speculative position and should be read accordingly.
|
||
|
||
- **Scope**, **Novelty**, **Practicality** — optional qualitative fields in the expanded footer. *Scope* ranges from *personal* to *civilizational*; *novelty* from *conventional* to *innovative*; *practicality* from *abstract* to *exceptional*. These are not ratings — they are orientations.
|
||
|
||
- **Stability** — auto-computed at every build from `git log --follow`. The heuristic: very new or barely-touched documents are *volatile*; actively-revised documents are *revising*; older documents with more commits settle into *fairly stable*, *stable*, or *established*. This requires no manual maintenance — the build reads the repository history and makes the inference.
|
||
|
||
The version history block, directly above the epistemic footer, uses a three-tier fallback: authored `history:` notes when they exist (written by me when the git log alone would not convey what changed), then the raw git log, then the `date:` frontmatter field as a creation record. `make build` auto-commits any changed content files before the Hakyll compilation runs, so the git log is always current.
|
||
|
||
The point of all this is simple: when you read something on this site, you should know what kind of claim I am making. The date a document was last modified is not decorative. A 40% confidence rating is not self-deprecation. The system is an attempt to make explicit something that most writing leaves implicit — where the author actually stands.
|
||
|
||
---
|
||
|
||
## Influences
|
||
|
||
The amount of influences on this website is immense, and cannot be detailed in the fullest extent. Every other webpage that I have visited, whether beautiful or pitiful, has evoked some type of reaction or response in me, and that response has played some role, even if minute, in the design of this website. I can point to Tufte's influence on many of my design choices, and for the introduction to Tufte, I am thankful to CSCI1377 at Brown. I am thankful to the many other courses I took in my undergrad that influenced how I interact or ideologically view visualizations, networks, systems, etc.
|
||
|
||
The tradition of the personal website is one that is built on a sense of community and interaction. I am thankful to everyone else who has a personal website and shares their content with the world. I am also particularly greatful to the open source and broader open culture movements, who have given me and the world so much. This website would not exist without you - and I wouldn't be the person I am without your influence - what a role model!
|
||
|
||
---
|
||
|
||
## The Future
|
||
|
||
This site is unfinished. Several portals have no content yet. The annotated bibliography
|
||
is sparse. I am in the progress of migrating content, so stay tuned!
|
||
|
||
The colophon itself is a living document. When the site changes substantially, this
|
||
page will change with it. The git history functions as an authoritative record; this page is my personal annotated summary.
|