Skip to content

Comments

docs: update root README with SDK and pluggable architecture#72

Open
seriouscoderone wants to merge 4 commits intoTHCLab:masterfrom
seriouscoderone:docs/root-readme
Open

docs: update root README with SDK and pluggable architecture#72
seriouscoderone wants to merge 4 commits intoTHCLab:masterfrom
seriouscoderone:docs/root-readme

Conversation

@seriouscoderone
Copy link

Summary

  • Added keriox_sdk (SDK) entry to the Organization section, describing KeriRuntime and Controller for KERI+TEL operations.
  • Added a new Architecture section covering pluggable storage (EventDatabase trait with redb default), pluggable notification dispatch (NotificationBus), and serverless composition (KeriRuntime<D>).

Test plan

  • Verify README renders correctly on GitHub
  • Confirm links to ./keriox_sdk resolve to the correct directory
  • Review Architecture section for accuracy against current codebase

🤖 Generated with Claude Code

seriouscoderone and others added 4 commits February 18, 2026 17:47
…tecture

Gate redb behind `storage-redb` feature flag (default ON) in keri-core and
teliox so the core protocol logic can compile and run without redb. This
enables future alternative storage backends (e.g., DynamoDB for serverless).

Key changes:
- Split EventStorage constructors: generic `new()` (no mailbox) vs
  `new_redb()` (RedbDatabase with mailbox) vs `new_with_mailbox()` (inject)
- Make mailbox_data an Option<MailboxData> to support non-redb backends
- Remove Any bound from EventValidator
- Gate TelLogDatabase, teliox EscrowDatabase, and escrow module behind
  storage-redb feature
- Genericize teliox escrow structs over K: EventDatabase for KEL storage
- Add in-memory MemoryDatabase implementing all database traits for
  validation and testing
- Move rkyv_adapter to database::rkyv_adapter (not under database::redb)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace the concrete HashMap-based NotificationBus with a trait-based
dispatch architecture. NotificationBus is now a Clone-able wrapper around
Arc<dyn NotificationDispatch>, enabling alternative notification backends
(e.g. SQS for serverless) without adding generic type parameters anywhere
in the codebase.

- Add NotificationDispatch trait with dispatch() and register_observer()
- Extract current HashMap logic into InProcessDispatch (RwLock + OnceLock)
- Add NotificationBus::from_dispatch() for custom implementations
- Change register_observer from &mut self to &self across all processors
- Add RwLockingError variant to keri-core Error enum

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace the anonymous 5-tuple return from default_escrow_bus with a named
EscrowSet<D> struct, accept an optional NotificationBus parameter, and
introduce KeriRuntime<D> in keri-sdk as a shared composition layer.

These changes address three problems that block serverless (Lambda) use:

- Anonymous tuple was fragile: callers positionally destructured five
  Arc'd escrows and adding a sixth would break every call site. EscrowSet
  gives named fields so callers pick what they need.

- Bus couldn't be injected: default_escrow_bus always created an
  in-process NotificationBus internally. Lambda handlers need SQS-backed
  dispatch so notifications fan out to queues instead of running inline.
  Accepting Option<NotificationBus> lets callers pass a custom bus while
  None preserves existing default behavior.

- Controller buried its internals: the SDK Controller created processor,
  storage, bus, and escrows in new(), discarded escrows, and kept fields
  private. KeriRuntime<D> extracts the shared KERI processing stack
  (processor, storage, escrows, notification_bus) into a standalone
  public struct so Lambda handlers can be thin shells — deserialize
  request, call runtime, serialize response.

All 13 callers of default_escrow_bus updated. Controller<D,T> now
composes over KeriRuntime<D> via a public `kel` field.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant