INIO

Datainnbrudd i Lørenskog: skaden har skjedd, hva nå?

Mon, 12 Oct 2026 00:00:00 +0000

Det fine med historien er at vi kan lære av den. Det betyr ikke at historien er vakker, ei heller at den ender godt. Her er en historie relatert til datainnbruddet i Lørenskog kommune.

Det som kommer etterpå

Her er hva du kan risikere å møte dersom du er blant dem som ligger i de «tapte» 1,8 terabytene med data – eller omtrent 1,3 millioner filer.

Historien vi skal lære av, begynner i Finland. Psykoterapiselskapet Vastaamo ble utsatt for et datainnbrudd i 2018, og høsten 2020 begynte utpressingen. Pasientopplysninger om rundt 33 000 personer var stjålet.

Lørenskog har rundt 50 000 innbyggere. Vi vet ennå ikke hvor mange av dem som er berørt, men kommunen og mediene snakker om flere tusen, og materialet inneholder blant annet pasientjournaler fra psykisk helse og barnevernssaker. Det er samme type opplysninger som i Vastaamo.

Innholdet i filene har også en ubehagelig likhet. Det dreier seg ikke bare om navn og kontaktinformasjon, men om svært sensitive personopplysninger – opplysninger om psykisk helse, familierelasjoner og private forhold som mennesker med god grunn forventer at skal forbli mellom dem og behandleren.

Det er et viktig poeng i denne sammenhengen.

Vastaamo-saken (utpressing) er nå seks år gammel. I 2020 ble det kjent at opplysninger om mer enn 30 000 pasienter var stjålet. Senere retts- og medieomtale har lagt tallet rundt 33 000. I 2020 var kunstig intelligens fortsatt noe de fleste av oss først og fremst forbandt med forskning, selvkjørende biler og science fiction.

Angrepsverktøyene var allerede effektive. Men verktøyene vi har i dag er ikke de samme som i 2020. Jeg tror derfor vi bør være forsiktige med å bruke Vastaamo som et tak på hva som kan skje med Lørenskog-dataene.
Vastaamo viser hva som kunne skje i 2020. Det er ikke nødvendigvis en beskrivelse av hva som kan skje i 2026.
Og når store mengder svært sensitive personopplysninger først er på avveie, er det derfor ikke sikkert at den største risikoen ligger i det som kan gjøres med informasjonen nå. Risikoen ligger også i hva som skjer når informasjonen berikes med data fra sosiale nettverk og åpne kilder, og hva som blir mulig å gjøre med det samlede bildet i morgen, eller om fem eller ti år.

Hva	Omtrent	Kilde
Pasienter med stjålne journaler	33 000	Yle
Ofre i straffesaken	over 21 000	Yle, februar 2024
Tiltalepunkter for forsøk på grov utpressing	over 21 000	Yle, mars 2024
Dømt for utpressing der offeret betalte	20 tilfeller	Yle, lagmannsretten
Ofre som har søkt statlig erstatning	rundt 6 000	Yle, juni 2026
Ofre som inngikk forlik med gjerningsmannen	1 200	Yle, mars 2024
Selvmord etter lekkasjen	ukjent; en advokat for ofrene kjenner til tilfeller	Yle, mars 2024
Andre konsekvenser (frykt, sykmelding, isolasjon)	ikke registrert	se under

NB Tallene bør leses som størrelsesordener, ikke som et komplett skadeomfang. Fravær av dokumentasjon er ikke det samme som fravær av hendelser.

Om betalingene

Vi vet at det gikk betalinger til hackerens bitcoin-lommebok. Det er imidlertid uklart hvor mange det var, og om alle kom fra ofrene.

Det er derfor viktig å skille mellom observerte betalinger og antall ofre som betalte. Det første kan vi telle; det andre vet vi ikke.

Vi vet også at utpressingen var omfattende. I den senere straffesaken ble det reist over 21 000 tiltalepunkter for forsøk på grov utpressing. Gjerningsmannen ble i tillegg dømt for 20 tilfeller der utpressingen faktisk førte til betaling.

Om selvmord og selvmordsforsøk

Her er tallene om mulig enda vagere.

Under rettssaken opplyste advokat Jenni Raiskio, som representerte ofre, at hun hadde blitt kontaktet av personer hvis pårørende hadde tatt livet sitt etter at pasientopplysningene ble stjålet og publisert. Hun fortalte også at andre ofre hadde vurdert selvmord etter lekkasjen.

Det betyr ikke at vi kan slå fast at lekkasjen var årsaken i de enkelte tilfellene. Det betyr heller ikke at dette er et komplett tall. Det er rapporterte tilfeller fra en advokat som representerte rundt 1 500 ofre.

Jeg har heller ikke funnet en samlet offentlig undersøkelse av langtidsvirkningene for denne gruppen. Det er mulig at forskning på traumeoppfølging etter andre store katastrofer kan gi et bedre grunnlag for å forstå slike langtidsvirkninger. Men det vil være en sammenligning, ikke dokumentasjon av hva som faktisk skjedde med Vastaamo-ofrene.

Det er nettopp dette som gjør tallene vanskelige å bruke: Vi har ganske gode tall på hvor mange filer som ble stjålet. Vi har langt dårligere tall på hva tyveriet gjorde med menneskene filene handlet om.

Andre dokumenterte konsekvenser

Det finnes likevel en rekke beskrivelser av konkrete konsekvenser for ofrene:

sykmelding og sosial isolasjon; enkelte ofre har fortalt at de sluttet å gå ut eller tok fri fra arbeid
frykt for at arbeidsgivere, familie og bekjente skulle få tilgang til journalopplysningene
frykt for identitetstyveri og behov for å beskytte personnummer og andre identifikasjonsopplysninger
angst, skam og mistillit til helsevesenet
personer som ikke lenger ønsket å oppsøke psykoterapi
videre spredning av journalopplysninger på nettet, også etter at det opprinnelige innbruddet var kjent
over 21 000 ofre i straffesaken; rundt 6 000 har søkt statlig erstatning, og 1 200 inngikk forlik med gjerningsmannen.

Erstatningssystemet gir også et bilde av hvor vanskelig det er å sette en verdi på skaden. Statens erstatningsordning vurderte i utgangspunktet erstatningene til rundt 500–1 500 euro, avhengig av hvilken type opplysninger som var eksponert. I juni 2026 økte finsk forsikringsdomstol erstatningene i 11 saker, til 1 000–2 000 euro.

Det er verdt å merke seg hva disse summene faktisk forsøker å prise: ikke verdien av de stjålne filene, men lidelsen og belastningen som følger av at svært private opplysninger er gjort tilgjengelige for andre.

Vær beredt

Med blikket bakover håper jeg helsevesenet og krisestabene allerede har klare veiledere og kapasitet for det som kan møte ofrene nå. Ikke selve datainnbruddet, men for det som kommer etterpå.

Utpressingskrav:

Vastaamo viser at titusenvis av enkeltpersoner kan bli direkte mål for utpressing. I dag finnes det langt bedre verktøy for å søke i, sammenstille og korrelere store datamengder enn i 2020. Det gjør det mulig å automatisere en type målretting som tidligere krevde betydelig manuelt arbeid.

Betalinger:

Vi vet at det i Vastaamo-saken ble gjort betalinger til bitcoin-adresser knyttet til utpressingen. Gjerningsmannen er dømt for 20 tilfeller der offeret betalte, men hvor mange som faktisk betalte, er fortsatt uklart.

Personlig målretting:

Det mest alvorlige er kanskje ikke at noen kan finne en fil. Det er at informasjon fra mange filer kan sammenstilles. Familieforhold, navn, adresser, økonomi, helseopplysninger og andre identifikatorer kan i prinsippet settes sammen til et langt mer presist bilde av et menneske enn den enkelte journalen alene gir.

Selvmord og alvorlige psykiske reaksjoner:

Vastaamo-saken dokumenterer at ofre og deres pårørende rapporterte svært alvorlige reaksjoner, inkludert selvmord og selvmordstanker. Vi vet ikke hvor stort dette omfanget faktisk var. Nettopp derfor bør det ikke komme som en overraskelse dersom også Lørenskog-saken får konsekvenser som ikke lar seg fange i statistikken.

Arbeidstap og andre sosiale konsekvenser:

Vi har dokumenterte enkelthistorier om sykmelding, isolasjon og frykt for at opplysningene skal bli kjent. Vi har derimot ikke et samlet tall på hvor mange som fikk problemer i arbeidsliv, familie eller sosialt liv.

Det er kanskje den viktigste lærdommen fra Vastaamo.

Vi vet hvordan vi teller filer. Vi vet hvordan vi teller berørte personer. Vi er langt dårligere til å telle hva som skjer med menneskene etterpå.

En liten betraktning på tampen

Utpressing er også en økonomisk øvelse.

I Vastaamo-saken fikk over 20 000 personer krav om å betale 200 euro innen 24 timer, eller 500 euro innen 48 timer. Det tilsvarer en potensiell kravmasse på mellom fire og ti millioner euro. Gjerningsmannen ble dømt for 20 tilfeller der offeret betalte.

Det interessante er derfor ikke bare hvor mye hver enkelt kan bli presset for. Det er hvor liten andel av ofrene som trenger å betale før masseutpressing blir lønnsomt.

Med for eksempel 30 000 berørte personer ville et tilsvarende krav på 200–500 euro representere en teoretisk kravmasse på 6–15 millioner euro. Det er ikke en prognose for Lørenskog, men det illustrerer hvorfor store datamengder kan ha en annen verdi for en angriper enn den har for virksomheten som mistet dem.

Om arbeidsprosessen

Artikkelen bygger på egne observasjoner, erfaringer og undersøkelser. Jeg har selv valgt problemstilling, kilder og sammenlikningsgrunnlag, og utarbeidet analysen og tabellene. KI er brukt som redaksjonelt hjelpemiddel til blant annet språkvask, rettskriving, oversettelse og sammenstilling av kildemateriale.

Om selve hendelsen: https://www.lorenskog.kommune.no/it-hendelse/
Innbyggertall, Lørenskog kommune: https://www.lorenskog.kommune.no/postliste-og-innsyn/kommunens-planer/folkehelseoversikt-2024-2027/befolkningssammensetning/
NRK om innholdet i de stjålne dataene: https://www.nrk.no/stor-oslo/xl/folsom-info-om-tusenvis-av-innbyggere-ble-funnet-pa-det-morke-nettet-1.17963757
Yle – Vastaamo-saken og erstatningssakene (engelsk og finsk)
https://yle.fi/a/3-12152682
https://yle.fi/t/18-318971/en
https://yle.fi/a/7-10082735
https://yle.fi/a/74-20077285
https://yle.fi/a/74-20233310
https://yle.fi/a/74-20075316
https://yle.fi/a/74-20078417
https://yle.fi/a/74-20212466
BBC omtale av ofrene: https://www.bbc.com/news/articles/c62nzxqw45eo
Helsinki-times: https://www.helsinkitimes.fi/finland/finland-news/domestic/29048-vastaamo-hacker-wanted-after-appeal-rejected.html

Ansvarlighetsmatrise

Fri, 2 Oct 2026 00:00:00 +0000

Et arbeidsdokument, ikke juridisk rådgivning.

Tabellen samler situasjoner der informasjonssikkerhet svikter i offentlig sektor, og hvilke lover som kan gi den enkelte et personlig ansvar. Den er kontrollert mot lovteksten og forarbeidene, men skal også prøves av folk som arbeider med dette til daglig.

Jeg vil bruke den som grunnlag for å vurdere risiko for den enkelte – for helsearbeideren og for lederen: hva kan skje, hvor ofte skjer det, og hva står på spill.

Ser du en feil, en lov som mangler eller en situasjon som bør med? Still spørsmålet på LinkedIn, eller send meg en melding på Signal.

Situasjon / feil	Mulig pliktbrudd	Individuelt ansvar mulig?	Mulig rettsgrunnlag	Strafferamme / reaksjon
Bevisst gir uvedkommende tilgang til taushetsbelagte opplysninger	Taushetsbrudd	Ja	Straffeloven § 209, jf. forvaltningsloven § 13	Bot / inntil 1 år
Grovt uaktsomt lar taushetsbelagte opplysninger komme på avveie	Taushetsbrudd (plikten til å hindre at andre får adgang)	Ja	Straffeloven § 209 fjerde ledd, jf. forvaltningsloven § 13	Bot / inntil 1 år
Grovt taushetsbrudd: forsett om vinning, eller tap eller fare for tap for noen	Grovt taushetsbrudd	Ja, ved forsett	Straffeloven § 210	Inntil 3 år
Den som utøver eller bistår ved utøving av offentlig myndighet, bryter grovt en tjenesteplikt	Tjenestefeil	Ja	Straffeloven § 171	Bot / inntil 2 år
Som over, men grovt uaktsomt	Grovt uaktsom tjenestefeil	Ja	Straffeloven § 172	Bot / inntil 1 år
Tjenesteplikten brytes ved utøving av offentlig myndighet, med alvorlig ulempe eller skade som følge	Misbruk av offentlig myndighet	Ja	Straffeloven § 173 bokstav c	Inntil 6 år
Bevisst uriktig opplysning til offentlig myndighet under forklaringsplikt	Uriktig forklaring	Ja	Straffeloven § 221 første ledd bokstav c	Bot / inntil 2 år
Grovt uaktsomt unnlater lovpålagt personvernhandling	Personvernbrudd	Ikke etter personvernreglene; mulig etter straffeloven § 209	GDPR / personopplysningsloven (ingen straffebestemmelse)	Overtredelsesgebyr mot virksomheten
GDPR-sikkerheten er ikke egnet for risikoen	Brudd på art. 32	Normalt ikke direkte straff	GDPR art. 32, jf. personopplysningsloven § 26	Overtredelsesgebyr mot virksomheten
Brudd meldes ikke til Datatilsynet uten ugrunnet opphold, og når det er mulig senest innen 72 timer	Art. 33	Normalt virksomhetsansvar	GDPR art. 33, jf. personopplysningsloven § 26	Overtredelsesgebyr mot virksomheten
Berørte personer varsles ikke når bruddet sannsynligvis gir høy risiko for dem	Art. 34	Normalt virksomhetsansvar	GDPR art. 34, jf. personopplysningsloven § 26	Overtredelsesgebyr mot virksomheten
Ledelsen kjenner til alvorlig risiko og gjør ingenting	Mulig tjenestefeil	Mulig, hvis de utøver eller bistår ved utøving av offentlig myndighet	Straffeloven §§ 171 og 172	Inntil 1–2 år
Kommunedirektøren lar være å etablere eller følge opp internkontroll	Kommuneloven § 25-1	Ja som ansvar, men kommuneloven har ingen straffebestemmelse	Kommuneloven § 25-1	Administrativt og politisk ansvar
Kommunen mangler rutiner for å avdekke og følge opp avvik og risiko for avvik	Kommuneloven § 25-1 tredje ledd bokstav b og c	Ja som ansvar	Kommuneloven § 25-1	Som over
Kommunedirektøren vet om risiko, men sørger ikke for oppfølging	Internkontrollsvikt	Potensielt	Kommuneloven § 25-1, og straffeloven §§ 171 og 172 hvis vilkårene der er oppfylt	Inntil 1–2 år etter §§ 171 og 172
Noen, også helsepersonell, tilegner seg helseopplysninger uberettiget, forsettlig eller grovt uaktsomt	Urettmessig tilegnelse	Ja	Pasientjournalloven §§ 16 og 30 a; for helsepersonell også helsepersonelloven § 67	Bot / inntil 1 år
Grov urettmessig tilegnelse av helseopplysninger	Samme	Ja	Pasientjournalloven § 30 a andre ledd; helsepersonelloven § 67	Inntil 3 år
Sikkerhetsloven gjelder, og kravet om sikkerhetstiltak brytes forsettlig eller uaktsomt	Sikkerhetsbrudd	Ja, der loven treffer (den verner nasjonale sikkerhetsinteresser)	Sikkerhetsloven § 4-3, jf. § 11-4 første ledd	Bot / inntil 6 måneder
Taushetsplikt om sikkerhetsgradert informasjon brytes forsettlig eller grovt uaktsomt	Taushetsplikt	Ja	Sikkerhetsloven § 5-4 andre ledd, jf. § 11-4 andre ledd	Bot / inntil 1 år
Ansvarlig leder etter sikkerhetsloven unnlater risikovurdering og dokumentasjon	Brudd på sikkerhetsstyring	Ikke straffbart i seg selv; brudd på pålegg fra tilsynet er straffbart	Sikkerhetsloven §§ 4-1, 4-2 og 4-4; pålegg etter § 3-6, jf. § 11-4 første ledd	Pålegg; ved brudd på pålegg bot / inntil 6 måneder
Angriper bryter seg inn i kommunens datasystem	Datainnbrudd	Ja – angriperen	Straffeloven § 204	Bot / inntil 2 år
Angriper får uberettiget tilgang til informasjon som overføres elektronisk	Krenkelse av kommunikasjonsvernet	Ja – angriperen	Straffeloven § 205 bokstav b	Bot / inntil 2 år
Angriper skaffer seg tilgangsdata for å begå et lovbrudd	Tilgangsdata	Ja – angriperen	Straffeloven § 201	Bot / inntil 1 år

