@xyo-network/event-kit-example
Public npm package (publishConfig.access: public) — design-partner
reference for the White Paper split:
| Role | Owner |
|---|---|
| Generic wake daemon | Event Kit publisher + admission gate |
| Application reducer | You — checkpoint ranges from admitted wakes |
Replaces
Typical bespoke “HMAC webhook URL that runs my indexer”:
- open or semi-secret HTTP that executes heavy work inline
- hand-rolled shared secrets without on-chain enable/disable
- no idempotent
wakeId/ grant freshness story
This example rehearses admit-and-enqueue → checkpointing reducer instead.
Its specs now drive the real D-002 path end to end: a real XYO account mints the
wallet JWT, the gate runs verifyWakeRequest + admitAndEnqueue, and the
failure matrix covers a malformed token, a Payload the token does not commit to,
a wrong audience, an out-of-scope queue, a revoked grant, concurrent replay,
idempotent retry, and checkpoint-save failure.
Chain state, the queue, and the inbox remain in-memory, so this is rehearsal evidence. It does not close the design-partner gate, which needs a partner to delete equivalent bespoke webhook auth or a signed deferral.
API
createCheckpointingRangeReducer— appliesfromPosition/toPositionand persistslastProcessedPositionplus scoped wake/hash recordscreateMemoryReducerCheckpointStore— in-memory checkpoint for tests/demos
Use a separate checkpoint store for each source and logical consumer. Admission
pins source identity and the accepted subscription before the reducer sees a wake.
Stores must provide runExclusive for all reducers sharing that checkpoint.
The memory implementation supplies this serialization; a persistent implementation
must coordinate its actual owners. ID-only checkpoints fail visibly and require
explicit evidence-backed migration. Serialization reduces parallelism for one
checkpoint. applyRange still needs repeat-safe external effects because a
process may die after those effects and before checkpoint save.
See specs for the happy path and the injected failure cases. Body tampering is
detected by recomputing the XYO Payload hash and comparing it with the
wallet-signed JWT eventHash; there is no separate event signature.