Files
ng-eventually/packages/client
Sylvain Duchesne 1c475d8c9f test(client): real-broker e2e harness for the SDK (own domain, dedicated wallet)
The polyfill had only fake-ng unit tests; real-broker behaviour (SPARQL graph
round-trip, doc_subscribe marshaling, inbox/index) was only ever exercised by
borrowing Festipod's harness. Add packages/client/e2e/ — a standalone Playwright
harness in the SDK's own domain: a minimal SDK page (configure() + the real
@ng-org/web ng, a window.__sdk bridge, zero Festipod domain) loaded in the broker
iframe on the real broker, authenticating with a DEDICATED wallet (name
ng-eventually-e2e, profile e2e/.playwright-profile-lib — gitignored, separate from
Festipod's). Runner: bun run e2e/run.ts (script test:e2e); not mixed into bun test.

Covers, against the real broker (23 checks, all green): docCreate; sparqlUpdate/
Query anchored default-graph round-trip; readUnion N-doc + per-doc tolerance + cap
gate; doc_subscribe initial+write+unsub and subscribeDocs per-doc isolation; inbox
post/read/watch + spoof guard; discovery submit/read/watchIndex + reserved-account
isolation; store-registry idempotency + bounded listMyEntityDocs + scope resolvers;
caps read-filter (in-memory, honestly scoped); IdentityStore.

Finding (reported, not a failure): on @ng-org/web 0.1.2-alpha.13 an anchored
INSERT DATA { GRAPH <plainNuri> {…} } DOES round-trip (no phantom graph) — several
lib comments assert the opposite; stale, to reconcile. Behaviour is unaffected (the
lib writes the always-safe no-GRAPH default-graph shape). bun test still 91 pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-06 23:55:07 +02:00
..

@ng-eventually/client

Two entry points — the data-plane is SDK-identical, the polyfill bootstrap is separate:

Import Surface
@ng-eventually/client The same signature as the SDK — ng, useShape, inbox (+ types). A drop-in for @ng-org/web / @ng-org/orm; as NextGraph matures it resolves to the real SDK (build alias removed) with no code change.
@ng-eventually/client/polyfill The only non-SDK surface — configure, setCurrentUser, and capability helpers (getCaps, grantRead, canRead/canWrite). It falls away as NextGraph matures.
// bootstrap (the only non-SDK call) — inject the real SDK
import { configure } from "@ng-eventually/client/polyfill";
configure({ ng: realNg, useShape: realUseShape, sharedWallet, currentUser });

// from here on, a pure SDK surface:
import { ng, useShape, inbox } from "@ng-eventually/client";
await ng.doc_create(/* … */);
const set = useShape(MyShape, scope);   // filtered to what the identity may read
await inbox.post(targetInbox, ref);     // deposit (anticipated SDK API)

What the polyfill adds on top of the real SDK (each emulated for now, native as NextGraph matures):

  • Shared-wallet identity (one wallet for everyone; the current identity id is relayed to the SDK).
  • Capability enforcement — a read filter + write guard over emulated grants attached to documents; the app declares a document's read policy and issues directed read grants.
  • Anticipated methods (inbox post, capability ops) with their future-SDK shapes, emulated for now.

Generic: no application domain. The consumer application injects its shapes and performs the acts of granting access. The relationship concept ("who is connected to whom") is the consumer application's own — the client exposes only directed per-document read grants.