Blue/Green on Paper: Upgrading Forgejo Seven Major Versions

Thu, 1 Oct 2026 00:00:00 +0000

Blue/Green on Paper: Upgrading Forgejo Seven Major Versions

Our self-hosted Forgejo runs the fleet's git: every
repository, the CI webhooks, the container registry, the agents' issue
tracker. On 1 October 2026 it was running 9.0.3. Upstream was at 16.0.5.

Nobody had decided to stay on 9. An upgrade had been proposed in May, as a
blue/green switch, and the pull request was closed without being merged.
Nothing noticed: no check compared what we pinned with what existed
upstream, so the gap grew quietly for five months.

Blue/green on paper

Our architecture decision record lists Forgejo as a blue/green service: two
slots, one live, one idle; upgrade the idle one, switch traffic with a DNS
change, keep the old one as the rollback. When we went to use it, we found
it described a system that did not exist.

There was no blue slot. The address the May plan reserved for it had since
been given to a database server.
Every client reached Forgejo by its IP address: the reverse proxies,
the CI server, the agents' scripts, the apps that file bug reports, the
CI pipelines that push back to their own repositories, and every git
clone on every host. About 45 places across 14 repositories.
A DNS name existed, and the old runbook's cutover step was "change the DNS
record". It would have moved almost nothing.

The operator's call was to fix that properly first: every client reaches
Forgejo by name, and the cutover is a DNS change, as designed.

One name, two slots

The work, in the order it mattered:

One internal-only name. We picked a name that exists only in internal
DNS. A second alias also existed in public DNS, pointing at the public
proxy; a host that fell back to a public resolver would have sent git
traffic there. With an internal-only name, a wrong resolver fails loudly
instead of misrouting.

One variable decides which slot is live. The DNS role now renders both
Forgejo names from a single value. Our DNS answers with TTL 0, so the
switch is seen immediately.

The proxies resolve per request. nginx resolves a hostname in
proxy_pass or an upstream block once, at start. We learned in September
what that costs: after a reboot race, nginx came up before DNS and the
whole public site stayed down for hours. So the proxies use
resolver ... valid=10s and a variable:

location /forgejo/ {
    set $forgejo_backend "<internal name>:3000";
    rewrite ^/forgejo/(.*)$ /$1 break;
    proxy_pass http://$forgejo_backend;
}

Two things we only found by testing it in throwaway nginx containers
against an echo backend, with URLs containing %2F, spaces and query
strings:

rewrite ... break stops the rewrite module, and set is part of it.
Put set after the rewrite and the variable is empty: every request
returns 500.
proxy_pass with a variable and a URI does not strip the location prefix
the way the static form does. The rewrite above reproduces the old
behaviour byte for byte; the raw-URI alternative we tried first passed
%2F through undecoded, which differs from what Forgejo had always seen.

The agents keep their identity. The Forgejo CLI looks up its token by
host string. Adding entries for the new name the obvious way, with the
shared bootstrap token, would have made every agent act as the operator.
A small helper now copies each agent's own entry to the new name, and has
tests for exactly that.

Then the clients. Nine repositories got the same one-line kind of
change in their CI files and default URLs, each through review.

Rehearse on a copy

The blue slot is a new VM, same size, built by OpenTofu and configured by
the same Ansible role, with one difference while it holds a copy of live
data: webhook delivery is limited to loopback. The copy contains every
webhook the live server has, and a test push on blue must not start real
CI pipelines.

Copy while green keeps running. A consistent database snapshot through
SQLite's online backup API, then the repositories and package data
streamed with tar. 4.3 GB in about two and a half minutes; the same
number of files on both sides.
Start 16.0.5 on the 9.0.3 data. We were prepared to step through the
intermediate major versions. We did not need to: 64 migrations ran in
36 seconds, with no errors.
Verify the way people use it. API calls with an agent's token, a
clone and a push over SSH (the branch appeared on blue and not on green),
a container registry pull, a webhook test delivery that blue refused, and
the web UI in a real browser with the public URL routed to blue. HTTP
status codes alone have fooled us before.

The new slot also surfaced three problems that only a fresh host shows: a
log handler that tried to "reload" journald (it cannot be reloaded), a host
firewall that the old server never had and that blocked the Forgejo port,
and Forgejo 16 rewriting its own config file on start, which made every
Ansible run restart it. All three are fixed in the roles, so the next fresh
host does not hit them.

What went wrong

Applying the by-name change to one app, we re-rendered its environment file
with --limit set to the app host. The playbook's check that the database
password is set lived in a separate play for the control node, and --limit
skipped it. The file was written with an empty password and the API was
down for about two minutes. The dry run had shown the change; we read it
through a filter that dropped any line containing "password", to keep
secrets out of the transcript.

Two lessons, both now written down: the guard belongs inside the role,
where --limit cannot skip it; and when hiding secrets in a diff, mask
the values, never drop the lines.

Making drift visible

The root cause was not the old version, it was that nobody could see it.
Forgejo fell five months behind without anyone deciding it should, because
nothing was looking.

So the change that matters most is not the upgrade, it is a check. Every
Monday a job compares, for each component we pin, the pinned version with
the latest stable upstream release and, where the service reports it, with
the version actually running, and posts the result on the fleet's
coordination bus. On its first run Forgejo was seven major versions behind.
On Monday 5 October it reported Forgejo as current.

Forgejo was not the only one: the first run also found other components
behind, which nobody had been looking at either. We do not publish that
list. A list of which services run old versions is a map for an attacker,
and it is out of date the day after it is written.

That is the lesson. An upgrade closes one gap; monitoring stops the next one
from growing in silence. "What is behind" should be a query, not a memory.

The cutover

With every client on the name and the rehearsal green, the cutover was the
short part. We did everything that could be done in advance first: the dry
runs of both playbooks, and the file with the server's secrets. Then:

Stop green. From here its data is final.
Copy everything again, the same tar stream as in the rehearsal: 4.3 GB,
19,523 files, 197 seconds. The database checksum matched on both sides.
Give blue green's SSH host keys. Clients pin the server's key by name,
so to them the switch is invisible.
Start 16.0.5 and let it migrate, then point the one DNS value at blue.

Forgejo was down for about six minutes. Then the full check set, not a
sample: the API by name and through the public proxy, an SSH clone and push,
the web UI in a real browser, a webhook that started a real CI pipeline,
image builds that pushed to the registry and deployed, the CI login and the
log shipping.

Two things broke, and both were ours:

We stopped green while a CI deploy was still pulling an image. The
check that CI was idle and the stop went out together, instead of one
after the other. The old version kept serving; the deploy ran again
after the switch. The runbook now says: read the idle check, then stop.
The script that logs CI into Forgejo scraped a form field that
Forgejo 16 no longer has. One small fix, and a note in the runbook that
anything scraping a web page will break on a major upgrade.

Green stays stopped, untouched and pinned to the old version as the
rollback. At the next upgrade the slots swap roles: blue is live, green is
where the new version is rehearsed.

Why we run SSL Labs against every public service — including this site

Sun, 27 Sep 2026 00:00:00 +0000

A certificate that renews correctly is not the same as a TLS setup that works. This site's certificate renews fine — and yet, until recently, no externally-run test had ever checked what a real visitor's browser actually gets.

So when services go public around here, one of the first checklist items is an external scan: SSL Labs' SSL Server Test. We run it, we read it, and we treat the result as the baseline for the service, not as a one-time favour to the certificate.

I ran it against this site while writing this post. The result is A+, but the interesting part is what the report says about that result — and what a test like this does that a curl from inside the lab can't.

A certificate is not a configuration

Renewal tells you one thing: the certificate authority still issues you a signed certificate on schedule. It does not tell you:

whether the served chain is complete and trusted by every major client,
whether a browser and a generic script arrive at the same endpoint,
which protocol versions and cipher suites are actually negotiated,
whether HSTS is present and set to a sane value,
whether the hostname the visitor typed resolves to the same TLS endpoint the certificate names,
or whether an old, weak endpoint is quietly left enabled alongside the good one.

Those are configuration questions, and renewal software does not answer them. A certificate can renew forever on a host where the configuration behind it is broken, partial, or serving yesterday's defaults.

Why an external test, from a third party

The temptation is to test from inside: you know the certificate name, you can reach the host, you can even script a handshake. The problem is that inside-looking checks tend to test what you already believe.

An external scanner like SSL Labs sits outside your network, in roughly the position a real visitor does. It resolves the public name, connects over the public path, and grades what it finds — without any shortcut you get for being on the same LAN, in the same DNS zone, or already holding the private key. If your setup only works "from here", an external test is where that shows up.

It also tests the way clients actually test: through the browser's trust store, through the intermediate chain shipped by every major CA, through the HTTP stack that applies HSTS. It tests every IP address the name resolves to, and simulates handshakes from dozens of real clients, so your TLS answer has to be consistent across endpoints — not just correct on the machine next to the server.

What the report grades

SSL Labs walks through everything a real deployment must get right, in five sections:

Certificate: chain, validity dates, signature algorithm, key size, revocation coverage (OCSP/CRL).
Protocol support: which TLS versions are enabled and which are disabled. TLS 1.0/1.1 have no business being enabled on a public service in 2026.
Key exchange: whether forward secrecy is actually in force — not just advertised.
Cipher strength: per-protocol cipher selection, with the weak ones that should be disabled.
Configuration notes and HSTS: whether clients are instructed to skip plain HTTP, and whether that instruction is durable (includeSubDomains, a sane max-age).

For this site, the report found: a full and trusted chain, TLS 1.3 negotiated with a modern AEAD cipher (TLS_AES_256_GCM_SHA384), no protocol downgrades, strong key exchange, and HSTS set to max-age=31536000; includeSubDomains. That last line is what pushes an otherwise-good deployment from A to A+ on the report's scale.

Why it is on the launch checklist

We learned the hard way that "the page loads" and "the user connection is sound" are different claims. Every service we run publicly gets the same short list before it counts as live:

TLS 1.3 enabled, TLS 1.0 and 1.1 disabled.
HSTS set with subdomains, so a visitor never silently falls back to plain HTTP.
A complete, trusted chain — no missing intermediates concatenated by hand.
An external scan against the final public hostname, with the grade and its notes read — not just screenshot.
The certificate's renewal path is automated and monitored, so the setup that passed today is still the setup that serves tomorrow.

The tie between 4 and 5 is deliberate. A scan is a point-in-time photograph; renewal automation is what keeps the photograph true. Neither replaces the other, and a checklist that has one without the other is a checklist with a hole in it.

The honest caveat

A grade is a snapshot, not a promise. An A+ today means every client positioned like the tester is well served right now. It does not guarantee the configuration survives the next deploy, the next certificate rotation, or the next server rebuild — which is exactly why the scan is on the checklist when evaluating services, and the automation is what runs between evaluations.

If you run a public service, the same URL pattern works for yours:

https://www.ssllabs.com/ssltest/analyze.html?d=www.inio.no

Run it, read the notes under the grade, and fix what it flags — that's the point of the exercise. A certificate is table stakes. A configuration that earns its grade is the actual service.

Multi lingual support in the Helix editor

Fri, 18 Sep 2026 00:00:00 +0000

Writing in Markdown without a spellchecker is risky—especially if you write in multiple languages or have a habit of typing fast and making typos.

Here is a short, reproducible guide to setting up multilingual spell and grammar checking (English & Norwegian) in the Helix editor (hx) using mise.

Tech Stack

Helix (hx): Fast, modal terminal editor with built-in LSP support.
mise: Runtime and tool version manager used to manage language servers cleanly without sudo.
ltex-ls: LanguageTool-based language server providing spell and grammar checking.
marksman: Markdown language server providing document symbols, links, and completion.

Files Involved

mise.toml (or ~/.config/mise/config.toml): Installs and manages ltex-ls and marksman.
~/.config/helix/languages.toml: Defines the language servers and attaches them to Markdown.
.helix/languages.toml (optional): Per-project override to switch between English and Norwegian.

Step 1: Install the Language Servers with mise

Install ltex-ls (GitHub backend) and marksman:

# Global mise setup:
mise use -g github:valentjn/ltex-ls@latest
mise use -g marksman@latest

# Or declare in your project's mise.toml:
# [tools]
# "github:valentjn/ltex-ls" = "latest"
# marksman = "latest"

Tip on PATH: Ensure ~/.local/bin is in your $PATH. If needed, symlink the binaries directly:
ln -s ~/.local/share/mise/installs/github-valentjn-ltex-ls/latest/bin/ltex-ls ~/.local/bin/ltex-ls
ln -s ~/.local/share/mise/installs/marksman/latest/marksman ~/.local/bin/marksman

Step 2: Configure Helix (`~/.config/helix/languages.toml`)

Edit or create ~/.config/helix/languages.toml:

# 1. English spell checking (British English; use "en-US" for American)
[language-server.ltex-en]
command = "ltex-ls"

[language-server.ltex-en.config]
ltex.language = "en-GB"

# 2. Norwegian Bokmål spell checking
[language-server.ltex-nb]
command = "ltex-ls"

[language-server.ltex-nb.config]
ltex.language = "nb"

# 3. Attach marksman and ltex-en to Markdown
[[language]]
name = "markdown"
language-servers = ["marksman", "ltex-en"]

Step 3: Switching Between English and Norwegian

Running both ltex-en and ltex-nb simultaneously is not recommended because English text will be flagged as misspelled Norwegian and vice versa.

Instead:
- Keep ltex-en as your global default in ~/.config/helix/languages.toml.
- When working in a repository or directory that is primarily Norwegian, create a local .helix/languages.toml:

[[language]]
name = "markdown"
language-servers = ["marksman", "ltex-nb"]

Helix automatically merges project-level .helix/languages.toml with your global configuration.

Step 4: Verify the Setup

Check that Helix recognizes the language servers:

hx --health markdown

You should see green checkmarks for both servers:

Configured language servers:
  ✓ marksman: /home/inio/.local/bin/marksman
  ✓ ltex-en: /home/inio/.local/bin/ltex-ls

Summary

With mise managing the language server binaries and Helix natively handling multiple language servers per file type, you get real-time Markdown intelligence and grammar/spell checking with zero bloat and seamless switching between languages.

Fetch data from Open Street Maps

Mon, 14 Sep 2026 00:00:00 +0000

I need fake nodes in my grid to simulate data-points, providing dynamic data, I grabbed the nodes from OSM. Here is the script i used to grab Norwegian fuel stations.

  import requestsimport pandas as pd
  query = """[out:json][timeout:180];
  area["ISO3166-1"="NO"]["boundary"="administrative"]->.norway;
  nwr["amenity"="fuel"](area.norway);
  out center tags;"""
  response = requests.post(    "https://overpass-api.de/api/interpreter",    data=query)response.raise_for_status()
  elements = response.json()["elements"]
  rows = []
  for element in elements:    tags = element.get("tags", {})
      if element["type"] == "node":        latitude = element["lat"]        longitude = element["lon"]    else:        latitude = element.get("center", {}).get("lat")        longitude = element.get("center", {}).get("lon")
      rows.append({        "osm_id": element["id"],        "osm_type": element["type"],        "name": tags.get("name"),        "brand": tags.get("brand"),        "operator": tags.get("operator"),        "latitude": latitude,        "longitude": longitude,    })
  df = pd.DataFrame(rows)df.to_csv("norway_fuel_stations.csv", index=False)
  print(f"Saved {len(df)} stations")

