@xyo-network/event-kit-node

中文文档
2.3.4发布于 2026/11/03LGPL-3.0-onlyTypeScriptES Module

Node 26+ Event Kit durability, handshake clients, and SQLite source publisher runtime

原始使用文档
文档目录5 节
  1. Handshake clients
  2. Resident publisher
  3. Durability model
  4. Queue providers
  5. Boundary

@xyo-network/event-kit-node

Node.js 26+ durability adapters for Event Kit. The repository pins Node 26.9.0:

  • createFilesystemCursorStore — publisher cursor for the wake publisher actor
  • createFilesystemPublisherOutbox — durable pending-wake slot for retry stability
  • createSqliteWakeReceiver — atomic durable inbox/queue over one private FULL/WAL SQLite database
  • createSqliteWakeQueue — standalone fenced WakeQueue over node:sqlite
  • createFilesystemWakeQueue / createFilesystemWakeInbox — coordinated SQLite authority with inspectable JSON projections
  • createSqliteBestEffortInbox / createBestEffortSnapshotWorker — persistent bounded hint security/coalescing and independent snapshot work
  • migrateReceiverStore / migrateIdOnlyReducerCheckpoint — explicit stopped-owner offline migration and reports

Handshake clients

Import @xyo-network/event-kit-node/handshake for the Phase 3 control-plane surface. That subpath exports:

  • synchronized finalized-replay readers and XL1 publication composition;
  • publisher and subscriber clients for declaration, discovery, encrypted subscription/grant publication, challenge, acceptance, and revocation; and
  • filesystem stores for replay checkpoints, mutation intents, publication journals, publisher encryption-key custody, and endpoint-challenge decisions.

Generated on-chain handshake mutations use a caller-supplied 16-byte lowercase-hex operation ID. createFilesystemHandshakeMutationIntentStore atomically binds the first request to its exact random service/key, grant, ciphertext, or acceptance artifacts. An exact retry loads that winner before consulting mutable chain state; changed input under the same scoped operation ID fails closed. Records and directories are private (0600/0700). Publisher service intents retain the encryption private key until it can be copied idempotently into key custody. Subscriber intents retain ciphertext and a request fingerprint, not endpoint or challenge-secret plaintext.

createFilesystemFinalizedStatementPublicationJournal then binds the logical mutation to its chain, Claim source, ordered object/attachment hashes, and exact signed transaction. Restart resumes from the highest durable phase and may rebroadcast only that evidence; it never rebuilds or re-signs an ambiguous publication.

The handshake subpath deliberately does not load the wake queues, inbox, outbox, or node:sqlite. A clean packed consumer typechecks and executes it without SQLite coupling. There is one unversioned source-aware contract. Service publication requires sources and maxPositionsPerWake; subscription publication requires source and fromPosition. Authorization remains pinned to the XL1 session independently of source positions. Removed schema suffixes, block-range fields, and profile selectors have no compatibility aliases.

Resident publisher

@xyo-network/event-kit-node/publisher-runtime exports the SQLite publisher authority/stores, persistent runtime, real D-005 discovery, bounded transports, native REST gateway/datalake composition, and XL1/Ethereum/UTC source readers. It uses the shared periodic actor lifecycle; the CLI owns process interrupts, provider cleanup, and probes. Importing the module does not open a database; opening publisher state loads node:sqlite explicitly.

Logical wake creation and pending outbox persistence co-commit. Durable admission receipt, contiguous publisher cursor, and outbox clear co-commit independently for each subscriber. Process death and ambiguous responses resend the same body with a fresh real wallet JWT. Publisher progress is admission progress, not completed receiver compute. See the runbook for ownership, crypto custody, retry/cancellation rules, transport limits, and the remaining hosted/Sequence gates.

status().deliveryDiagnostics reports fixed failure phase/reason counters and the latest received HTTP status and bounded Retry-After delay. These counters cover only the current process and survive a successful retry; they are neither lost-notification counts nor durable receipts. The existing failures field remains the current streak and clears on a matching acknowledgment. Malformed 200/202 content never counts as a delivery. Error text and response bodies are excluded from diagnostics.

Durability model

The 2026-10-05 remediation replaces split identity/enqueue commits with one transaction over scoped wake and token bindings, a stable receipt, exact authorized work, lease state and completion. Duplicate token binding/expiry extension is atomic. FULL/WAL SQLite coordinates objects and processes on one local host; a bounded 100 ms busy wait fails visibly under unresolved contention. Retrying retains logical identity.

The filesystem adapter uses the same authority in receiver.sqlite. Private pending/ and inflight/ JSON files are projections, published exclusively with link and synced directories. They do not decide admission or lease ownership. Missing projections can be repaired; corrupt or mismatching bytes stop processing and remain available for inspection. Claims validate shape and canonical hash against committed authority. Completion removes the retained body while keeping the stable identity/receipt tombstone; stale files cannot resurrect completed work. repairProjections() scans active work and filesystem references explicitly.

Owned directories/files are 0700/0600, with owner, regular-file and symlink checks. Unsafe existing custody is refused instead of chmodding unrelated paths. Publisher cursor/outbox replacement remains single-writer rename, with file and publication-directory syncs. Read, parse, state and sync failures propagate; retained retry bytes/IDs are never replaced because a read failed.

Legacy stores are refused before journal-mode mutation. Use the offline migration runbook on stopped-owner copies; retain backup, inventory and quarantine evidence. The new source format is intentionally incompatible with old writers and runtime dual readers are absent.

Queue providers

All three providers assign a fresh lease fence on each claim. ack()/release() compare the current entry/state/token atomically. A stale or opposite completion throws StaleWakeLeaseError; repeating the same successful operation is inert. Recovery requires recoverInflight({ consumersStopped: true }) after every consumer sharing the store has stopped. The assertion is an operator contract, not a liveness detector. Startup alone does not establish quiescence.

Expanded shared conformance covers stale/repeated completion and successor preservation. Independent-object/process admission races, real SIGKILL boundaries, private custody and signed HTTP tests supplement it. Provider clauses requiring reopen/cross-writer support remain explicitly skipped for memory.

Application effects remain at least once. Fence queue state and separately make external effects idempotent or atomically commit effects/checkpoints in their owner.

node:sqlite is built in, so this adds no dependency. It does not emit an ExperimentalWarning when loaded on the pinned Node 26.9.0 runtime.

Boundary

Current recovery evidence covers local objects/processes and copied fixtures, not host-loss, storage hardware failure, restore or cross-machine qualification. Historical core Gate 5 evidence remains scoped to its original artifacts. See the remediation plan for current checks and measured performance/retention costs. The on-chain publisher roadmap qualifies a single VM in Phases 4-7; a coordinated multi-VM deployment needs a transactional shared store, leases, and fencing and is roadmap Phase 8.

版本与发布记录

@xyo-network/event-kit-node 共发布 22 个版本,首次发布于 2026/08/21;过去 12 个月发布了 22 个版本。

版本发布日期距今
2.3.4latest2026/11/03今天
2.3.32026/11/03今天
2.3.22026/10/313 天前
2.3.12026/10/303 天前
2.3.02026/10/295 天前
2.2.32026/10/286 天前

关于 @xyo-network/event-kit-node 的常见问题

@xyo-network/event-kit-node 是什么?

Node 26+ Event Kit持久性,握手客户端,和SQLite源代码发布者运行时

如何安装 @xyo-network/event-kit-node?

在项目目录运行 npm install @xyo-network/event-kit-node,或使用 pnpm add / yarn add / bun add。它还需要宿主项目提供 peer 依赖:ajv(^8.20)、zod(^4.6)、ethers(^6.17)、async-mutex(^0.5)、@ariestools/sdk(^9.0)、@xyo-network/sdk(^8.1)、@ariestools/actor(^2.0)、@opentelemetry/api(^1.10)、@xyo-network/xl1-sdk(^5.8)、@xyo-network/sdk-protocol(^8.0)、@xyo-network/xl1-protocol(^5.8)、@xyo-network/xl1-statement-graph-sdk(^0.7)、@xyo-network/xl1-statement-graph-engine(^0.7)、@xyo-network/xl1-statement-graph-schemas(^0.7)。npm 7 及以上与 pnpm 8 及以上默认会自动安装必需的 peer 依赖,Yarn 需要手动安装。

@xyo-network/event-kit-node 支持 TypeScript 吗?

支持。包内自带 TypeScript 类型声明(package.json 声明了 types 入口),安装后即可获得类型提示,无需再安装 @types 包。

@xyo-network/event-kit-node 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@xyo-network/event-kit-node 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=26。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@xyo-network/event-kit-node 可以商用吗?

@xyo-network/event-kit-node 使用 LGPL-3.0-only 许可。弱 Copyleft:作为库被调用时通常不要求开源你自己的代码,但修改库本身需以 LGPL 开源;前端打包合并后的适用边界存在不同理解。以上为概括,不构成法律意见,请以许可原文为准。

@xyo-network/event-kit-node 还在维护吗?

最新版本 2.3.4 发布于 2026/11/03(今天);至今共发布 22 个版本,其中过去 12 个月发布了 22 个;首次发布于 2026/08/21。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。