notes: events/talks/kericonf26-d2-14-oconnor-path-to-production

This data as json

path title type status classification words body
events/talks/kericonf26-d2-14-oconnor-path-to-production Fergal O'Connor: KERIA and Signify, the Path to Production (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 785 # Fergal O'Connor: KERIA and Signify, the Path to Production (KERIConf 2026) **Abstract.** Fergal O'Connor, identity solutions lead architect at the Cardano Foundation and architect of its Veridian wallet, set out the maturity gaps he sees in KERIA (the KERI cloud agent service) and Signify (its edge client libraries), grouped as developer experience, operational resilience and scalability. The session included a running technical discussion with members of the audience. It is for developers and operators building on KERI (Key Event Receipt Infrastructure) agents in production. ## Summary O'Connor introduced the Veridian wallet, launched to public app stores over a year earlier as, in his account, the first KERI and ACDC (Authentic Chained Data Containers) mobile wallet in production, built on KERIA and Signify. Building it led his team to contribute many changes back. He said the implementation maturity of KERIA and Signify lags behind KERIpy, and that the gaps are ordinary software engineering matters, not protocol or security flaws: the stack works in production but gives too little feedback. He recapped the model from his talk the day before: agent in the cloud, controller at the edge. KERIA, a Python service built on KERIpy, runs isolated agents in the cloud that perform verification of KERI, ACDC and CESR (Composable Event Streaming Representation) and talk to witnesses, watchers, issuers and verifiers. Each agent has one Signify client at the edge that signs events and credentials. Asked about several clients per agent, he said clients sharing a passcode derive the same keys and would work, though differences in local state could cause inconsistencies. Signify, he agreed with a questioner, means any edge client library of KERIA. On developer experience, his team has been strongly typing the edge libraries by generating types for Signify-ts and Signify Java from KERIA's OpenAPI documentation, which is itself generated from KERIpy's data structures, so the definitions stay in sync. He argued that Signify's combined calls, which build, anchor and submit in one step, lose data if a response is lost; operations should be split into create-and-sign and an idempotent submit, as IPEX (Issuance and Presentation Exchange) already is, to support outbox patterns. An audience member suggested reconsidering the API itself, passing CESR streams instead of bulky HTTP payloads. The other major barrier is silent failure: operations that stay pending forever with no reason given. On operational resilience, he described KERIA crashing on certain bad inputs, which in a multi-agent service affects every user; one such case was recently fixed, though it now leaves an operation pending. Escrows in KERIpy handle out-of-order events, not application reliability, so agents need retries and acknowledgements; a 202 response only means a message was queued for an in-memory parser. In-memory queues, such as the one holding a group's partly signed IPEX message, must become durable. He also asked for structured, filterable logs with request or client identifiers, building on logging work Kent had added, semantic versioning between KERIA and Signify, and a migration framework. On scalability, he said clients currently poll for operation status and notifications, which will not scale to thousands of wallets. He proposed Server-Sent Events, which are plain HTTP and work with load balancers. The obstacle is that KERIA derives an operation's completion by checking the database each time instead of storing a completed state; the discussion concluded that KERIpy should emit an event when something important completes. Horizontal scaling comes last: agents' LMDB (Lightning Memory-Mapped Database) files are already isolated, so instances could share a volume with the agency acting as router. ## Key terms KERIA, Signify, cloud agent, edge controller, OpenAPI type generation, outbox pattern, idempotent submit, silent failures, escrow, Server-Sent Events ## Claims and their evidence - Veridian, built on KERIA and Signify, was released to public app stores over a year before the talk. [presenter-reported] - Types for Signify-ts and Signify Java are now generated from KERIA's OpenAPI documentation, which is generated from KERIpy data structures. [presenter-reported] - KERIpy escrows handle out-of-order processing, not end-to-end application reliability, so retries and idempotency are needed between agents. [informative] - KERIA's operation status is computed from the database on each check rather than stored, which blocks event-driven notification. [informative] - The gaps described concern software maturity and resilience, not the security of the protocols. [presenter-reported] ## Related KERIpy, KERIA, Signify-ts, Signify Java, HIO, IPEX, CESR 2, the Veridian wallet, O'Connor's own KERIConf 2026 talk the previous day on KERIA and Signify security architecture, and Thomas's talk on the five Ws that morning. ## Provenance Drafted by Claude on 2026-10-15 from the curated transcript (d2-14-fergal-oconnor-keria-signify-path-to-production.md), all 40 minutes read. Several stretches of rapid audience exchange are hard to attribute and are summarized without naming speakers. No quotations; paraphrase only. Not yet read by Mark.

Links from other tables