notes: events/talks/kericonf26-08-hansen-witnesses-watchers

This data as json

path title type status classification words body
events/talks/kericonf26-08-hansen-witnesses-watchers Ryan Hansen: Witnesses and Watchers (KERIConf 2026) summary v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation partner 778 # Ryan Hansen: Witnesses and Watchers (KERIConf 2026) **Abstract.** Ryan Hansen, a member of the KERI Foundation development team, gave a walkthrough of deploying KERI (Key Event Receipt Infrastructure) witnesses, watchers and a boot service from the code that healthKERI open sourced. He summarized the core concepts, stepped through the setup guide in the KERI Foundation's boot repository, and demonstrated a wallet provisioning witnesses against the KERI Foundation's demonstration host. The session is for people who want to stand up this infrastructure themselves. ## Summary Hansen introduced himself as part of a new KERI Foundation development team and framed the session around three components: the boot service, witnesses and watchers, plus deployment to the web in general. He pointed the audience to the setup guide in the KF boot repository under the KERI Foundation GitHub organization and said he would summarize it rather than run it live. He recalled the core concepts: KERI is about keys, of two kinds, signing keys and rotation keys; key events, which he grouped into single-signature and multi-signature events; and the KEL (key event log) that records them. Everything else supports that core. For the roles of the ecosystem's components he recommended Samuel Smith's white paper and slides, linked from keri.one. He gave three disclaimers. The guide is opinionated, one of many ways to deploy. The services are Falcon applications, plain Python over HTTP, and still work in progress; the witness and watcher code is in production use at healthKERI, while the boot service is newer. And the guide is a demonstration that runs several witnesses on one host, which is not a production setup. For production he sketched witness and watcher providers spread across cloud regions and availability zones, with a wallet able to choose among one or several providers to widen its witness pool. The steps followed: an Ubuntu 24.04 base with libsodium, Nginx for TLS (Transport Layer Security) termination and reverse proxying, and certbot. Asked about Docker, he said it is fine for development but that Samuel Smith advises against containers for this deployment on security grounds, so the guide stays close to bare metal. Next came a no-login service user and a directory tree under /opt/keri, then uv and a pinned Python 3.14.0. He installed three packages straight from GitHub, pending a PyPI (Python Package Index) release: the healthKERI witness (witopnet), the watcher (watopnet), and the boot service, which acts as the control plane for provisioning witnesses and watchers. Configuration files set each witness's base URL and ports; four witness instances on one host let the wallet offer a three-of-four witness threshold. Launch scripts, a boot service environment variable listing the witness back ends, the Circus process manager under systemd, and Nginx with TLS completed the setup. In the demonstration he created a vault and a new AID (autonomic identifier) locally, then used the KERI Foundation plugin, adapted from healthKERI's work, to begin onboarding with a three-of-four profile. The boot service introduces the witnesses, returns their OOBIs (out-of-band introductions), and the wallet rotates them in. A first attempt stalled because his IDE (integrated development environment) was in debug mode; the second succeeded. He then enrolled an authenticator app and issued a test credential. Questions covered how this differs from the witness inside KERIpy (this is a separate, production-oriented project), single-witness configurations (supported), what Circus adds over systemd (a Python-level convenience), the environment variables Locksmith needs to discover the witness service, and why code now lives in the KERI Foundation organization. ## Key terms signing keys, rotation keys, key events, key event log, witness, watcher, boot service, three-of-four threshold, OOBI, Circus ## Claims and their evidence - The witness and watcher code open sourced by healthKERI is in production use there; the boot service is newer and will be iterated. [presenter-reported] - Running several witnesses on one host is for demonstration only and is not a production deployment. [presenter-reported] - The boot service makes the first introduction with an ephemeral AID, then uses an account relationship for later calls, some of which go directly to the witnesses. [informative] - Four configured witness back ends allow the wallet to offer a three-of-four witness threshold; a single witness is also supported. [informative] - The packages are expected on PyPI after the conference, and the KERI Foundation host is for demonstration use. [presenter-reported] ## Related KF boot repository and setup guide, witness-hk (witopnet), watopnet, KERIpy, the Locksmith wallet, healthKERI, Samuel Smith's KERI white paper; earlier KERIConf 2026 presentations by Samuel Smith and a demonstration referred to as Jay's. ## Provenance Drafted by Claude on 2026-10-15 from the curated transcript (08-ryan-hansen-witnesses-watchers.md), all 40 minutes read. No quotations; paraphrase only. Not yet read by Mark.

Links from other tables