Sylvain Duchesne
88d96857fb
Model the read filter on NextGraph's real ReadCap mechanism instead of an invented per-item grant. Verified in nextgraph-rs: there is no Document type (document = repo); a store is a container repo referencing other repos by RDF overlay; holding a store's cap does NOT grant the repos it contains (each repo needs its own cap; no read-cap inheritance). So the access unit is the DOCUMENT = an item's `@graph`, never the item. - caps.ts: CapRegistry (read/write caps per document NURI + public docs; open/grantRead/grantWrite/makePublic/canRead/canWrite/governsRead/ hasReadPolicy). Replaces access.ts (Grant). - read-filter.ts: filter keeps an item iff its `@graph` document is readable (held cap or public); items with no `@graph` or in an ungoverned document are kept. No injected grantOf — the filter reads `@graph` and consults the registry (automatic, domain-agnostic). - polyfill.ts: getCaps()/resetCaps() replace setGrantOf/getGrantOf; useShape filters only when caps.hasReadPolicy() (else passthrough, no regression). - tests: caps.test.ts (6) + read-filter.test.ts (4), incl. no-inheritance between documents. 10 pass; tsc rc=0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ng-eventually
A generic polyfill layer over the NextGraph JS SDK.
NextGraph's JS SDK does not yet expose cross-wallet reads, capabilities, inboxes
or group stores. ng-eventually lets an app behave as if those existed today, by
emulating them on top of a single shared wallet / broker. It is generic:
it contains no application domain — the consumer injects its shapes and the
acts of granting access.
The name: eventually NextGraph will ship these features; until then this layer fills the gap (and nods at eventual consistency / events).
Packages
| Package | Role | At migration |
|---|---|---|
@ng-eventually/client |
SDK-identical wrapper the app imports instead of @ng-org/web / @ng-org/orm. Adds the polyfills the broker/verifier will do natively (shared-wallet login, capability enforcement, anticipated cap/inbox methods). |
Disappears: the app points back at the real SDK (build alias removed). |
A global-index curator package is deferred. NextGraph is mono-user with no global data (apps/services see only what the user shares; there is no multi-user backend). A global index would come from a singleton app (a global document administered by the developer) — not implemented and uncertain, and simpler paths may exist. So no second package for now; it will be (re)introduced once the global-index mechanism is decided. The curator must never be bundled in the client → it will be a separate package when it lands.
Design principle
The application code is written as if the target NextGraph existed. All compensation lives here, beside the app. Migration = remove this layer; the app code (SDK-shaped) is unchanged.
- SDK-identical surface: the client wraps the real
ng(a Proxy that forwards everything and overrides only what must be emulated) anduseShape. The real SDK is injected viaconfigure()(no hard import → build-alias safe + testable). - Authorization = emulated capabilities: documents carry grants; the client enforces them generically (read filter + write guard). The app attaches grants via cap operations — same as it will in the target. No policy is injected.
- Inbox: the client
inbox.post()deposits; materialization (the curator) is deferred with the global-index mechanism — see the note above. - Tests of the polyfill (against a real broker) live in this repo, so the consuming app can test its features against a mocked, clean API.
Status
Scaffold. Mechanisms are stubbed with TODO(broker) / TODO(polyfill) where
real NextGraph wiring is required.