reMarkable syncbook

Fri, 11 Sep 2026 00:00:00 +0000

Raw steps and data collected while building this, kept here so nothing gets forgotten while the real README.md gets written by hand. Not meant to be the
final doc

Pull reMarkable tablet notebooks over SSH and render them to PNG/SVG; push a modified page back, safely (backup first, hash-verify after).

No reMarkable cloud account, no desktop app, no USB required if your tablet is reachable over Wi-Fi/LAN -- just SSH.

Why

The reMarkable stores each notebook as a directory of pages in a reverse-engineered binary format ("lines v6"). syncbook doesn't reimplement that format itself -- it shells out to the real ssh/scp for transport (so it inherits your normal host-key handling and ssh-agent, nothing reimplemented) and to rmc /
cairosvg via uv for rendering. syncbook itself is just the orchestration: find the notebook, move the right files, verify they arrived intact.

Prerequisites

A reMarkable tablet with SSH enabled (see below).
uv installed (curl -LsSf https://astral.sh/uv/install.sh | sh)
-- used to run rmc/cairosvg without any manual pip install step.
Rust (to build syncbook itself): cargo build --release.

Enabling SSH on the reMarkable

On the tablet: Settings -> About -> General/Software, tap the entry near the bottom that shows a serial number and a one-time root password. This also shows the tablet's IP address on your current network (or use 10.11.99.1, the fixed address reMarkable always assigns itself over USB).
From your computer, do one interactive login with that password to confirm connectivity:

ssh root@<tablet-ip>

Install your public key so you never need the one-time password again:

cat ~/.ssh/id_ed25519.pub | ssh root@<tablet-ip> \
  'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

(Generate a key first if you don't have one: ssh-keygen -t ed25519.) Note the source file before the pipe and the chmods -- sshd will silently ignore authorized_keys if the permissions on ~/.ssh or the file itself are too open.

Confirm the key-based login works before moving on:

ssh -o PreferredAuthentications=publickey root@<tablet-ip> echo ok

Building

cargo build --release
mkdir -p ~/bin
cp target/release/syncbook ~/bin/syncbook

Make sure ~/bin is on your PATH (add export PATH="$HOME/bin:$PATH" to your shell profile if it isn't already).

First run

syncbook doesn't keep its own config file -- both pullrm and pushrm connect via a normal ~/.ssh/config host alias (default name: remarkable), so plain ssh remarkable / scp remarkable:... on the command line behave identically to what syncbook does internally.

Run any command; if the alias isn't configured yet, you'll be prompted once:

$ syncbook pullrm "My Notebook"
No 'remarkable' entry found in ~/.ssh/config -- first-time setup for syncbook.
reMarkable hostname or IP: 10.11.99.1
Path to SSH private key [/home/you/.ssh/id_ed25519]:
Wrote Host 'remarkable' to ~/.ssh/config. Re-run your command to continue.

This appends a block like:

# BEGIN SYNCBOOK MANAGED (remarkable)
Host remarkable
    HostName 10.11.99.1
    User root
    IdentityFile /home/you/.ssh/id_ed25519
    StrictHostKeyChecking accept-new
# END SYNCBOOK MANAGED (remarkable)

Edit that block directly (e.g. to change the IP after switching from USB to Wi-Fi) -- syncbook only writes it once, on first run.

If you already have a working SSH alias for your tablet under a different name, just pass --host <name> instead of renaming anything:

syncbook --host my-existing-alias pullrm "My Notebook"

Usage

Pull a notebook by its visible name (as shown in the reMarkable UI) or by UUID:

syncbook pullrm "My Notebook"
# -> ./My_Notebook/<page-uuid>.rm, .svg, .png for each page, plus content.json

Push a modified page back (backs up the current on-device state first, verifies the upload by hash afterward):

syncbook pushrm "My Notebook" <page-uuid> ./modified-page.rm

Important: the reMarkable's own app (xochitl) only re-parses a page from disk when its notebook is opened -- there is no live-reload signal to
send. After pushrm succeeds, open (or close and reopen) the notebook on the tablet to see the change.

Don't restart xochitl itself (systemctl restart xochitl) to "force" a refresh -- during development of
this tool that caused a spurious blank page to appear, most likely because the currently-open document's in-memory state and the file on disk briefly disagreed across the restart. Simply opening the notebook is both safer and sufficient.

Backups

Every pushrm backs up the notebook's current .metadata, .content, and the target page's current .rm (if it exists) to ~/remarkable-backups/<UTC-timestamp>/<notebook-uuid>/ before touching anything on the device. Nothing is deleted automatically -- prune old backups by hand whenever you like.

Advanced: writing native ink annotations

pushrm will happily upload any valid .rm file, but constructing one that adds new pen strokes to an existing page -- e.g. to draw a native ink
annotation on top of someone's sketch -- is real surgery on a reverse-engineered CRDT format, not something this tool automates. It's documented as a worked example instead of a polished subcommand, because getting it right requires understanding two non-obvious things:

New content should go on its own layer, with its own freshly registered author ID -- see examples/annotate.py, which uses rmscene to build a Group, register it under the page's root, and add a Line to it.
A new CRDT sequence item must not fabricate a causal link to existing content. The natural-seeming approach -- pointing your new layer's
left_id at an existing item's ID, to insert it "after" that item -- gets silently accepted by rmscene's reader (which is lenient) but rejected by the real reMarkable app with rm.crdt.item Item: invalid origin left: ... / rm.crdt.sequence - invalid item in journalctl -u xochitl, because you never actually observed that item's insertion the way a real collaborating client would have. The correct, honest representation of an independently-added layer is left_id = right_id = CrdtId(0, 0) -- a concurrent, uncoordinated insert, which is exactly what real independent edits are. Using a fabricated reference caused this exact failure during development, and the app's defensive recovery from it produced a stray blank page in the notebook as a side effect.

Run it like:

python3 examples/annotate.py path/to/page.rm path/to/page-annotated.rm
syncbook pushrm "My Notebook" <page-uuid> path/to/page-annotated.rm

You'll need to adjust the circle's center/radius in the script to match where you actually want to annotate -- it's a worked example, not a general tool (finding a good general-purpose UI for "here's where to annotate" is future work, tracked as a shape/coordinate input problem, not a syncbook problem).

License

MIT licensed — see the LICENSE file in the syncbook repository.

Pulling charger data from NOBIL

Fri, 11 Sep 2026 00:00:00 +0000

NOBIL’s API provides data about public EV charging stations and charging points, primarily in Norway — available since October 2025. This is a great example of a public service.

The available station data includes:

Station and charging-point IDs
Name, address, municipality and country
Latitude/longitude coordinates
Operator and service-provider information
Accessibility and opening hours
Public/private access details
Vehicle types supported
Connector type—for example CCS, CHAdeMO, Type 2
Number of connectors
Charging capacity and power in kW
Payment and access information
Station descriptions, contact details and images
Update or modification timestamps
Real-time EVSE status where an operator supplies it

The real-time status values include AVAILABLE, CHARGING, BLOCKED, OUTOFORDER, RESERVED, INOPERATIVE, PLANNED, REMOVED, and UNKNOWN. Real-time data is supplied only for operators with an appropriate OCPI connection to NOBIL.

You need to register for an API key before using the conventional API. The data is made available under a Creative Commons Attribution 4.0 licence, subject to NOBIL’s usage terms.

How often can you pull it?

The public API page and the currently indexed documentation do not state a fixed request limit such as “one request per minute” or “1,000 requests per day.” Therefore, you should not assume unlimited polling. Use caching, avoid repeatedly downloading the complete database, and ask NOBIL for the permitted rate if you need high-frequency or commercial polling.

For normal station metadata, a sensible implementation would be:

Initial full import: once
Regular metadata refresh: every 15–60 minutes
Routine background synchronization: every few hours if minute-level changes are not important
Real-time availability: use NOBIL’s real-time WebSocket service instead of repeatedly polling the normal API

NOBIL’s real-time service returns updates through a WebSocket stream, so you receive changes rather than continually requesting the full dataset. You subscribe to the real-time product, obtain a connection URL using an API key, and then connect using WebSockets.

In practical terms: use the standard API for station details and configuration, and use the real-time stream for charger availability. Store the last response locally and only refresh data when necessary. Since NOBIL does not provide historical status data through the API, you would need to store successive real-time updates yourself if you want historical availability.

Keep up working for the greater good.

Serial Console to a Nexus 5010

Wed, 9 Sep 2026 00:00:00 +0000

Serial Console to a Nexus 5010

TODO: pull the Eth1/1 module — it's the one reporting invalid
calibration data below. Cheap enough to not be worth debugging further;
physically swap it out next time someone's at the rack.

The plan for the next phase of the fleet's network involves real managed
switching instead of the single unmanaged box currently sitting on the home
LAN. Step one of that plan arrived as a USB-to-serial adapter and a rollover
cable, reportedly plugged into the primary Proxmox host.

It was not plugged into the primary Proxmox host.

Wrong server first

A quick sweep of the primary host — lsusb, dmesg, journalctl -k since
boot, even a direct read of the built-in DB-9 COM port at 9600 8N1 — turned
up nothing. No serial chipset, no signal, silence. It has exactly one
physical serial port and five USB ports, all confirmed empty.

The adapter was on the fleet's second (currently standalone) hypervisor,
instead. lsusb found it immediately: a Prolific PL2303
USB-to-serial converter, cleanly bound to /dev/ttyUSB0. A raw
stty -F /dev/ttyUSB0 9600 cs8 -parenb -cstopb -echo raw followed by a
carriage return got an instant, live reply — the switch was already mid
first-boot, sitting in its setup dialog asking about password policy.

Lesson, filed under the fleet's running "verify enforcement, not presence"
theme: a report that a cable is plugged into host A is a claim about host A,
not evidence about host A. Two live Proxmox hosts exist; check both before
concluding a physical link isn't there.

What showed up on the other end

The switch identifies itself, once logged in, as:

Cisco Nexus Operating System (NX-OS) Software
Copyright (c) 2002-2010, Cisco Systems, Inc.
kickstart: version 4.2(1)N1(1)
system:    version 4.2(1)N1(1)
compile time: 4/29/2010

A Nexus 5010 — fixed-config, twenty 10-Gigabit SFP+ ports, running a
software image compiled in April 2010. Old enough that a few of its
defaults needed working around, which turned out to be the most useful part
of the exercise.

First boot, deliberately incomplete

The Day-0 dialog on NX-OS asks a long string of yes/no questions before it
ever offers a prompt. Answered narrowly on purpose:

Secure password standard: yes.
admin account password: set, not written here — see the fleet's
usual secrets handling.
A second login account: no — NX-OS's admin already is the
superuser-equivalent; nothing else was needed yet.
SNMP strings, NTP server, Fibre Channel, telnet, HTTP server: all
declined. No community strings worth setting before there's a monitoring
target to point them at, and telnet/HTTP are just attack surface with SSH
already in the plan.
Out-of-band mgmt0 IP and default gateway: declined, deliberately.
The addressing plan for the new network segment doesn't exist yet — better
to leave the switch reachable only by console until it does, than guess an
IP that conflicts with whatever gets decided next.
SSH server: enabled, with a freshly generated 2048-bit RSA host key
(RSA offered over the legacy DSA option).

The switch rebooted, applied the config, and came back with a clean
switch# prompt.

A key type from the future

Adding the operator's SSH public key to the admin account for later
passwordless access seemed like the obvious next step —
username admin sshkey <key> is the NX-OS equivalent of dropping a line into
authorized_keys. It rejected the key outright: invalid SSH key format.

The key in question was Ed25519. Ed25519 support landed in OpenSSH in 2014.
This NX-OS image is from 2010. The command's own inline help (username admin sshkey ?) doesn't enumerate accepted key types — it just says LINE
— so the rejection reads identically whether the problem is a malformed
string or an unsupported algorithm entirely, which cost a few minutes
chasing a suspected serial-line corruption bug (a long pasted line did
appear briefly garbled on the wire, a red herring caused by console
auto-wrap at the default 80-column terminal width — fixed with
terminal width 511, and worth remembering for any future long paste over
this same console) before show version settled it. An RSA key is needed
for this device; ed25519-only keys don't have anywhere to go here yet.

What's actually plugged in

show interface transceiver on a NX-OS box is the equivalent of walking
down the row of ports with a flashlight:

Ethernet1/1
    sfp is present but not supported
   SFP calibration is invalid
Ethernet1/2, 1/3, 1/5
    sfp is present
    type is Fabric Extender Transceiver
    part number is PLRXPL-VC-S43-CG
Ethernet1/4, 1/6-1/20
    sfp is not present

Two findings worth writing down before anyone reaches for these later:

Three of the four populated ports are FET optics — Cisco's
Fabric-Extender-Transceiver SFP+, a cut-down 10G optic that only
establishes a link between a Nexus parent switch and a Nexus 2000-series
Fabric Extender. They will not link up to a server NIC, another switch, or
anything that isn't a FEX, no matter how good the fiber run is. If the plan
for this switch doesn't involve a 2000-series FEX downstream, these three
are the wrong optic for the job.
One SFP reports a hard failure: present, but flagged unsupported with
invalid calibration data — the kind of thing a bad or counterfeit module
produces, not something a config command fixes. Worth physically swapping
before assuming any port-level troubleshooting will help.

All twenty fixed ports show down in show interface status, which is
expected — nothing is cabled to a live partner yet.

Next: Ansible, once there's an address to talk to

mgmt0 is physically up (link negotiated at 1000 Mb/s) but carries no IP,
by design — bringing this switch under Ansible management is the next
phase, and it depends on the network addressing plan landing first. The
outline:

Add the cisco.nxos Ansible Galaxy collection (and its
ansible.netcommon dependency) to the control node.
A new inventory group in inio-infrastructure for network switches, with
ansible_connection=ansible.netcommon.network_cli and
ansible_network_os=cisco.nxos.nxos — this NX-OS image predates NX-API,
so it's classic CLI-over-SSH, not the REST-style API newer Nexus gear
offers.
Credentials in OpenBao, not the playbook — the password set today is a
known default and gets rotated once real management begins.
A role covering the fleet's standing observability baseline (syslog to
OpenObserve, NTP) plus VLAN/interface config, none of which can be
written meaningfully until the addressing plan exists.
The Cat6 (copper) SFPs that are still in transit will presumably replace
or supplement the FET optics currently occupying three of the four
populated ports, depending on what those links are meant to carry.

For now: password set, SSH enabled, transceivers inventoried, one bad optic
identified, and a decade-old assumption about key algorithms re-learned the
hard way. Console access remains the only way in until the network plan
says otherwise.

HOLD Ordered: Waiting for SFP.:

IKEA VIDGA connector

Wed, 29 Apr 2026 00:00:00 +0000

This is a connector for the rails used by the IKEA VIDGA curtain track systems. Personally, I find the connectors that came with VIDGA complicated and flimsy, especially when the hex bolts are already there.

The connector repurposes the hex bolts from the end terminators.

The STL file is only the gray piece. Place the connector halfway in the rail, and fasten with the bolt; It should be a snug fit.

Here you can download the connector STL file: connector-STL-file

DNS Resolver configuration and setup

Tue, 28 Apr 2026 00:00:00 +0000

DNS in a Distributed Homelab: Control, Constraints, and What Actually Works

As internal services evolve and automation becomes more central, one challenge keeps resurfacing: DNS management across locations and sites.

Keeping track of dynamically allocated IPs, ephemeral services, and changing infrastructure does not get easier over time — it becomes a source of increasing complexity.

To address parts of this, I've used and tested:

These help structure inventory, but they don't fully solve the problem of how DNS should behave in a dynamic, distributed environment.

The Context: A Distributed Setup That Grew Organically

I run a shared homelab/data centre setup across multiple physical locations together with friends. As the system has grown, so has the complexity around:

IP range management (dynamic public IPs and private ranges)
Routing (VPN)
DNS resolution (internal and external services)

Services move, scale, and get redeployed.

Once you start down the rabbit hole, static assumptions break down quickly ;-)

The Architecture: Simple, Distributed, and Actually Working

We've converged on a solution that is both simple and robust — and, importantly, it works in practice.

At the core is BIND, used to build a layered DNS structure.

Key principles

Each location runs its own local DNS resolver.
Resolvers point to secondary resolvers at other sites.
Data and resolution capability are distributed across locations.

Each resolver then forwards queries to internal DNS servers that:

Serve local IP ranges via internal zones.
Expose services through both internal and external URLs.
Enforce allow-lists for what can be resolved.

DNS as a Control Plane

A central idea in this setup is:

DNS is not just a lookup service — it is a control layer.

We log every request, and a "new request" will light up as a flare in the log rig.

Instead of allowing unrestricted resolution:

Unknown or non-approved queries are redirected to an internal "catch-all".
This catch-all acts as a controlled boundary.

From there, a deliberate "break glass" mechanism is available:

Authentication (username/password)
Temporary "resolve-all" access (e.g. during installation)
Or permanent allow-listing of specific domains

This introduces a balance between:

Security
Operational control
Flexibility when needed

Why This Matters

Letting everything resolve freely may feel simpler — but it quickly leads to:

Loss of visibility
Increased attack surface
Harder debugging
Unpredictable behaviour across environments

By constraining DNS and making access explicit, the system becomes:

More predictable
Easier to reason about
Easier to operate over time

The Trade-off: Friction vs Control

Yes — this introduces friction.

But it's intentional friction.

Most of our systems have no need to resolve external services. Exceptions are mainly updates and short bursts of activity — "nothing that can't be solved using a cron job."

We trade a bit of convenience for:

Traceability: We log behaviour to neo4j, and all new entries light up and are evaluated.
Reproducibility: When we redeploy a system, we know what it is supposed to talk to, and can preconfigure this during the instrumentation process using Ansible.
A clearer understanding of what our systems are actually doing.

Open Questions

Even though this setup works well, there are still open areas worth exploring:

We have still not reached a final plan for how to model inventory (IPs, services, DNS) consistently.
Where is the right boundary between automation and manual control?
Should DNS evolve into a policy engine — or stay a pure resolver?
How much dynamism can DNS realistically support before abstraction is required?

Monoculture outside the standard

Mon, 27 Apr 2026 00:00:00 +0000

Today I was called in to have a Teams meeting with a Norwegian government institution.

Being what I am, a person of standards, not implementations ;-). I am inclined to use free and open-source software that adheres to standards.

