neuwirth
/
levineuwirth.org
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

auto: 2026-03-25T13:45:34Z

This commit is contained in:
Levi Neuwirth 2026-03-25 14:45:34 +01:00
parent 9626f6795a
commit 19a76f8fbf
2 changed files with 31 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
content/colophon.md
View File

@ -45,26 +45,15 @@ the encoding is luminance rather than hue.]
## The Build
::: dropcap
[TODO: Hakyll and Pandoc. Why Haskell. The compile step as philosophy — this site is
a program and the content is the source code. The analogy to compiled software: readers
receive a deterministic artifact, not a runtime rendering decision.]
:::
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.
[TODO: What Pandoc [AST]{.smallcaps} filters do. The filter chain: wikilinks →
preprocessor, then sidenotes, smallcaps, dropcaps, links, images, math. All
transformation before the reader arrives.]^[The full pipeline: Markdown source →
Pandoc [AST]{.smallcaps} → citeproc → filter chain (sidenotes, smallcaps, dropcaps,
wikilinks, external link classification, responsive images) → HTML. Complex math goes
through a second pass: KaTeX renders server-side at build time, producing static
[HTML]{.smallcaps}+MathML. No math rendering happens in the browser.]
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.
[TODO: The semantic search model — self-hosted [ONNX]{.smallcaps} weights served
same-origin, no external [API]{.smallcaps} calls. Why this matters for the site's
privacy posture.]
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.
[TODO: Build telemetry — pointer to `/build/` and `/stats/` for the empirical picture.
This section covers intent; those pages cover state.]
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}}
---
@ -126,11 +115,6 @@ The commit history, of course, is available for you to view and licensed accordi
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.
[TODO: The Tufte influence — *Envisioning Information*, the three-column layout, the
argument that footnotes interrupt reading in a way that marginalia does not. The
sidenote as a first-class typographic element rather than a concession to citation
convention. Credit: Said Achmiz for the sidenote positioning [JS]{.smallcaps} (the
implementation used here is a simplified fork).]
### No Tracking
@ -144,43 +128,40 @@ to inspect it, fork it, or, more broadly, do whatever you please with it.
### Living Documents
[TODO: The epistemic metadata system — `status`, `confidence`, `modified`, `importance`.
What each field means. Why marking `status: Ongoing` on a document matters: it is an
honest claim about the document's relationship to the author's current thinking, rather
than the implicit permanence that publication usually signals. The modified date is
not decorative; it is the reader's primary signal for whether to treat a document as
settled or in flux.]
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
[TODO: gwern.net — the primary architectural and philosophical ancestor. What was
taken (sidenotes, living documents, epistemic metadata, semantic zoom, the long-form
personal essay as the primary unit). What was changed (visual register — gwern's
monochrome is denser; this site is more spacious — and scope).]
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.
[TODO: Tufte — *Envisioning Information* and *The Visual Display of Quantitative
Information*. The three-column layout, the sidenote tradition, the principle that
good typography is invisible.]
[TODO: The personal website tradition more broadly — the early web's culture of
idiosyncratic personal pages before social media collapsed everyone into the same
templates. This site is partly an argument that that culture was worth having.]
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. Some pages are marked `status: Stub` for good reason. This is acknowledged
rather than concealed, because a site that presents itself as complete when it is not
is making a false claim about the relationship between the author and the work.
[TODO: Specific things that are in progress — content migration, the library portal,
the fiction and research portals as the corpus grows. The Recently section on the
homepage, deferred until the corpus supports it.]
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 is the authoritative record; this page is
the annotated summary.
page will change with it. The git history functions as an authoritative record; this page is my personal annotated summary.

6
content/gpg.md
View File

@ -4,17 +4,15 @@ title: GPG Key
Public key for [ln@levineuwirth.org](mailto:ln@levineuwirth.org).
**Key ID:** `XXXXXXXXXXXXXXXX`
**Key ID:** `B01A01AD1B5C9663`
**Fingerprint:**
```
XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
CD90 AE96 383B BAF4 15A1 D740 B01A 01AD 1B5C 9663
```
Download: [pubkey.asc](/gpg/pubkey.asc)
Also available on [keys.openpgp.org](https://keys.openpgp.org).
## Verification
```bash