notes: events/talks/kericonf26-d2-12-pahio-keri-development-deployment

This data as json

path title type status classification words body
events/talks/kericonf26-d2-12-pahio-keri-development-deployment Keanu Pahio: KERI Development and Deployment (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 735 # Keanu Pahio: KERI Development and Deployment (KERIConf 2026) **Abstract.** Keanu Pahio of the KERI Foundation showed how to deploy the Foundation's KERI (Key Event Receipt Infrastructure) stack locally: the Locksmith wallet, a boot server, witnesses and watchers. He explained the role of each part, demonstrated running them, and pointed to where developers can extend the stack through wallet plugins and the witness and watcher APIs. It is a hands-on talk for developers starting to build on the Foundation's open-source infrastructure. ## Summary Pahio set out the objectives: understand the deployment architecture and the role of each part, deploy witnesses, watchers and a wallet locally, and know where to start developing, for example by writing a Locksmith plugin or extending the witness and watcher APIs. The only requirements are Python, with version 3.13 recommended because 3.14 caused problems in some repositories, and Libsodium, the cryptographic library KERI uses. Locksmith, the wallet, generates AIDs (autonomic identifiers), signs with them, keeps key pairs secure, stores and verifies KELs (Key Event Logs) and handles OOBIs (out-of-band introductions). He used the KERI Foundation branch of the public Locksmith repository, which carries the Foundation's plugin, and pointed to the developer guide for setting up the environment and regenerating the Qt resources. In the demo he created a vault, which an audience member confirmed corresponds to a Habery in KERIpy, the container for AIDs and their keys. The Foundation plugin exists because of the boot server. Witness and watcher services each run two servers: a private boot API that creates and deletes witnesses or watchers, and a public server that anyone can reach once they exist. Because the private API is not reachable from outside, the Foundation's boot server, kf-boot, calls it on the wallet's behalf, and the plugin bridges Locksmith to the boot server. The plugin currently handles onboarding, witness registration, watcher resolution and authentication. Locally, the boot server must run on the same machine as the witnesses and watchers. He showed the plugin base classes in the Locksmith repository that a developer can subclass, using the Foundation plugin as the model, and then started the boot server and connected the wallet to it; the final step of the live demo did not display as expected, and he moved on. For witnesses, he walked through the repository and its developer guide, noted that the configuration was covered by Ryan Hansen earlier in the conference, and ran witnesses showing their internal and public ports and their AIDs. The witness API is a Falcon application; its POST handler checks that the AID is valid, creates a witness, gets the OOBIs and returns them, and that handler is where a developer would add checks or behavior. Watchers follow the same pattern, though their repository had no documentation yet and could not be installed from PyPI. Witnesses and watchers are meant to be deployed together, with witnesses first. In questions, asked why anyone would change shared infrastructure, he gave examples such as rate limits on provisioning, and a plugin that takes payment before provisioning. Others in the room added that changing the API handler adds functions around the witness rather than altering the witness protocol, which is implemented in KERIpy. ## Key terms Locksmith, vault, Habery, KERI Foundation plugin, boot server, kf-boot, witness server, watcher server, private and public APIs, plugin base, Falcon ## Claims and their evidence - The KERI Foundation stack needs only Python (3.13 recommended) and Libsodium to run locally. [presenter-reported] - Witness and watcher services expose a private boot API for provisioning and a public server for use, so provisioning from a wallet goes through a boot server. [informative] - In local deployments the boot server must run on the same machine as the witnesses and watchers. [presenter-reported] - The Foundation's Locksmith plugin currently handles onboarding, witness registration, watcher resolution and authentication, and can be extended, for example to require payment before provisioning. [presenter-reported] - Witnesses and watchers are designed to be deployed together. [presenter-reported] ## Related The Locksmith wallet (KERI Foundation branch), kf-boot and the KERI Foundation witness and watcher repositories; KERIpy; Ryan Hansen's KERIConf 2026 talk on configuration. ## Provenance Drafted by Claude on 2026-10-15 from the curated transcript (d2-12-keanu-pahio-keri-development-deployment.md), all of it (about 23 minutes of speech in a 48-minute recording). The opening objectives are partly reconstructed by the transcript's editor, and two demo passages are mostly silent. No quotations; paraphrase only. Not yet read by Mark.

Links from other tables