Logging into the meeting was easy peasy: select the camera (I have multiple); allow the browser/Teams URL to use my mic and camera; blur the background, before settling on a background that fit my personality.

Only to watch myself making funny faces for five minutes.

Great was my surprise when no faces showed up. The other participants could see me, but I was unable to see them.

Ruffling around for five minutes to get things working... we rescheduled.

There are some advantages to seeing each other when it comes to communication.

This is not a bug

What did happen?

Sound was working, my image was showing, I could turn on blur, and switch between a number of virtual locations.

When push came to shove, reality had a breakdown.

Immediate danger? No.

Long term? Yes.

We see this in nature. When one species dominates too aggressively, it does not win — it destabilises the ecosystem. It consumes too much of the common resources, removes diversity and disables resilience, and inevitably it collapses.

This is not philosophy; it is biology.

What just happened?

My setup worked:

The browser followed the spec.
The camera delivered a stream.
The browser rendered it locally.

But somewhere in the black box, "Teams" decided I was not — part of the team — and immediately digitally marginalised and digitally erased me.

Not because I failed.

But because I was not conforming to an unwritten, proprietary expectation.

The Norwegian house implements Microsoft's vision.

NOT the standards and guidelines developed by the World Wide Web Consortium (W3C).

A quick search, and a visit to the Microsoft Teams device test, confirmed my suspicion: Firefox does not work.

When our government tools don't implement standards, they undermine independent evolution, interoperability and long-term digital content survival.

And by this we are endangering our democratic resilience.

Whether citizens can access public information should not depend on which proprietary technology they happen to use. As long as it adheres to standards.

Working with web development in my early years, I recall the effort we faced with users coming from the dominant platform, MS Windows, and its bundled Internet Explorer.

The problem

When government bodies use software that do not implement standards/standard formats.

The cure

DO NOT spend taxpayer money on solutions that force the public to use a set of vendors, adhere to standards (DIN EN ISO 216, DIN 5008, ISO 9001, ISO 14001, ISO/IEC 27001, ISO 45001, ISO 31000, ISO 8601, HTML/CSS, and WCAG 2.2.) they are there for our convinience and common good.

Markdown Stuff

Thu, 26 Mar 2026 00:00:00 +0000

In my effort to automate and assemble all my note-taking efforts over the years, I'm in the process of migrating to JBake as the new home.

No change without pain.

In my old Hakyll static compiler, I had invested a large amount of effort into special, nice adaptations. Now I pay the price.

Problems

[x] Tables don't render
[x] Code blocks are broken and don't work
[ ] d2lang preprocessing is broken. Probably move this to a separate pipeline and serve static content from there.
Now I have reconfigured the rendering engine to use (CommonMark)
Here is the spec: CommonMark Spec...
[ ] Find a linter to check all posts. I probably have to write this one.
[x] Code a translator for the remaining systems and their respective files. VIP.

Code block

This is a code block with annotation: bash


This is a code, that is
bash

This is a code block with NO annotation


This is a code block
!bash

Table

this	is	a	header
center	right	left	right
senter	høyre	venstre	høyre

Tegn

æ, ø, å
Æ, Ø, Å

Competitive Analysis: Guestimate vs. the Market

Thu, 12 Mar 2026 00:00:00 +0000

Competitive Analysis: Where Does Guestimate Fit?

The Market

The audience engagement and interactive quiz market is mature and well-funded. The dominant players are SaaS platforms built for education, corporate training, and event presentations. Interactive content sees 52.6% higher engagement than static content, with users spending 13 minutes on average vs. 8.5 minutes on static formats.

None of the major players focus on estimation as a game mechanic. This is our gap.

Competitor Overview

Product	HQ	Focus	Participants	Price (entry)	Price (1000 users)
Kahoot!	Oslo	Game-based learning	20–2000	$17/mo	~$75/mo (Pro)
Mentimeter	Stockholm	Interactive presentations	Varies	€13/mo	Enterprise tier
Slido	Bratislava (Cisco)	Polls & Q&A for meetings	100–5000	Free/3 polls	$200/mo (Enterprise)
AhaSlides	Singapore	Interactive quizzes	50+	$7.95/mo	Custom
Wooclap	Brussels	Audience response (education)	Unlimited	$3.99/mo	Custom
Guestimate	Norway	Estimation game for venues	40/game	Self-hosted	Self-hosted

Feature Comparison

What They All Do

Multiple choice / polling questions
Live leaderboards and results
QR code join flow
Mobile-first player experience
Analytics and reporting

What They Don't Do

Estimation-based gameplay — all competitors use discrete answer formats (multiple choice, ranking, matching). None use continuous numerical estimation with range inputs.
Venue-bound lobbies — competitors are session-based (presenter creates, shares code). None bind games to physical locations for recurring, unattended play.
Facilitator-free operation — all competitors require a presenter/host. Guestimate's common screen is the host. The system runs itself.
Dual-screen architecture — competitors show results on the presenter's shared screen. Guestimate has a dedicated common screen (TV/projector) separate from player phones, designed for public spaces.

Competitor Deep Dive

Kahoot! — The Market Leader

Strength: Brand recognition, 9+ billion cumulative participants, deep integrations (Teams, Zoom, LMS). ISO/SOC2/GDPR compliant.
Weakness: Requires a host. Quiz-only format (multiple choice). Pricing scales per host, not per participant. Not designed for unattended public spaces.
Pricing: $17–75/mo per host. One-time events from $250. Up to 2000 participants on Pro.
Relevance: Kahoot is the name people know. Any pitch must answer "why not just use Kahoot?"

Mentimeter — The Presentation Tool

Strength: 100M+ users, 220 countries. Strong in corporate meetings and conferences. Word clouds, scales, open-ended questions.
Weakness: Presentation-first, not game-first. No competitive scoring or leaderboard focus. Annual-only billing frustrates users. Free tier very limited.
Pricing: From €13/mo per presenter. Enterprise pricing unlisted.
Relevance: Mentimeter is about gathering opinions, not playing games. Different use case, but overlaps in "engagement at events."

Slido — Enterprise Polls (Cisco)

Strength: Cisco backing. Native integrations with Webex, Teams, PowerPoint. Strong moderation and Q&A features.
Weakness: Meeting-oriented. Quiz is a secondary feature. Free tier limited to 3 polls per event.
Pricing: Free to $200/mo. One-time events from $49.
Relevance: Enterprise buying power. If a corporate customer already uses Webex, Slido comes bundled.

AhaSlides — Budget Alternative

Strength: Cheapest entry point ($7.95/mo). Team play mode. Self-paced quizzes. Good for ice-breakers.
Weakness: Smaller market presence. Limited to standard quiz formats.
Pricing: Free (5 questions, 50 participants) to custom enterprise.
Relevance: Price competitor if we go SaaS. Shows the floor of what the market will pay.

Wooclap — Education Focus

Strength: 21 question types. Free for K-12. Strong in European education market.
Weakness: Education-first, weak in entertainment/venue use cases.
Pricing: $3.99–7.99/mo per teacher.
Relevance: Shows education is a viable vertical, but not our primary target.

Guestimate's Differentiators

1. Estimation as Game Mechanic

No competitor does this. Players submit numerical ranges, not multiple-choice answers. This creates a unique cognitive challenge: "How big is Norway?" requires genuine estimation, not recognition of a pre-written answer. The range-based scoring rewards both accuracy and confidence (narrow ranges score higher when correct).

2. Venue-Bound, Facilitator-Free

The system is designed for airports, pubs, and conference lobbies — places where a screen runs continuously without a human host. Players scan a QR code, play, and leave. The next game starts automatically. No competitor supports this model.

3. Location-Aware Content

Questions can be tagged to locations and audiences. A pub in Oslo gets Norwegian trivia. A tech conference gets industry estimation questions. This makes the content contextually relevant without manual curation per event.

4. Self-Hosted / On-Premise

Unlike all competitors (pure SaaS), Guestimate can run on-premise. For venues with privacy requirements or unreliable internet, this is a genuine advantage. It also means zero per-seat licensing — the venue pays once.

Competitive Positioning Matrix

                    Game-first ←————————————→ Tool-first
                         |                        |
   Unattended    Guestimate                       |
   (venue)             |                          |
        |              |                          |
        |         Kahoot!        AhaSlides        |
        |              |              |           |
   Hosted         _____|______________|___________|
   (presenter)         |              |           |
        |         Mentimeter    Wooclap     Slido |
        |              |              |           |

Pricing Implications

The market shows clear pricing bands:
- Budget: $4–8/mo (AhaSlides, Wooclap) — limited features
- Standard: $13–20/mo (Kahoot, Mentimeter) — per host
- Professional: $50–75/mo (Kahoot Pro, Slido Pro) — branding, analytics
- Enterprise: $200+/mo (Slido, Mentimeter) — SSO, support, scale

Guestimate's venue model doesn't fit per-host pricing. A per-venue monthly subscription or per-event flat fee would be more natural. Suggested tiers to explore:
- Free: 1 venue, default questions, 40 players
- Pro: Unlimited venues, custom questions, branding, analytics
- Enterprise: On-premise, API access, white-label

Key Takeaway

Guestimate is not competing with Kahoot on features. It competes on context: the unattended, location-bound, estimation-focused game that runs itself in public spaces. The answer to "why not Kahoot?" is: because Kahoot needs a host, and you need a screen that runs 24/7 in your lobby.

The go-to-market should target venue operators (pubs, airports, conference centres) who want ambient entertainment — not trainers or presenters who want a quiz tool.

Design: Scaling to 1000 Concurrent Users

Wed, 11 Mar 2026 00:00:00 +0000

Multi-Game Scalability: The Path to 1000 Concurrent Users

To achieve our goal of 1000 concurrent players in the game engine, we must transition from a single-instance architecture to a distributed, horizontally scalable system.

1. Architectural Shift: From Synchronized to Distributed

The current engine relies on Java-level synchronization and embedded persistence. In a multi-node setup, this causes state fragmentation.

Key Changes:

Centralized Persistence: Moving to a shared PostgreSQL or H2 Server instance.
Optimistic Concurrency: Implementing versioned updates in the Game domain object to prevent race conditions during concurrent answer submissions.
Event Orchestration: Introducing Redis as an event bus to synchronize SSE updates across all nodes.

2. Distributed SSE Event Flow

Players connected to Node A must see events triggered by players on Node B.

Trigger: An action occurs (e.g., participate() on Node A).
Publish: Node A publishes a PLAYER_JOINED event to the Redis channel game:<gameCode>.
Broadcast: All nodes (A, B, C...) subscribed to that channel receive the event.
Push: Each node pushes the event to its locally connected SSE clients.

3. Load Balancing & Reliability

Stickiness: Use Nginx ip_hash to keep game sessions localized where possible.
Re-hydration: Implement state recovery logic to allow the SMC state machine to resume from the database after a node restart.

4. Measuring Success

We will track our progress toward the 1000-user target using OTel-exported metrics in OpenObserve:
- active_games_total
- players_per_game_avg
- event_propagation_latency_ms

This design ensures that technical integrity remains high as we scale the product to its target audience.

Recognisable Play Specification

Wed, 11 Mar 2026 00:00:00 +0000

Recognisable Play

A lightweight competitive game designed for trust, tension, and conversation.

1. Core Intent

The game is designed to:
- Run fully unattended if needed
- Create shared tension before and during play
- Transition into a relaxed, social discussion after the game
- Be easy to join, hard to abuse, and safe to trust

The facilitator is optional. The system itself is the primary host.

2. The Recognisable Pattern (Brand Feature)

Every game follows the same emotional and temporal rhythm:

Invite – Common screen shows QR code, join URL, game code (AUTO_LOBBY)
Wait – 5-min lobby timer, +30s per new player when <30s remain
Commit – Timer expires or 40 players → game starts (COUNTDOWN)
Tension – Timed questions, visible response pressure (PLAYING → REVIEWING, repeats)
Release – Results, fun facts, discussion (RESULTS)
Reset – Brief pause, then new game auto-creates (COOLDOWN → AUTO_LOBBY)

This pattern never changes. The cycle repeats indefinitely.

Players learn to trust the rhythm.

This is a brand feature: when the counter appears, everyone knows what happens next.

3. UX Consistency Rules

One global countdown at a time
One authoritative screen state
Same transitions every game
No surprise pauses or hidden waits

Timers are sacred. If time runs out, the system acts.

4. Player Trust Model

Trust is built by:

Transparency
Scoring model is open
Statistics are shared
Privacy where it matters
Scores are private
Response-time pressure is public
Predictability
Same rules every game
Same timers, same outcomes

5. Identity & Sessions

Identity is session-based
Sticky via cookie/session storage
Email is optional
Email may be attached to session summary
Late joiners:
Attach to running game
Cannot score on completed questions

No permanent accounts required.

6. Automation First

There is no facilitator. The system is the host.

Root URL visit creates a new game automatically
Lobby timer starts on first player join (5 min)
Game auto-starts, auto-advances, auto-restarts
Player disconnects:
Auto-answer with defaults
After two auto-answers, stop waiting

The game never blocks indefinitely.

7. Competitive, but Feelgood

Game is individual & competitive
Goal is not winning — it is engagement and reflection
Time pressure prevents overthinking
Discussion after the game is part of the experience

Winning feels good.
Learning feels better.

8. Technical Design Guidelines

For developers:

Single authoritative game engine
Event-driven state transitions
Idempotent joins
Deterministic timers
Explicit game phases (state machine):
AUTO_LOBBY → COUNTDOWN → PLAYING → REVIEWING → RESULTS → COOLDOWN → AUTO_LOBBY
FINISHED (terminal, via Halt only)

No hidden states.

9. Non-goals

No long-term player ranking
No monetisation hooks
No dark patterns
No artificial delays

10. Summary

This game is not about complexity.

It is about:
- Rhythm
- Trust
- Tension
- Release

Recognisable Play is the product.

The Finished Phase: Credits-Style Results Without Data Exposure

Wed, 11 Mar 2026 00:00:00 +0000

FINISHED Phase — Functional Specification

1. Purpose of FINISHED

The FINISHED phase exists to:

Provide closure to the game session
Present final results in a shared, passive format
Highlight collective and individual achievements without exposing personal data
Define clear conditions for session termination

