Crate hennery_kernel 

Shared collector foundations (kernel spec): storage, request auth, and the operator and their setup, host identity and pairing, and the admin socket.

Modules

admin

The admin socket (kernel spec §4.2): <data>/admin.sock, a Unix socket only the collector’s own user may use, for hennery admin … recovery commands that work without a browser or a session: print the setup link, reset the password or public_url, list the hosts, mint a pairing code.

auth

Request auth for operator routes (kernel spec §3.2, §3.3): the session cookie, behind the browser rules. It replaces the walking skeleton’s development bearer token.

auth_api

Operator auth over HTTP (kernel spec §3, §8): the one-time setup, login and logout, step-up, the signed-in sessions, and passkeys (plan 3c).

capabilities

GET /api/capabilities (kernel spec §8; plan 4b): which mode this collector runs in, and which features it has switched on. The web UI shows the views of its mode (frontend spec §2) and hides a screen whose feature is off.

client_address

Address-only reverse proxy attribution. Never an authentication identity.

coordination

Process ownership and the owner lifecycle gate. Every writer opens through db::open, even before the first optional registration exists.

csp

Kernel spec §7.2: every HTML response carries the Content-Security-Policy. One layer over the whole router sets it, so a page cannot be added without it.

db

SQLite helpers (kernel spec §1).

delivery

Web Push delivery (kernel spec §6; plan 10b-ii): drain the notice queue (push::Notices), apply each notice’s hat policy, and send it to every subscription of the owner’s, encrypted to the browser (RFC 8291) and signed with the collector’s VAPID key (RFC 8292).

egress

The outbound HTTP policy (kernel spec §7.1; gateway spec §4, §5.7): every request hennery itself sends to the network — the gateway’s proxy, its OAuth calls, Web Push — goes through an EgressClient.

hats

Hats (kernel spec §5; umbrella §8): the isolation boundary a session belongs to. A hat is {id, name, colour}; every host has a default hat, and per-host path rules (prefix → hat) pick another for the paths under them. The registry keeps them beside the hosts, on the same connection (Hosts), so a host and its default hat always change together. Every query names the database’s owner (kernel spec §1).

health

/healthz and /readyz (kernel spec §8): whether the process is up, and whether its database answers. For a service manager or a load balancer: they need no session, sit outside the browser rules (kernel spec §3.3), and carry no data, only a fixed word.

hosts

Host identity and pairing (kernel spec §4): the hosts registry, one-time pairing codes, and the check of a host’s hello proof (ACP core §3.5). Every query names the database’s owner (kernel spec §1), bound when the registry opens (db::kernel_owner): another owner’s host is unknown here, and another owner’s code pairs nothing.

json

The JSON body extractor of every route that reads one. axum’s own Json answers a body it refuses with plain text carrying serde’s message, which quotes the request back and changes with serde. This one keeps axum’s status and answers a fixed ApiError instead.

lifecycle

Lifecycle hooks (kernel spec §5.5): what the kernel’s own operations require of the modules that own session and gateway state. They implement the trait, so the kernel never imports them.

logo

Hat logos (kernel spec §5.1; plan 4d-B2). A logo is uploaded as a PNG, at most 64 KiB, and stored and served only as this module re-encodes it: decoded to plain 8-bit pixels, then written afresh as IHDR, IDAT and IEND, so no text, metadata, profile, animation or trailing bytes of the upload survive (the security review’s ruling B: no SVG, no WebP). The browser turns any other format into a PNG before it uploads.

operator

The operator (kernel spec §3): the one owner, their password, the public_url setting, and the one-time setup link that sets them up.

origin

The browser rules (kernel spec §3.3): what every browser route checks before its handler, cookie or not.

passkeys

Passkeys (kernel spec §3.2, plan 3c): WebAuthn with webauthn-rs.

plugin_context

Bounds and redaction for decoded, untrusted startup data. Source validation belongs to the collector, under its owner/scope transaction.

push

Web Push (kernel spec §6; plan 10a): the VAPID key pair in <data>/vapid.key and the tokens it signs, the owner’s push subscriptions, and each hat’s push policy. Delivery and its triggers are plan 10b’s. The subscriptions and the policies share the host registry’s connection and owner, as hats do, and every query names the owner (kernel spec §1).

ratelimit

Failure-based rate limiting per client address (kernel spec §3.2, §4.1): a few free failures within a window, then an exponentially growing lockout.

recents

Project recents (kernel spec §1.1, §5.3; plan 6c decision 11): the directories sessions started or resumed in, per host and hat, newest first. They share the host registry’s connection and owner, and every query names the owner (kernel spec §1).

redact

Shared first-party token scanner. Assemble logical text before scanning; arbitrary provider secrets and encodings are outside this shape contract.

secret

Randomness and hashing for credentials (kernel spec §3, §4).

session_defaults

Owner/hat/agent launcher preferences. All writes recheck authorization, freeze and compare-and-swap revision under the same IMMEDIATE transaction.

web

The web UI, embedded at build time (build.rs; kernel spec §7): the router’s fallback, so it answers only paths no route claims.