sini

den#694: a user's host-class content stays in the user (design)

Status: design agreed in the den Matrix support thread, revised after an adversarial review. This file is for review before any code lands. It is published as a public gist linked from #694 (Q8).

Code read at den 14ca369 (after #743). Every claim is marked measured (at 14ca369) or derived (read from source, not run). The §1 and §5 probes ran with nix-unit under a 12G memory cap in throwaway test files that were not kept, so those tables can only be re-checked by re-running them; the PR cells in §7 re-derive each one. The microvm-topology facts in §3 and the flake-system kind entry in §2 were measured during review, at the same rev.

Charter (owner, 2026-11-06)

The reference is current behaviour on main. This design turns it into a new, formal set of rules that:

1. fix the impurity: content crosses an entity boundary only along an edge some rule derives, with the consent of the entity it applies to. Containment alone ca

sini

Matrix homeserver for json64.dev on the axon cluster

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.

1. Goal

A federated Matrix homeserver for the owner's own use and the @genie support bot:

sini

matrix-xmsg: a Matrix support bot backed by an expert agent session

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.

1. Problem

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.

sini

xmsg v1 — an HTTP bridge into running Claude Code sessions

Design spec, 2026-10-06. Status: design approved, not yet built.

1. Problem

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.

sini

Override as graph position: a design for den#686

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

sini

gen / den — Project Status

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.

sini

Using a Third-Party NixOS-Style Builder (finix) with Den

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 finixSystem calls omitted the required lib argument, it assumed Finix declares the nixpkgs.* options Den emits, and it activated host aspects through a key Den ignores. Every code block below has now been evaluated against den c7ef3f1 and finix 78fd549; §6 builds a real finix-system.drv. The three corrections are called out inline as Correction 1/2/3.

---

sini

opkssh Storage Layout — Predicate PR Specification (rev 2)

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.

Requirements

1. Existing ~/.opk/ configurations continue to work untouched. Any behavior change anywhere must be explicitly identified, never silent.

sini

Refresh Daemon — Delivery Plan

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).

Sequenced deliverables

0. Predicate PR — storage layout (own design discussion; not yet designed)

sini

OPKSSH Token Refresh Daemon — Design Specification

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.

1. Overview

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,