The FINISHED phase is read-only, non-interactive, and time-bounded.

2. Scope & Non-Goals

In scope

Common-screen presentation (credits-style)
Final player ordering and display
Presentation of derived statistical facts
Session termination handling

Explicitly out of scope

Score calculation or modification
Player interaction beyond session exit
New game initialization
Personal or identifying data exposure

3. Core Concepts (Mental Model)

Final Credits Sequence (FCS)

The FINISHED phase is represented as a Final Credits Sequence, similar to movie credits:

Automatically scrolling
Same content and order for all players
Passive observation only

The sequence may loop until the session terminates.

4. Data Responsibilities

4.1 Final Player Results (Immutable)

Each player has:

Final score
Rank
Accuracy metrics
Timing metrics (aggregated)

Rules:

Data is finalized before entering FINISHED
No values may change during FINISHED
No new data may be added

4.2 Derived Statistics Dataset

Derived from game-wide data:

Answer correctness
Answer timing
Answer deltas (distance from correct answer)
Consistency metrics

This dataset is input to the FINISHED statistics projection.

5. Statistics & Fact Projection (FINISHED)

Purpose

To generate highlight-style statistical facts that summarize notable outcomes of the game.

Characteristics

Deterministic given the same input
Non-personal
Explainable
Generated once and frozen

Example Fact Categories

Winner (highest score)
Fastest to answer
Slowest to answer
Most correct answers
Smallest average delta
Most consistent answers
Largest improvement over time

6. Presentation Rules

Ordering

Winner always displayed at the top
Remaining players ordered by descending score
Ties resolved deterministically
Ordering must be stable across all clients

Display

Credits-style vertical scroll
Shared pacing across all clients
No user-controlled navigation
Optional looping until session termination

7. FINISHED Flow Control

Entry Conditions

REVIEWING phase has completed
All question reviews are finalized
Final scores and statistics are available

Session Termination Conditions

The FINISHED phase ends when any of the following occurs:

A player console stops pinging the server beyond a defined timeout
A player explicitly selects “Join New Game”
A server-defined idle timeout is reached

Exit Behavior

Session is marked as terminated
No further events are accepted
Resources may be released
FINISHED data becomes archival

8. State Transitions

REVIEWING → FINISHED

Occurs when:

Final question review completes
REVIEWING exit criteria are met

FINISHED → SESSION_TERMINATED

Occurs when:

Any termination condition is triggered

9. Invariants (Must Always Hold)

No score changes during FINISHED
No personal or identifying data is displayed
All players see the same credits sequence
Facts do not change once generated
FINISHED contains no interactive gameplay elements

10. Test Strategy

10.1 Static Validation Tests

Final results exist for all players
All statistics are computable
Fact projection produces valid output

10.2 Presentation Tests

Correct ordering of players
Winner always displayed first
Stable ordering across clients
Scroll behavior matches specification

10.3 Statistics Tests

Each fact is derivable from stored data
No fact references raw or personal data
Facts remain constant during FINISHED

10.4 Termination Tests

Session ends on ping timeout
Session ends on join-new-game event
Session ends on idle timeout
No events accepted after termination

11. Acceptance Criteria

A player can:

Clearly see who won
Understand how players performed collectively
Observe interesting outcomes of the game
Exit the session naturally

Without:

Being able to infer personal or sensitive information
Affecting game state

Scale-Estimation Slider: Player GUI Design

Wed, 11 Mar 2026 00:00:00 +0000

1. Concept: Scale-Only Estimation Input

The game is about estimating scale, not selecting correct answers.
Users should express order of magnitude first, then optionally refine their estimate.

There are no discrete choices and no predefined steps.
Input is continuous and relative.

2. Primary Input: Horizontal Scale Slider

Base Interaction

A horizontal slider represents a logarithmic scale
Left = very small
Right = very large
The exact numeric value is hidden initially
Only the unit is shown (e.g. kg, liters, km)

|-----------------------------|
 small                     large

The slider is designed for coarse estimation, not precision.

3. Progressive Precision via Vertical Gesture

Refinement Gesture

While touching the slider:
Horizontal movement → changes magnitude
Vertical movement (upwards) → increases precision
Vertical movement (downwards) → decreases precision

This allows coarse → fine adjustment in a single continuous gesture.

Precision Levels

Vertical Distance	Precision Mode	Behavior
Near slider	Coarse	Log scale, large jumps
Medium height	Fine	Linear interpolation
High above	Precision	Decimal precision (max 2 decimals)

Rule:

Precision is capped at two decimal places.
This prevents false accuracy.

4. Scale Behavior (Important for Developers)

Scale Type

Default: logarithmic scale
Purpose: enable navigation from e.g. 1 → 1,000,000,000 in one motion
When precision increases:
The scale locally transitions to linear
Only within the current magnitude window

This avoids:

tiny finger movements jumping billions
meaningless exactness at global scale

5. Visual Feedback

While Sliding

Show:
Approximate value
Unit
Optional scientific notation at coarse level

Examples:

≈ 10⁶ kg
≈ 1 million kg
≈ 1.23 million kg

Formatting adapts to precision level automatically.

6. Input Rules (Explicit Constraints)

No keyboard input
No direct number entry
No snapping to predefined values
No minimum / maximum shown numerically
All values are soft-bounded
User can overshoot “reasonable” ranges
Game logic evaluates plausibility, not validity

7. Completion Interaction

User releases finger → value is locked
A short confirmation animation reinforces:

> “This is your estimate”

Only after submission:

The real value is revealed
Comparison is shown visually (not numerically first)

8. Example Developer-Facing Spec (Condensed)

InputComponent: ScaleSlider

- Axis: Horizontal (logarithmic)
- Gesture:
  - X-axis: magnitude selection
  - Y-axis: precision modulation
- Precision:
  - Dynamic
  - Max 2 decimal places
- Units:
  - Always visible
- Values:
  - Continuous
  - No discrete steps
- Purpose:
  - Express scale intuition, not exact knowledge

9. Design Philosophy (One-liner)

“The user should feel like they are feeling out the size of the world, not entering a number.”

Import Data Structure

Wed, 11 Mar 2026 00:00:00 +0000

Import data structure

{
  "id": "UUID",
  "questionText": "String",
  "isoUnit": "String",
  "defaultMin": "int",
  "defaultMax": "int",
  "correctValue": "int",
  "fasitSource": "String (validated URL)",
  "fasitCheckedAt": "YYYY-MM-DD",
  "illustrationUrl": "String (PNG URL)"
}

Sample data

[
  {
    "id": "6c9f1f0e-1b2d-4a73-bb3a-001001001002",
    "questionText": "How long is the border between Norway and Russia?",
    "isoUnit": "km",
    "defaultMin": 100,
    "defaultMax": 300,
    "correctValue": 196,
    "fasitSource": "https://en.wikipedia.org/wiki/Norway%E2%80%93Russia_border",
    "fasitCheckedAt": "2024-10-01",
    "illustrationUrl": "https://via.placeholder.com/512x512.png?text=How%20long%20is%20the%20border%20between%20Norway%20and%20Russia%3F"
  },
  {
    "id": "6c9f1f0e-1b2d-4a73-bb3a-001001001006",
    "questionText": "How many U.S. presidents served before Ronald Reagan?",
    "isoUnit": "presidents",
    "defaultMin": 20,
    "defaultMax": 50,
    "correctValue": 39,
    "fasitSource": "https://en.wikipedia.org/wiki/List_of_presidents_of_the_United_States",
    "fasitCheckedAt": "2024-10-01",
    "illustrationUrl": "https://via.placeholder.com/512x512.png?text=How%20many%20U.S.%20presidents%20served%20before%20Ronald%20Reagan%3F"
  }
]

Public Common Screen Flow

Wed, 11 Mar 2026 00:00:00 +0000

Public Common Screen Flow

Replaces the facilitator-driven game start. The common screen IS the game host.

Overview

When a user points their browser at the root URL, a new game session is created automatically. The common screen displays a QR code and join URL. Players scan the code, enter their name, and join the lobby. The game starts automatically based on timer rules — no facilitator needed.

After a game finishes, results are shown for a period, then a new lobby auto-creates.

State Machine (Updated)

AUTO_LOBBY → COUNTDOWN → PLAYING → REVIEWING → RESULTS → COOLDOWN → AUTO_LOBBY
                 ↑                      │
                 └── (next question) ───┘

CREATED and LOBBY are merged into AUTO_LOBBY — the system creates and opens the lobby in one step.

FINISHED is replaced by COOLDOWN — results display for a set period, then the cycle restarts.

Auto-Lobby Creation

Trigger: GET / (root URL)

System behaviour:
1. Select a random question set from the available pool
2. Create a new game with default config (10 questions, 60s per question)
3. Generate human-readable game code (e.g., "Blue-Dancing-Horse")
4. Display common screen with:
- QR code encoding the player join URL
- Human-readable game code
- Join URL as text
- Lobby countdown timer (starts at 5:00 when first player joins)
- Player list (updates as players join via SSE)

Lobby Timer Rules

The lobby timer governs when the game auto-starts. Three conditions, whichever comes first:

Condition 1: Timeout with no new players

Timer starts at 5:00 (5 minutes) when the first player joins
Timer counts down visibly on the common screen
If timer reaches 0:00 and at least 1 player has joined → game starts

Condition 2: Rolling extension for new players

Each new player joining resets the timer to 0:30 if less than 30 seconds remain
This allows latecomers to extend the lobby window
The extension only applies when the timer is below 30 seconds
Example sequence:
Timer at 0:22 → new player joins → timer resets to 0:30
Timer at 0:15 → new player joins → timer resets to 0:30
Timer at 1:45 → new player joins → timer stays at 1:45 (above 30s, no extension)

Condition 3: Max players reached

When 40 players have joined → game starts immediately
No waiting for the timer

Minimum players

1 player minimum required to start
If timer expires with 0 players, timer resets and waits for the first player

Player Join Flow (Unchanged core, simplified entry)

Player scans QR code on common screen
Lands on /play/{code} — join page
Enters player name (email remains optional)
POST /play/{code}/join registers player
Player sees "Get Ready" screen with lobby countdown
SSE keeps player updated on lobby state and game start

Auto-Progression Through Questions

With no facilitator, the game must auto-advance:

COUNTDOWN (5 seconds) → PLAYING
PLAYING → question timer runs (e.g., 60 seconds)
When timer expires OR all players have answered → REVIEWING
REVIEWING lasts a fixed duration (e.g., 10 seconds) → auto-advance
If more questions remain → back to COUNTDOWN
If no more questions → RESULTS

Results and Restart Cycle

RESULTS displayed for a fixed period (e.g., 60 seconds)

Rankings, winner highlight, stats
Rolling credits animation

COOLDOWN → brief pause (e.g., 10 seconds)
AUTO_LOBBY → new game session auto-created with a new random question set
Cycle repeats indefinitely

The common screen never goes blank or requires manual intervention.

API Changes Required

Removed endpoints (facilitator)

~~POST /api/games~~ — replaced by auto-creation on root URL visit
~~PUT /api/games/{code}/config~~ — defaults are used
~~POST /api/games/{code}/start~~ — auto-start replaces manual start
~~POST /api/games/{code}/next~~ — auto-advance replaces manual next
~~POST /api/games/{code}/halt~~ — no emergency stop needed without facilitator
~~POST /api/games/{code}/end~~ — auto-transition to cooldown

New/modified endpoints

GET / — creates auto-lobby, returns common screen
GET /api/games/{code}/lobby-timer — returns remaining lobby time and player count
SSE events should include lobby-timer updates when players join (timer extension)

Kept endpoints (player + common screen)

POST /api/games/{code}/players — join game (only during AUTO_LOBBY)
GET /api/games/{code}/questions/current — get current question
POST /api/games/{code}/questions/{index}/answers — submit answer
GET /api/games/{code}/results — get final results
GET /api/games/{code}/state — common screen state
All SSE endpoints

Web Routes (Updated)

Route	Purpose
GET `/`	Auto-create lobby, render common screen
GET `/screen/{code}`	Common screen for a specific game
SSE `/screen/{code}/events`	Real-time common screen updates
GET `/play/{code}`	Player join page
POST `/play/{code}/join`	Register player
POST `/play/{code}/answer`	Submit answer
SSE `/play/{code}/events`	Real-time player updates

The /facilitator routes are removed.

Common Screen Display States

AUTO_LOBBY (waiting for players)

Large QR code (center)
Join URL and game code (below QR)
Lobby countdown timer (prominent, top)
Player list (scrolling, updates live via SSE)
"Scan to join!" call to action

COUNTDOWN (between questions)

Question number indicator ("Question 3 of 10")
Countdown animation (5, 4, 3, 2, 1)

PLAYING (question active)

Question text at top (readable from distance)
Question illustration mid-right
Timer countdown mid-left
Players joined / answers received counter

REVIEWING (after question)

Correct answer revealed
Stats: first to answer, best delta, median delta
Auto-advances after fixed duration

RESULTS (game over)

Ranked leaderboard
Winner highlight
Response time stats
"Next game starting in..." countdown

Configuration Defaults

Parameter	Default	Notes
Lobby timeout	300s (5 min)	From first player join
Lobby extension	30s	Added when player joins with <30s remaining
Max players	40	Immediate start when reached
Min players	1	Must have at least 1 to start
Questions per game	10	From question set
Question time limit	60s	Per question
Countdown between questions	5s	Before each question
Review duration	10s	Auto-advance after review
Results display	60s	Before auto-restart
Cooldown	10s	Between results and new lobby
Question set selection	Random	Rotate through available sets

The Reviewing Phase: Aggregate Feedback Without Attribution

Wed, 11 Mar 2026 00:00:00 +0000

REVIEWING Phase — Functional Specification

1. Purpose of REVIEWING

The REVIEWING phase exists to:

Replay each question
Show objective outcomes (correct answer, distributions)
Provide non-personal statistical insight
Progress collectively, not individually

It is read-only, time-independent, and player-synchronized.

2. Scope & Non-Goals

In scope

Cycling through questions
Displaying:
Original question
Correct answer
Aggregated statistics
Derived “interesting facts”
Coordinated “Next” progression
Persisting player scores

Explicitly out of scope

Player identity disclosure
Individual answer attribution
Real-time answering
Score changes

3. Core Concepts (Mental Model)

Question Review Unit (QRU)

Each question produces one immutable review unit containing:

Question text
Correct answer
Aggregated answers
Derived statistics
Derived facts

QRUs are processed sequentially.

4. Data Responsibilities

4.1 Player Scores (Persistent)

Must be stored before REVIEWING starts.

Each player has:

Final score
Optional accuracy metrics (e.g. % correct)

Rules:

Scores are immutable during REVIEWING
Scores may be displayed globally or privately

4.2 Question Result Dataset (Per Question)

For each question:

Question text
Correct answer
All submitted answers (anonymous)
Count of players who answered
Distribution data (bins / groups)

This dataset is input to statistics & facts engines.

5. Statistics Engine (Deterministic)

Purpose

Transform raw answer data into neutral, aggregated metrics.

Required Outputs (minimum)

% correct
Answer distribution (e.g. histogram)
Mean / median / spread (where applicable)
Outlier detection (statistical, not personal)

Rules:

No player identifiers
Same input → same output
Must complete before facts generation

6. Random Fact Engine (Controlled Randomness)

Purpose

Generate 1–X interesting, non-personal facts per question.

Inputs

Question Result Dataset
Statistics Engine output
Random seed (session-scoped)

Output Characteristics

True
Non-identifying
Derived from group behavior
Explainable

Example Fact Types:

“Most players underestimated the answer”
“This question had the widest spread of answers”
“Accuracy improved compared to the previous question”

Rules:

Facts are derived, never raw
No mention of individuals
Upper bound X is fixed per session
Facts are generated once, then frozen

7. REVIEWING Flow Control

State Variables

currentQuestionIndex
playersReadyCount
totalPlayers
advanceThreshold (e.g. 60%)

Next Event Aggregation

Player Action:

Player presses Next

System Behavior:

Record readiness (idempotent)
Aggregate count
Compute readiness ratio

Transition Rule:
When
playersReadyCount / totalPlayers ≥ advanceThreshold

Then:

Advance to next question
Reset readiness
Broadcast transition

