Skip to content
KN-86 Deckline

Keyring — main-grid key operations

First-party on-device program #9 (ADR-0042). Status: Stub — design pending.

Charter stub. Keyring is canonical per ADR-0042; this doc is a placeholder until the full design lands. See the program roster.

Identity

Section titled “Identity”

The deck’s key-operations surface on the main grid: generate, revoke, inspect, crack. The CIPHER voice (the cryptographic personality) stays OLED-exclusive per ADR-0015; Keyring is the main-grid operations counterpart.

Scope (intended)

Section titled “Scope (intended)”
  • Manage a keyset: generate, inspect, revoke.
  • Crack operations against mission-provided locks/ciphers.
  • The visible, operable face of cryptographic work (CIPHER narrates on the OLED; Keyring is where you act).

Interfaces

Section titled “Interfaces”
  • Launched via (launch-app :keyring …) (NoshAPI Tier 1, ADR-0005). Draws on the cartridge/content rows per the canonical grid; never paints CIPHER glyphs on the main grid (ADR-0015 / ADR-0042 constraint). Authored in KEC Lisp; source under runtime/programs/keyring/.

Open questions

Section titled “Open questions”
  • Keyring ↔ CIPHER coordination contract: how does a main-grid key op trigger/relate to OLED CIPHER utterances without violating OLED-exclusivity? (Event hand-off, not glyph sharing.)
  • Where do keys live — UDS, cartridge save, or a device keystore?
  • Is “crack” a minigame, a timed/threat-coupled operation, or instant against a difficulty value?
  • Does CONDUIT (conduit.md) pull credentials from here?

References

Section titled “References”