DRAFT design spec, 2026-10-07, rev 2. Status: server_name (json64.dev) and kanidm OIDC login
are ruled by the owner. The remaining choices are reversible defaults, marked [default]. Not
built.
Companion: matrix-xmsg bot spec.
A federated Matrix homeserver for the owner's own use and the @genie support bot:
DRAFT design spec, 2026-10-07, rev 2. Status: owner rulings on audience and ACL applied (§4, §8); remaining questions open; not built.
It builds on xmsg: docs/specs/ and TODO.md.
We want user support and debugging in a Matrix room, answered by a dedicated "expert" AI agent session: a long-running Claude Code session primed with the product's docs and code.
Design spec, 2026-10-06. Status: design approved, not yet built.
Claude Code sessions on one machine can message each other (ListAgents / SendMessage), but only
through a model tool call inside a session. Nothing lets a script, CI job, or another host list the
running sessions or push a message into a specific one without spending a model turn.
denful/den#686 asks, underneath the priority table
it proposes, for a module's contents to be transitively mapped to override instead of
conflict -- a recursive property of the submodule and everything under it, with no per-component
lib.mkForce.
The useful version of that is not a declared override list. It is that precedence falls out of where a contribution sits in the graph, with an explicit relation available for the cases where position is wrong. Most of the machinery for this already exists in gen-view, which implements the resolution
Date: 2026-08-27
Who this is for. You know Nix. You do not know this project. This report tells you what exists, what is decided, and what is left.
How to read the numbers. Every figure comes from a command run against the live repositories on the date above. No figure is copied from a document. Where a claim could not be checked, the report says so.
Integrating third-party NixOS-style system builders—such as Finix—into a Den flake workspace requires understanding how Den manages module collection, builder invocation, and output attribute paths.
This tutorial provides a complete architectural guide and three practical integration patterns for wiring Finix hosts into a Den-managed fleet.
Revision note. The first version of this guide was not runnable end to end. Its
finixSystemcalls omitted the requiredlibargument, it assumed Finix declares thenixpkgs.*options Den emits, and it activated host aspects through a key Den ignores. Every code block below has now been evaluated against denc7ef3f1and finix78fd549; §6 builds a realfinix-system.drv. The three corrections are called out inline as Correction 1/2/3.
Predicate for the refresh-daemon work (deliverable 0 in refresh_daemon_plan.md):
XDG config-path support and non-clobbering key-file naming. Rev 2 folds in the
adversarial review (verdict SOUND-WITH-FIXES) and the owner's I7 ruling.
~/.opk/ configurations continue to work untouched. Any
behavior change anywhere must be explicitly identified, never silent.
Companion to refresh_daemon_spec.md (the ratified design, 2026-08-20). All
design forks from the earlier draft of this file are resolved; the decision log
below records the rulings. Branch: feat/refresh-daemon, stacked on
feat/agent-lifetime (PR 1 = openpubkey/opkssh#611).
0. Predicate PR — storage layout (own design discussion; not yet designed)
Successor to the draft reviewed in openpubkey/opkssh#606 (gist version). This revision is the ratified design; §2 lists every material change from that draft with rationale.
opkssh daemon is a standalone, user-started background process that owns OIDC
authentication and token refresh end-to-end. When it is running, every
opkssh login delegates to it: the daemon runs the OIDC flow, holds all secrets,
This specification outlines the architecture for PR 2, building upon the configurable ssh-agent lifetime support introduced in PR 1.
The goal of PR 2 is to transform opkssh login --auto-refresh from a simple foreground sleep loop into a resilient, background-capable Token Refresh Daemon. The daemon automatically maintains active OIDC PK Tokens and keeps loaded certificates in ssh-agent synchronized without interrupting SSH connections.