Safeguards:

A player pressing Next multiple times counts once
Late joiners do not affect threshold
Disconnects freeze their last state

8. State Transitions

REVIEWING → REVIEWING

Occurs when:

Threshold reached
More questions remain

REVIEWING → FINISHED

Occurs when:

Last question review completes
Threshold reached

9. Invariants (Must Always Hold)

No score changes during REVIEWING
No personal data exposed
All players see the same question at the same time
Facts do not change once generated
Advancement is collective, not individual

10. Test Strategy

10.1 Static Validation Tests

Every question has:
Correct answer
Answer dataset
Statistics engine produces output for all question types
Fact engine produces ≤ X facts

10.2 Statistics Engine Tests

Same dataset → same statistics
Percentages sum correctly
No division by zero
Works with:
All correct
All incorrect
Single-player edge case

10.3 Fact Engine Tests

No fact references individuals
No raw answers leaked
Same seed → same facts
Different seed → different selection, same truth
Produces 0 facts if dataset too small
Never exceeds X

10.4 REVIEWING Flow Tests

Advance only after threshold
Advance exactly once per question
Multiple Next presses don’t skew count
All players see same index

10.5 Failure & Edge Tests

Player disconnects mid-review
Player reconnects
Threshold exactly met
Threshold exceeded
Only one player

11. Acceptance Criterion

A player can understand:

what the correct answer was,
how people answered in general,
something interesting about the group,

without learning anything personal.

If yes, REVIEWING works.

JSON API Details

Wed, 11 Mar 2026 00:00:00 +0000

Game HTTP API — JSON Payload Details

API to start a game and retrieve {key}-json-game-data-file.json

QuestionSet Example

{
  "code": "Blue-Dancing-Horse",
  "startTime": null,
  "questions": [
    {
      "questionIndex": 1,
      "illustrationUrl": "https://url/media-hash",
      "questionText": "What is the wingspan of a Norwegian Boeing 747 in {$1}",
      "isoUnit": "m",
      "defaultMax": null,
      "defaultMin": -100,
      "correctValue": null,
      "questionTimeLimitSec": 60
    },
    {
      "questionIndex": 2,
      "illustrationUrl": "https://url/media-hash",
      "questionText": "Number of McDonald's Double Cheese meals served each day in {$1}",
      "isoUnit": "units",
      "defaultMax": null,
      "defaultMin": -100,
      "correctValue": null,
      "questionTimeLimitSec": 60
    },
    {
      "questionIndex": 3,
      "illustrationUrl": "https://url/media-hash",
      "questionText": "Height of Seip Mountain in {$1}",
      "isoUnit": "m",
      "defaultMax": null,
      "defaultMin": -100,
      "correctValue": null,
      "questionTimeLimitSec": 60
    }
  ]
}

Answer Example

{
  "questionId": 1,
  "playerId": "p-2",
  "userMin": 55,
  "userMax": 72,
  "submittedAt": 1700000042000
}

ScoreResult Example

{
  "rankings": [
    { "rank": 1, "playerId": "p-3", "name": "Carol" },
    { "rank": 2, "playerId": "p-2", "name": "Bob" }
  ],
  "fastestAvgResponseMs": { "playerId": "p-3", "name": "Carol", "avgMs": 8200 },
  "slowestAvgResponseMs": { "playerId": "p-2", "name": "Bob", "avgMs": 14500 }
}

Estimation Feedback Loop

Wed, 11 Mar 2026 00:00:00 +0000

Project Planning in the Age of AI: What Can History Teach Us?

Working notes toward a longer discussion. This is a living document.

The Estimation Problem

Every project begins with a guess. We call it an "estimate" to give it dignity, but Daniel Kahneman would call it what it is: a prediction made under uncertainty, distorted by cognitive biases we cannot feel operating.

In Thinking, Fast and Slow, Kahneman describes the planning fallacy — our systematic tendency to underestimate the time, cost, and risk of future actions while overestimating their benefits. This isn't a character flaw. It's how human cognition works. System 1 (fast, intuitive) generates an optimistic anchor. System 2 (slow, analytical) is too lazy to adjust it far enough.

The result is predictable: projects run late. Not randomly late — systematically late, in the same direction, by roughly the same factor.

The question is: can we do better? And specifically — can AI agents, with access to structured memory and historical data, break the cycle?

What Precision Demands

Simon Winchester's The Perfectionists traces the history of precision engineering — from John Wilkinson's cannon borer to the nanometer tolerances of modern semiconductors. A recurring theme: precision improves only when you measure the gap between intention and outcome, then feed that measurement back into the process.

Wilkinson didn't bore better cylinders by trying harder. He bore better cylinders by measuring the deviation of each one and adjusting the machine. The feedback loop is the precision.

Software estimation has no such loop. We estimate, we execute, we ship (or slip), and then we estimate the next thing as if the last one never happened. The data exists — in our git logs, our issue trackers, our CI pipelines — but we never close the circle.

The KT Framework Applied to Estimation

Kepner and Tregoe gave us a framework for structured thinking: Situation Appraisal, Problem Analysis, Decision Analysis, and Potential Problem Analysis. Their insight was that most failures come not from lack of intelligence but from lack of structured process — people jump to solutions before understanding the situation.

Applied to estimation, the KT framework asks:

Situation Appraisal: What do we actually know? What data do we have from previous similar tasks? What is the scope of our uncertainty?

Problem Analysis: When our estimates were wrong, why were they wrong? Was the task more complex than anticipated? Did we underestimate integration effort? Did rework from failures consume the buffer?

Decision Analysis: Given what we know about our historical accuracy, which estimation method gives us the best prediction? Raw intuition? Three-point estimates? Reference class forecasting? Monte Carlo simulation?

Potential Problem Analysis: What could make this estimate wrong? What would we do if it is? Where are the risks concentrated?

Most teams skip straight to "how long will this take?" and answer from intuition. KT says: slow down. Examine the situation. Look at the data.

The Data We Already Have

Consider what a modern development environment produces automatically:

Source	Signal
Git commit history	When work actually started and ended
Issue tracker (open → close)	Elapsed calendar time per task
CI pipeline history	Build time, failure rate, rework cycles
DORA metrics	Deployment frequency, lead time, change failure rate, recovery time
Agent memory (Neo4j)	What was known, what was decided, what was learned

We measured our own DORA metrics today. Deployment frequency: elite. Lead time: elite. MTTR: elite. Change failure rate: 68% — low performer.

That 68% is not just a quality metric. It's an estimation input. If two-thirds of deployments fail and require a fix-forward cycle, then every task estimate needs a rework multiplier. Ignoring this is like Wilkinson ignoring that his bore drifts left — the error is systematic and correctable, if you measure it.

Reference Class Forecasting

Kahneman and Tversky proposed reference class forecasting as the antidote to the planning fallacy. Instead of asking "how long will this task take?", ask: "how long did similar tasks take?"

The method:

Identify a reference class of comparable past tasks
Obtain the statistical distribution of outcomes in that class
Use that distribution as the baseline prediction
Adjust only for specific, articulable differences

This is powerful because it bypasses the inside view (our optimistic story about this particular task) and forces us to confront the outside view (what actually happened last time, and the time before that).

For software teams, the reference class is rich:

"Refactoring" tasks: how long did previous refactors actually take vs. estimate?
"Bug fixes" after failed deployments: what's the average rework time?
Tasks assigned to a specific agent: what's their personal estimation bias?

Three-Point Estimates and Monte Carlo — Necessary but Not Sufficient

Our scheduling tool, tj, already supports three-point estimates (optimistic, most likely, pessimistic) and runs Monte Carlo simulations using PERT-Beta distributions. This gives us P50, P80, and P95 confidence intervals.

But three-point estimates have a hidden assumption: that the estimator is well-calibrated. If your "pessimistic" estimate is actually your "most likely" outcome (a common pattern), then even 10,000 Monte Carlo simulations will produce confidently wrong predictions.

The simulation is only as good as the distribution it samples from.

Closing the Loop: Calibrated Estimation

What we need is a feedback mechanism with three components:

A. Retrospective Comparison

After a task completes, compare estimate to actual:

tasks:
  - id: implement-sse
    effort: { optimistic: 2d, likely: 4d, pessimistic: 8d }
    actual: 6d

From many such comparisons, compute:
- Bias factor per resource: mean(actual / likely) — are they consistently 1.3x or 0.8x?
- Spread accuracy: do 80% of actuals fall within the estimated P20–P80 range?
- Task-type patterns: refactors take 2x, bugfixes take 0.5x of estimated effort

B. Calibrated Distributions

Feed the bias factors back into future estimates. If an agent historically underestimates by 1.4x, shift their PERT distribution rightward before running Monte Carlo. The math is straightforward:

calibrated_likely = raw_likely * bias_factor
calibrated_pessimistic = raw_pessimistic * spread_factor

The result: Monte Carlo predictions that reflect demonstrated accuracy, not assumed accuracy.

C. Automatic Data Collection

The richest approach: don't ask humans (or agents) to self-report actuals. Import them from the system of record.

Git: first commit on branch → merge to main = working time
Gitea: issue opened → issue closed = calendar time
Woodpecker: pipeline count per issue = rework cycles

This removes the burden of manual retrospectives and ensures the data is honest.

The Agent Memory Connection

Here is where AI agents change the game. A human developer forgets their estimation patterns. They don't track that they underestimate "refactoring" tasks by 40% and overestimate "adding tests" by 20%. The bias operates invisibly.

An AI agent with structured memory can:

Remember the estimate it gave for each task
Record the actual outcome when the task completes
Compute its own calibration factors — per task type, per project, per complexity level
Apply those factors automatically to future estimates

The agent doesn't need to be told it has a bias. It can discover the bias from data, and correct for it. This is reference class forecasting, automated.

Our shared memory graph (Neo4j) already stores project context, decisions, and agent knowledge. Extending it to store estimation-vs-actual pairs is a natural step. The calibration factors become part of the agent's evolving knowledge — improving with every completed task.

The Vision: Task, History, Knowledge

The connection we're building toward:

New Task → "Have we done this before?"
              ↓
        Reference class lookup in memory
              ↓
        Historical bias factors applied
              ↓
   Agent's calibrated three-point estimate
              ↓
        Monte Carlo simulation (tj)
              ↓
      P50 / P80 / P95 with earned confidence
              ↓
            Execute
              ↓
        Record actual outcome
              ↓
      Update memory → improve next estimate

Each task feeds forward into better predictions for the next one. The agent's knowledge compounds. The estimates get more honest — not because the agent tries harder, but because the feedback loop enforces it mechanically.

This is Winchester's lesson from precision engineering: you don't improve by wanting to be more accurate. You improve by measuring the error and correcting for it, systematically, every time.

What This Means for Project Planning

Traditional project planning tools (MS Project, Jira, etc.) treat estimates as inputs and schedules as outputs. They never question whether the inputs are any good.

A calibration-aware planning tool inverts this: past outcomes are inputs, and the schedule reflects demonstrated capability rather than hopeful prediction.

For a small team with AI agents, this means:
- The planning tool gets smarter with every sprint
- Estimates are grounded in evidence, not anchoring bias
- Confidence intervals actually mean what they claim (P80 = 80%)
- The team can trust its own predictions — and stakeholders can too

Open Questions

How many data points are needed before calibration factors are reliable? (Likely 10-15 per reference class, per standard statistical guidance.)
Should calibration be per-agent, per-task-type, or both? (Both — with fallback to global when data is sparse.)
How do we handle tasks that have no historical reference class? (Fall back to uncalibrated estimates with wider uncertainty bands, and flag them explicitly.)
Can we detect when a team's capability has changed (new tools, new architecture) and reset calibration? (Track calibration drift over time — a sudden improvement in bias factor signals a capability shift.)

References

Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux. — Planning fallacy, reference class forecasting, System 1/System 2, anchoring bias.
Kahneman, D. & Tversky, A. (1979). "Intuitive Prediction: Biases and Corrective Procedures." TIMS Studies in Management Science, 12. — The original reference class forecasting paper.
Winchester, S. (2018). The Perfectionists: How Precision Engineers Created the Modern World. HarperCollins. — Feedback loops as the mechanism of precision improvement.
Kepner, C.H. & Tregoe, B.B. (1981). The New Rational Manager. Princeton Research Press. — Structured analysis: situation appraisal, problem analysis, decision analysis, potential problem analysis.
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. — DORA metrics, capabilities of high-performing organizations, data-driven improvement.
McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Microsoft Press. — Cone of uncertainty, estimation techniques, calibration through historical data.
Flyvbjerg, B. (2006). "From Nobel Prize to Project Management: Getting Risks Right." Project Management Journal, 37(3). — Applying reference class forecasting to large-scale projects.
DORA Team / Google Cloud. (2024). Accelerate State of DevOps Report 2024. — Current benchmarks for elite/high/medium/low software delivery performance.

REST API Specification

Wed, 11 Mar 2026 00:00:00 +0000

REST API Specification

Base path: /api

All request and response bodies are application/json.

Error Format

{
  "error": "GAME_NOT_FOUND",
  "message": "No game with code 'Blue-Dancing-Horse' exists."
}

Code	HTTP	Meaning
GAME_NOT_FOUND	404	Game code does not exist
GAME_FULL	409	Max players (40) reached
PLAYER_NOT_FOUND	404	Player not in this game
QUESTION_TIMEOUT	410	Answer after time limit
VALIDATION_ERROR	400	Missing or invalid fields

Player Input

POST /api/games/{code}/players — join

Request:

{
  "name": "Bob"
}

Response 201 Created:

{
  "playerId": "p-2",
  "name": "Bob",
  "gameCode": "Blue-Dancing-Horse",
  "state": "AUTO_LOBBY"
}

POST /api/games/{code}/questions/{index}/answers — answer

Submit min/max answer for current question. Only in PLAYING state.

Request:

{
  "playerId": "p-2",
  "userMin": 380,
  "userMax": 450
}

Response 201 Created:

{
  "questionIndex": 3,
  "playerId": "p-2",
  "delta": 70,
  "submittedAt": 1700000042000
}

GET /api/games/{code}/questions/current — getQuestion

Get the current question. Only in PLAYING state.

Response 200 OK:

{
  "questionIndex": 3,
  "questionText": "How tall is the Empire State Building?",
  "isoUnit": "m",
  "defaultMin": 0,
  "defaultMax": 1000,
  "illustrationUrl": "https://media.example.com/media-hash",
  "timeRemainingMs": 42000
}

POST /api/games/{code}/next — signalNext

Signal readiness to advance to the next question or phase. Used in REVIEWING state.

Request:

{
  "playerId": "p-2"
}

Response 200 OK:

{
  "status": "OK"
}

GET /api/games/{code}/results — getResults

Final results. Available in RESULTS, FINISHED, COOLDOWN.

Response 200 OK:

{
  "code": "Blue-Dancing-Horse",
  "state": "RESULTS",
  "rankings": [
    { "rank": 1, "playerId": "p-3", "name": "Carol" },
    { "rank": 2, "playerId": "p-2", "name": "Bob" }
  ],
  "fastestAvgResponseMs": { "playerId": "p-3", "name": "Carol", "avgMs": 8200 },
  "slowestAvgResponseMs": { "playerId": "p-2", "name": "Bob", "avgMs": 14500 },
  "achievements": [
    { "title": "The Sniper", "name": "Carol", "detail": "Smallest total range for correct answers." },
    { "title": "The Rock", "name": "Bob", "detail": "Most consistent estimation ranges." }
  ]
}

Common Screen — Game State

GET /api/games/{code}/state — getGameState

Current game state for the common screen display.

Response 200 OK:

{
  "code": "Blue-Dancing-Horse",
  "state": "PLAYING",
  "currentQuestionIndex": 3,
  "numberOfQuestions": 10,
  "playersJoined": 12,
  "answersReceived": 8,
  "timeRemainingMs": 42000,
  "question": {
    "questionText": "How tall is the Empire State Building?",
    "isoUnit": "m",
    "illustrationUrl": "https://media.example.com/media-hash"
  }
}

During AUTO_LOBBY, includes lobby timer:

{
  "state": "AUTO_LOBBY",
  "lobbyTimeRemainingMs": 245000,
  "playersJoined": 5
}

During REVIEWING:

{
  "state": "REVIEWING",
  "playersReady": 7,
  "review": {
    "correctValue": 443,
    "stats": {
      "percentCorrect": 66.7,
      "mean": 450.5,
      "median": 445.0,
      "spread": 120.0
    },
    "facts": [
      { "text": "The group has excellent knowledge about this!" },
      { "text": "We had some wild outliers this round!" }
    ]
  }
}

During FINISHED:

{
  "state": "FINISHED",
  "timeRemainingMs": 25000,
  "results": { ... }
}

Gui

Wed, 11 Mar 2026 00:00:00 +0000

GUI

Create for presentation-mode "Horizontal" layout. Think Apple Keynote, and Norman Nielsen Group on usability and design principles. Don't make me think!

Generic: two screen types are connected by a common backend, that represents one game. The common screen auto-creates a new game when the root URL is visited.

Users in general

The user is a commoner from the street, with no previous experience with this game.

Screens in general

Horizontal view TV, presentation.
player-screen is meant to be on a mobile (touch-screen)
common-screen is meant to be on a TV/Projector/theatre-screen
The game is a presentation, but interactive.
Error screen (if something happens, that can get you back to start)
No facilitator screen — the system is the host.

Player-screens

Skills: Generic person from the street
Affordance: Enable the user to participate in the game.

Screenflow

Scan QR code on common screen
Splashscreen - register (enter name)
Waiting screen - show users that register, lobby countdown timer
Sample question - screen (how to play)
The rules (how to score points)
Countdown to first question
Repeat questions until end
Wait for final participant's answer
For all questions: display answer on common-screen, show your answers on player-screen.
Late joiners: can enter during COUNTDOWN, PLAYING, or REVIEWING — cannot score on missed questions.

Enter max min values

A key portion of the game is to enter values relatively fast. Number input must be easy and efficient. How do we test that?

Let the player-screen reflect common-screen. If you move your eyes, elements should be at the same location.

Common-screen

Skills: Person in a public house, Conference, Internet

The common screen is the game host. Visiting the root URL (/) auto-creates a new game session.

Display per state

State	Display
AUTO_LOBBY	QR code, join URL, game code, lobby countdown timer (5 min), player list (live via SSE)
COUNTDOWN	"Question N of M", countdown animation (5, 4, 3, 2, 1)
PLAYING	Question text at top, illustration mid-right, timer + answer count mid-left
REVIEWING	Correct answer, winner delta, median delta, first-to-answer
RESULTS	Ranked leaderboard, winner highlight, response time stats
COOLDOWN	"Next game starting in..." countdown

Question on top - so it can be read over the head of the person in front of you.
Question-illustration/image at the mid/lower - right
Game information at the mid/lower left
Countdown to next question
Number of players/answers

Error States

All screens should handle the following error conditions gracefully:

Error	Shown on	Behaviour
Connection lost	All screens	Show reconnecting indicator. Retry automatically. After timeout, offer "Return to start".
Game not found	Player-screen, Common-screen	"Game does not exist. Check the code and try again." with input to re-enter code.
Game full	Player-screen	"This game is full (40 players). Wait for the next game."
Session expired	All screens	"Your session has expired." with option to rejoin (player).

Data Catalogue

Wed, 11 Mar 2026 00:00:00 +0000

Domain Data Catalogue

This catalogue documents all domain data types used in the game.
It serves as the authoritative reference for domain concepts, their constraints,
and their GDPR classification.

Governed by the "Use Domain-Specific Data Types" ADR (linked from the project KB).

Identity Types

Domain Type	Underlying	Constraints	Example
`GameId`	UUID	Non-null, immutable	`6c9f1f0e-...`
`PlayerId`	UUID	Non-null, immutable	`a3b2c1d0-...`
`QuestionId`	UUID	Non-null, immutable	`7d8e9f0a-...`
`QuestionSetId`	UUID	Non-null, immutable	`1a2b3c4d-...`

Game Types

Domain Type	Underlying	Constraints	Example
`GameCode`	String	Non-blank, format: `Word-Word-Word`	`Blue-Dancing-Horse`
`GameState`	Enum	One of 7 defined states	`PLAYING`
`QuestionIndex`	int	>= 0, < numberOfQuestions	`3`
`QuestionCount`	int	> 0	`10`
`TimeLimitSeconds`	int	> 0	`60`

GameState Values

State	Description
`AUTO_LOBBY`	Waiting for players, lobby timer running
`COUNTDOWN`	Game starting, countdown active
`PLAYING`	Active question, accepting answers
`REVIEWING`	Showing answer review for current question
`RESULTS`	Showing final rankings
`COOLDOWN`	Post-results cooldown
`FINISHED`	Game ended

Player Types

Domain Type	Underlying	Constraints	GDPR	Example
`PlayerName`	String	Non-blank, max 40 chars	Personal	`Bob`
`PlayerEmail`	String	Valid email format	Personal	`bob@example.com`

GDPR Notes — Player Data

PlayerName and PlayerEmail are personal data under GDPR
Must be deletable on request (right to erasure)
Retention: tied to game lifecycle — delete after game ends or on request
Purpose: identifying players during gameplay

Question Types

Domain Type	Underlying	Constraints	Example
`QuestionText`	String	Non-blank	`How tall is the Empire State Building?`
`IsoUnit`	String	Non-blank, ISO unit code	`m`, `km`, `presidents`
`RangeMin`	double	< RangeMax	`0.0`
`RangeMax`	double	> RangeMin	`1000.0`
`CorrectValue`	double	Within [RangeMin, RangeMax]	`443.0`
`IllustrationUrl`	String	Valid URL or null	`https://media.example.com/...`
`FasitSource`	String	Valid URL	`https://en.wikipedia.org/...`
`FasitCheckedAt`	String	ISO date YYYY-MM-DD	`2024-10-01`

Answer Types

Domain Type	Underlying	Constraints	Example
`UserMin`	double	< UserMax	`380.0`
`UserMax`	double	> UserMin	`450.0`
`Delta`	double	Computed: UserMax - UserMin, >= 0	`70.0`
`SubmittedAt`	long	Epoch millis, > 0	`1700000042000`

Score & Result Types

Domain Type	Underlying	Constraints	Example
`Rank`	int	>= 1	`1`
`AverageResponseMs`	long	>= 0, milliseconds	`8200`
`Percentage`	double	0.0 to 100.0	`45.5`
`MedianDelta`	double	>= 0	`95.0`

Time Types

Domain Type	Underlying	Constraints	Usage
`EpochMillis`	long	> 0	Game start, countdown end, question start
`DurationMs`	long	>= 0	Time remaining, response times
`DurationSeconds`	int	> 0	Question time limit

Aggregate Summary

Aggregate / Entity	Key Types	Mutable
Game	GameId, GameCode, GameState, QuestionIndex, QuestionCount, TimeLimitSeconds, EpochMillis	Yes (aggregate root)
Player	PlayerId, PlayerName, PlayerEmail, GameCode	No (record)
Question	QuestionId, QuestionText, IsoUnit, RangeMin, RangeMax, CorrectValue	No (record)
QuestionSet	QuestionSetId, List<Question>	No (record)
Answer	QuestionId, PlayerId, UserMin, UserMax, SubmittedAt	No (record)
ScoreResult	List<PlayerRanking>, ResponseTimeStat	No (record)
AnswerVisualization	QuestionText, CorrectValue, Percentage, List<PlayerRange>	No (record)

Implementation Notes

All domain types should be Java records (immutable value objects)
Validation happens in the record constructor (compact constructor)
Adapters convert primitives to domain types at the boundary
Game is the only mutable aggregate — uses SMC state machine for transitions
Primitives are allowed in private helper methods within the domain layer

Tracking A Game For Insight With Umami

Sat, 28 Feb 2026 00:00:00 +0000

Mental Model

For games, the best practice in Umami is:

Track state transitions as events, not page views.

Because:

It’s a SPA-like structure
No full reloads
One URL represents many states
We care about flow, not reloads

Best Tracking Architecture

Track Game Start

When game loads:

umami.track('game-start', {
  game: 'Blue-Soaring-Phoenix'
});

The game names are currently random

Track State Transitions

Every time your state machine changes state:

umami.track('state-change', {
  game: 'Blue-Soaring-Phoenix',
  from: previousState,
  to: currentState
});

Or even better:

umami.track(`state-${currentState}`, {
  game: 'Blue-Soaring-Phoenix'
});

Now each state becomes measurable.

Track Important Events

Examples:

umami.track('level-complete', {
  game: 'Blue-Soaring-Phoenix',
  level: 3
});

umami.track('player-death', {
  game: 'Blue-Soaring-Phoenix',
  state: currentState
});

umami.track('game-finished', {
  game: 'Blue-Soaring-Phoenix'
});

How To Build Funnels From This

Example funnel:

game-start
state-intro
state-battle
level-complete
game-finished

This tells you:

Where players drop off
Which states are bottlenecks
Which states cause rage quit
Conversion from start → finish

Advanced (Recommended)

Since you are using:

/screen/{game-id}

You should:

Extract game ID dynamically

const gameId = window.location.pathname.split('/').pop();

umami.track('game-start', { game: gameId });

Now your tracking automatically works for all games.

Even Better: Track State Duration

Add timestamps:

let stateEnterTime = Date.now();

function onStateChange(newState) {
  const duration = Date.now() - stateEnterTime;

  umami.track('state-duration', {
    game: gameId,
    state: previousState,
    duration: duration
  });

  stateEnterTime = Date.now();
}

The Cleanest Structure For tracking?

Given your architecture, I would track:

Event	When
game-start	Initial load
state-enter	Every state transition
state-exit	Optional
game-finished	Win
game-abandoned	On unload (optional)

Goals

Information I want:

Which states take too long
Which states are skipped
Engagement level
Reconstruct full player paths, when do they fall off
Detect loops
Identify impossible transitions
Find stuck states

I Do NOT want:

Track every tiny UI action
Track animations
Track every frame

As this will flood our analytics.

Track:

Meaningful transitions
Player intent
Milestones

Open questions

Do we want per-session tracking or anonymous only?
What are the benefits of each approach?
GDPR considerations.

Our Engineering Perspective: High Insight, Low Overhead

As we refine our tracking architecture for the game, our goal is to maximize the signal-to-noise ratio. We want to know exactly how players experience the game without bloating the client-side logic or flooding our database with trivial UI events.

1. Minimal Code Overhead via State Machine Hooks

Since the game already operates on a formal state machine, we don't need to sprinkle umami.track calls throughout our UI components. Instead, we hook directly into the state transition logic. One single function call in the state machine's entry/exit handler covers the entire application. This keeps our domain logic clean and our tracking centralized.

2. Strategic Session Tracking vs. Pure Anonymity

We discussed the tradeoff between session-based and anonymous tracking.

Anonymous (Default): Great for counting total events and seeing broad trends. This is our baseline and is 100% GDPR compliant out of the box because no PII or persistent identifiers are stored.
Session-Based: By utilizing Umami's built-in session handling (which uses a rotating hash based on IP, User Agent, and Website ID), we can reconstruct a single player's journey through the states without actually identifying who they are. This is the "sweet spot" for us: it allows funnel analysis (Start → Level 1 → Finish) while remaining privacy-first. We aren't tracking people; we are tracking journeys.

3. "Journey Replay" without the Data Weight

Instead of complex session recording tools, we use these events to build a "breadcrumb trail." If we see a high frequency of state-enter events for the same session without a corresponding game-finished, we've identified a drop-off point. If we see a session looping between two states, we've found a UX friction point or a bug.

4. GDPR by Design

By hosting our own Umami instance and stripping out PII before it ever hits the wire, we ensure that our player data never leaves our infrastructure. Our "we" approach means we own the data, the tracking logic, and the responsibility to keep it anonymous.

Summary of our tracking strategy:

Hook the State Machine: Zero UI-level boilerplate.
Track Journeys, not Users: Leverage Umami's anonymous session hashes.
Signal over Noise: Focus on state transitions and milestones to keep the data actionable.

Proxmox Sdn Design

Mon, 2 Feb 2026 00:00:00 +0000

Virtualized Firewall with Color-Coded Zones

Physical Layout

Internet (ISP)
      |
      | [Physical NIC 1 - RED/WAN]
      |
 ┌────▼────────────────────────────────────────┐
 │         Proxmox Host (4 NICs)               │
 │                                             │
 │  NIC1: enp1s0 (RED - WAN/Internet)         │
 │  NIC2: enp2s0 (Trunk - VLANs 10,20,30)     │
 │  NIC3: enp3s0 (Optional trunk/backup)       │
 │  NIC4: enp4s0 (Proxmox management)         │
 │                                             │
 │  ┌─────────────────────────────────────┐   │
 │  │   Proxmox SDN Configuration         │   │
 │  │                                     │   │
 │  │  Zone: RED    (no VLAN, direct)    │   │
 │  │  Zone: GREEN  (VLAN 10)            │   │
 │  │  Zone: ORANGE (VLAN 20)            │   │
 │  │  Zone: BLUE   (VLAN 30)            │   │
 │  └─────────────────────────────────────┘   │
 │                                             │
 │  ┌─────────────────────────────────────┐   │
 │  │  Firewall VM (IPFire/OPNsense)     │   │
 │  │                                     │   │
 │  │  vtnet0 → vmbr0 (RED)   [WAN]     │   │
 │  │  vtnet1 → vmbr10 (GREEN) [LAN]    │   │
 │  │  vtnet2 → vmbr20 (ORANGE) [DMZ]   │   │
 │  │  vtnet3 → vmbr30 (BLUE) [Wireless]│   │
 │  └─────────────────────────────────────┘   │
 │                                             │
 │  ┌─────────────┐  ┌─────────────┐          │
 │  │ Server VMs  │  │  DMZ VMs    │          │
 │  │ (GREEN)     │  │  (ORANGE)   │          │
 │  │ → vmbr10    │  │  → vmbr20   │          │
 │  └─────────────┘  └─────────────┘          │
 └─────────────────────────────────────────────┘
              |
              | [Physical NIC 2 - Trunk with VLANs]
              |
         ┌────▼────┐
         │ Managed │
         │ Switch  │
         │ (VLANs) │
         └────┬────┘
              |
    ┌─────────┼─────────┐
    |         |         |
 [VLAN 10] [VLAN 20] [VLAN 30]
  GREEN     ORANGE     BLUE
  Servers    DMZ      Wireless

Proxmox Network Configuration

Bridge Configuration

# /etc/network/interfaces

# Management interface (Proxmox web UI access)
auto enp4s0
iface enp4s0 inet static
    address 10.1.2.10/24
    gateway 10.1.2.1

# RED Zone - WAN/Internet (dedicated, no VLAN)
auto vmbr0
iface vmbr0 inet manual
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware no
    # This bridge is ONLY for firewall WAN interface

# VLAN-aware trunk bridge for internal zones
auto vmbr1
iface vmbr1 inet manual
    bridge-ports enp2s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10 20 30
    # Carries all internal VLANs

# GREEN Zone - Servers (VLAN 10)
auto vmbr10
iface vmbr10 inet manual
    bridge-ports enp2s0.10
    bridge-stp off
    bridge-fd 0
    # Proxmox host can have IP here for management
    # address 10.10.10.2/24

# ORANGE Zone - DMZ (VLAN 20)
auto vmbr20
iface vmbr20 inet manual
    bridge-ports enp2s0.20
    bridge-stp off
    bridge-fd 0

# BLUE Zone - Wireless (VLAN 30)
auto vmbr30
iface vmbr30 inet manual
    bridge-ports enp2s0.30
    bridge-stp off
    bridge-fd 0

Alternative: Using Proxmox SDN (Web UI)

Instead of manual bridge config, use Proxmox SDN:

Datacenter → SDN → Zones:

Zone: zone_red
  Type: Simple
  Bridge: vmbr0

Zone: zone_green
  Type: VLAN
  Bridge: vmbr1
  Tag: 10

Zone: zone_orange
  Type: VLAN
  Bridge: vmbr1
  Tag: 20

Zone: zone_blue
  Type: VLAN
  Bridge: vmbr1
  Tag: 30

Datacenter → SDN → VNets:

VNet: red_wan
  Zone: zone_red

VNet: green_servers
  Zone: zone_green
  Subnet: 10.10.10.0/24
  Gateway: 10.10.10.1 (firewall)

VNet: orange_dmz
  Zone: zone_orange
  Subnet: 10.20.20.0/24
  Gateway: 10.20.20.1 (firewall)

VNet: blue_wireless
  Zone: zone_blue
  Subnet: 10.30.30.0/24
  Gateway: 10.30.30.1 (firewall)

Firewall VM Configuration

VM Hardware Settings

VM ID: 100 (Firewall)

Hardware:
  - CPU: 2 cores (or more if doing IDS/IPS)
  - Memory: 2048 MB (4096 if using Suricata/IPS)
  - Disk: 20GB (thin provisioned)

Network Devices:
  net0: virtio, bridge=vmbr0 (RED/WAN)
  net1: virtio, bridge=vmbr10, tag=10 (GREEN)
  net2: virtio, bridge=vmbr20, tag=20 (ORANGE)
  net3: virtio, bridge=vmbr30, tag=30 (BLUE)

Options:
  - Start at boot: Yes
  - Start/Shutdown order: 1 (starts first)

Firewall Zone Mapping

Inside the firewall VM (IPFire example):

Interface Assignment:
  RED (WAN):       vtnet0 → vmbr0 → Internet
  GREEN (LAN):     vtnet1 → vmbr10 (VLAN 10) → Servers
  ORANGE (DMZ):    vtnet2 → vmbr20 (VLAN 20) → DMZ
  BLUE (Wireless): vtnet3 → vmbr30 (VLAN 30) → Wireless clients

IP Addressing Scheme

RED (WAN):        DHCP or static from ISP
GREEN (Servers):  10.10.10.0/24
  - Firewall:     10.10.10.1
  - Proxmox:      10.10.10.2
  - VMs:          10.10.10.10-254

ORANGE (DMZ):     10.20.20.0/24
  - Firewall:     10.20.20.1
  - Web server:   10.20.20.10
  - Mail server:  10.20.20.11

BLUE (Wireless):  10.30.30.0/24
  - Firewall:     10.30.30.1
  - DHCP range:   10.30.30.100-200

Management:       192.168.100.0/24
  - Proxmox:      192.168.100.10

Traffic Flow Examples

Internet Access from Server VM

Server VM (10.10.10.50)
  ↓ via vmbr10 (VLAN 10)
Firewall GREEN interface (10.10.10.1)
  ↓ routing + NAT
Firewall RED interface
  ↓ via vmbr0
Physical NIC 1 (enp1s0)
  ↓
Internet

DMZ to Server Communication (blocked by default)

DMZ VM (10.20.20.10)
  ↓ via vmbr20 (VLAN 20)
Firewall ORANGE interface (10.20.20.1)
  ↓ [FIREWALL RULES - usually DENY]
Firewall GREEN interface (10.10.10.1)
  ↓ via vmbr10 (VLAN 10)
Server VM (10.10.10.50)

Wireless Client to Internet

Wireless device (10.30.30.150)
  ↓ via Access Point (VLAN 30 tagged)
Physical Switch (VLAN 30)
  ↓ via trunk
Physical NIC 2 (enp2s0, VLAN 30)
  ↓ via vmbr30
Firewall BLUE interface (10.30.30.1)
  ↓ routing + NAT
Firewall RED interface
  ↓
Internet

External Switch Configuration

Your managed switch needs VLAN configuration:

Port 1: Trunk (to Proxmox NIC 2)
  - Tagged VLANs: 10, 20, 30
  - Untagged: none

Port 2-10: GREEN (Servers)
  - Untagged VLAN: 10

Port 11-15: ORANGE (DMZ)
  - Untagged VLAN: 20

Port 16-24: Access Points
  - Tagged VLAN: 30 (wireless clients)
  - Or untagged VLAN 30 if AP doesn't do VLANs

VM Deployment Example

Web Server in DMZ

VM ID: 200 (Web Server)

Hardware:
  - CPU: 2 cores
  - Memory: 2048 MB
  - Disk: 50GB

Network:
  net0: virtio, bridge=vmbr20, tag=20

Inside VM:
  IP: 10.20.20.10/24
  Gateway: 10.20.20.1 (firewall)
  DNS: 10.10.10.53 (if you have internal DNS)

Firewall rules needed:

ORANGE → RED: Allow HTTP/HTTPS outbound
RED → ORANGE: Allow HTTP/HTTPS to 10.20.20.10 (port forward)
ORANGE → GREEN: Deny (except specific DB server on specific port)

Database Server on GREEN

VM ID: 201 (Database Server)

Network:
  net0: virtio, bridge=vmbr10, tag=10

Inside VM:
  IP: 10.10.10.20/24
  Gateway: 10.10.10.1

Firewall rules:

ORANGE (10.20.20.10) → GREEN (10.10.10.20:3306): Allow
GREEN → Any: Default allow to internet

High Availability Considerations

If you want redundancy:

Proxmox Node 1:                Proxmox Node 2:
NIC1 → RED                     NIC1 → RED (failover)
NIC2 → Trunk (active)          NIC2 → Trunk (standby)
NIC3 → Cluster link            NIC3 → Cluster link
NIC4 → Management              NIC4 → Management

Firewall VM with HA enabled (Proxmox HA manager)
Shared storage (Ceph or NFS) for VM disks

Security Notes

Proxmox management network (an RFC1918 range on its own VLAN) should be on GREEN or separate VLAN
Firewall VM gets CPU pinning for better performance
Enable virtio for all network interfaces (better performance)
Disable MAC learning on bridges if having issues
Log firewall rules to monitor traffic between zones
Regular backups of firewall VM configuration

Migration from Physical Firewall

Document current setup (rules, port forwards, DHCP, DNS)
Deploy firewall VM with RED on separate test network
Configure GREEN zone first, test connectivity
Add ORANGE and BLUE, verify isolation
Migrate rules one zone at a time
Test thoroughly before switching production traffic
Keep old firewall as backup for a few weeks

Performance Considerations

With 4 NICs and virtualized firewall:
- Expected throughput: 1-2 Gbps (with virtio)
- Latency: ~1ms additional vs physical
- CPU usage: ~5-15% per core under load

If you need 10G or more:
- Consider PCI passthrough of NIC to firewall VM
- Or use SR-IOV for near-native performance

Header Of INIO

Mon, 2 Feb 2026 00:00:00 +0000

Header of INIO

This article is related to my previous beloved Hakyll site. Unfortunately maintaining a number of ecosystems (despite my love for them all ) takes its toll. I therefore consolidate on JBake for now.

Still most of this remains true.

Metainfo


title=Header Of INIO
date=2026-02-02
type=post
status=published
tag = hakyll blog structure
level = low
lang = en
description =This is a description!

Title

Title of the document replace first line #Header
Reflected in this documents filename along with date, This is also the base for any static links.

Author:

Name of person/institution responsible for the content.

author=me

Level

In order to keep up with GDPR, this information should probably reflect values, policies and national guidelines.

high, medium, low

level=medium

Language

If multi-language-publishing is set up
no,en,de

lang=no

Date

When to publish the article
ISO date format: YYYY-MM-DD

date = 2022-02-02

Note Pipeline Design

Thu, 1 Jan 2026 00:00:00 +0000

Overview

A single-source, multi-target publishing system that maintains notes in plain markdown with YAML frontmatter and routes them to different outputs based on metadata.

Architecture


Source Repository
├── posts/
│   ├── session-with-claude.md
│   ├── project-notes.md
│   └── research-paper.md
├── img/
│   └── diagrams/
├── data/
│   ├── tables.csv
│   └── figures.tex
└── pipeline/
    ├── Makefile
    ├── build.kt (or build.py)
    └── templates/
        ├── pdf.tex
        ├── web.html
        └── slides.html

Metadata-Driven Routing

Your frontmatter determines the pipeline:

title: Session with claude
author: jensse
category: private      # routes to: private blog, encrypted PDF
level: low            # affects: visibility, indexing
tags: ai code explore # used for: cross-linking, search
lang: en
date: 2025-02-21
output:
  - web-private       # target: personal site (authenticated)
  - pdf-archive       # target: versioned PDF in archive/
format: article       # template: article vs slides vs paper

Pipeline Stages

Stage 1: Parse & Route

// build.kt (pseudo-code)
fun processNote(file: Path) {
    val (frontmatter, content) = parseMarkdown(file)

    val targets = when {
        frontmatter.category == "private" &&
        frontmatter.level == "low" ->
            listOf(Target.PrivateWeb, Target.PDFArchive)

        frontmatter.category == "public" ->
            listOf(Target.PublicWeb, Target.PDF)

        frontmatter.format == "paper" ->
            listOf(Target.LaTeXPaper, Target.PDF)

        else -> listOf(Target.DefaultWeb)
    }

    targets.forEach { buildForTarget(it, file, frontmatter) }
}

Stage 2: Data Processing

For notes with embedded data/figures:

posts/research-paper.md
  ↓ (references data/experiment.csv)
  ↓
pipeline/processors/csv-to-table.kt
  ↓ (generates LaTeX table or SVG chart)
  ↓
build/intermediates/experiment-table.tex
  ↓
[included in final document]

Stage 3: Format Conversion

Using Pandoc as the universal converter:

# For web output
pandoc post.md \
  --template=templates/web.html \
  --filter=process-images.py \
  --css=styles.css \
  -o output/web/post.html

# For PDF via LaTeX
pandoc post.md \
  --template=templates/pdf.tex \
  --filter=process-latex.py \
  --pdf-engine=xelatex \
  -o output/pdf/post.pdf

# For slides
pandoc post.md \
  --template=templates/slides.html \
  -t revealjs \
  -o output/slides/post.html

Stage 4: Post-Processing

Copy images to output directories
Generate index/TOC pages
Create RSS feeds
Update search index

Makefile Structure

# Variables
SRC_DIR := posts
IMG_DIR := img
OUT_DIR := output
BUILD_DIR := build

# Targets
all: web pdf

web: $(patsubst $(SRC_DIR)/%.md,$(OUT_DIR)/web/%.html,$(wildcard $(SRC_DIR)/*.md))

pdf: $(patsubst $(SRC_DIR)/%.md,$(OUT_DIR)/pdf/%.pdf,$(wildcard $(SRC_DIR)/*.md))

# Pattern rules
$(OUT_DIR)/web/%.html: $(SRC_DIR)/%.md
	@mkdir -p $(OUT_DIR)/web
	kotlin build.kt web $<

$(OUT_DIR)/pdf/%.pdf: $(SRC_DIR)/%.md
	@mkdir -p $(OUT_DIR)/pdf
	kotlin build.kt pdf $<

clean:
	rm -rf $(OUT_DIR) $(BUILD_DIR)

watch:
	fswatch -o $(SRC_DIR) $(IMG_DIR) | xargs -n1 -I{} make all

.PHONY: all web pdf clean watch

Example Build Script (Kotlin)


// build.kt
import java.nio.file.Path
import kotlin.io.path.*

data class Frontmatter(
    val title: String,
    val category: String,
    val level: String,
    val output: List<String>,
    val format: String = "article"
)

enum class Target {
    PrivateWeb, PublicWeb, PDF, LaTeXPaper
}

fun main(args: Array<String>) {
    val command = args[0] // "web" or "pdf"
    val sourceFile = Path(args[1])

    val (frontmatter, content) = parseMarkdownFile(sourceFile)

    when (command) {
        "web" -> buildWebOutput(sourceFile, frontmatter, content)
        "pdf" -> buildPDFOutput(sourceFile, frontmatter, content)
    }
}

fun buildWebOutput(source: Path, meta: Frontmatter, content: String) {
    val templatePath = selectTemplate(meta.category, meta.format, "web")

    executeCommand(
        "pandoc", source.toString(),
        "--template=$templatePath",
        "--filter=filters/web-images.py",
        "-o", outputPath(source, "web", "html")
    )
}

fun buildPDFOutput(source: Path, meta: Frontmatter, content: String) {
    // Preprocess: extract LaTeX snippets, CSV data
    val processed = preprocessForLaTeX(source, content)

    // Convert to PDF via LaTeX
    executeCommand(
        "pandoc", processed.toString(),
        "--template=templates/pdf.tex",
        "--pdf-engine=xelatex",
        "-o", outputPath(source, "pdf", "pdf")
    )
}

fun selectTemplate(category: String, format: String, outputType: String): String =
    when {
        format == "paper" -> "templates/academic-paper.$outputType"
        category == "private" -> "templates/private-note.$outputType"
        else -> "templates/default.$outputType"
    }

Data Processing Pipeline

For your LaTeX/CSV workflow:

data/experiment.csv
  ↓
pipeline/processors/CsvToLatexTable.kt
  ↓
build/intermediates/experiment-table.tex

data/diagram.tex (TikZ)
  ↓
pipeline/processors/LatexToSvg.kt
  ↓
build/intermediates/diagram.svg
  ↓ (for web)
img/generated/diagram.svg
  ↓ (for PDF, keep as .tex)
[embedded directly in LaTeX]

Key Advantages

Single source of truth: All notes in posts/*.md
Version control friendly: Plain text, Git-friendly
Metadata-driven: Routing logic in frontmatter, not file locations
Composable: Each processor is a small, testable function
Incremental builds: Make only rebuilds changed files
Type-safe: Kotlin gives you compile-time safety for your build logic
No hidden magic: You control every transformation

Migration Path

Start simple: Get basic markdown → HTML working with Pandoc
Add routing: Implement metadata parsing and target selection
Add formats: One at a time (PDF, then slides, etc.)
Add preprocessing: CSV conversion, LaTeX snippets as needed
Optimize: Caching, parallel builds when it matters

Example Workflow

# Write a note
vim posts/new-idea.md

# Build everything
make all

# Or build specific target
make web
make pdf

# Watch for changes
make watch

# Deploy to destinations
make deploy-private  # rsync to private server
make deploy-public   # push to GitHub Pages

Tools You'll Need

Pandoc: Universal document converter
Make: Build orchestration
Kotlin (or Python): Custom processing scripts
XeLaTeX: PDF generation from LaTeX
ImageMagick/Inkscape: Image format conversions
fswatch: File watching for auto-rebuild

INIO

Datainnbrudd i Lørenskog: skaden har skjedd, hva nå?

Det som kommer etterpå

Om betalingene

Om selvmord og selvmordsforsøk

Andre dokumenterte konsekvenser

Vær beredt

Utpressingskrav:

Betalinger:

Personlig målretting:

Selvmord og alvorlige psykiske reaksjoner:

Arbeidstap og andre sosiale konsekvenser:

En liten betraktning på tampen

Om arbeidsprosessen

Ansvarlighetsmatrise

Blue/Green on Paper: Upgrading Forgejo Seven Major Versions

Blue/Green on Paper: Upgrading Forgejo Seven Major Versions

Blue/green on paper

One name, two slots

Rehearse on a copy

What went wrong

Making drift visible

The cutover

Why we run SSL Labs against every public service — including this site

A certificate is not a configuration

Why an external test, from a third party

What the report grades

Why it is on the launch checklist

The honest caveat

Multi lingual support in the Helix editor

Tech Stack

Files Involved

Step 1: Install the Language Servers with mise

Step 2: Configure Helix (~/.config/helix/languages.toml)

Step 3: Switching Between English and Norwegian

Step 4: Verify the Setup

Summary

Fetch data from Open Street Maps

reMarkable syncbook

Why

Prerequisites

Enabling SSH on the reMarkable

Building

First run

Usage

Backups

Advanced: writing native ink annotations

License

Pulling charger data from NOBIL

Serial Console to a Nexus 5010

Serial Console to a Nexus 5010

Wrong server first

What showed up on the other end

First boot, deliberately incomplete

A key type from the future

What's actually plugged in

Next: Ansible, once there's an address to talk to

IKEA VIDGA connector

DNS Resolver configuration and setup

DNS in a Distributed Homelab: Control, Constraints, and What Actually Works

The Context: A Distributed Setup That Grew Organically

The Architecture: Simple, Distributed, and Actually Working

Key principles

DNS as a Control Plane

Why This Matters

The Trade-off: Friction vs Control

Open Questions

Monoculture outside the standard

This is not a bug

What just happened?

The problem

The cure

Markdown Stuff

Problems

Code block

Table

Tegn

Competitive Analysis: Guestimate vs. the Market

Competitive Analysis: Where Does Guestimate Fit?

The Market

Step 2: Configure Helix (`~/.config/helix/languages.toml`)