@kehto/shell 0.16.2 → 0.16.5

package/README.md

@@ -21,7 +21,7 @@ The primary entry point is `createShellBridge()` — it owns the postMessage lis
 Current draft behaviors this package enforces:
 
 - The shell does not inject a host-provided nostr object into napplets — NIP-5D explicitly forbids napplet-visible signing. Napplets call `relay.publish` / `relay.publishEncrypted` and the shell mediates the signing flow internally (NIP-44 default, NIP-04 opt-in for encrypted envelopes).
-- `injectNappletNamespacePrelude()` implements the current draft NIP-5D injected-domain bootstrap: hosts prepend a `window.napplet` prelude to `srcdoc` outside the verified artifact bytes, so available NAP domain objects exist before napplet-authored scripts run. Assigned namespaces are filtered back to the explicit bare-domain allowlist; the playground does not inject `shell`.
+- `injectNappletNamespacePrelude()` implements the current draft NIP-5D injected-domain bootstrap: hosts prepend a `window.napplet` prelude to `srcdoc` outside the verified artifact bytes, so callable NAP domain interfaces exist before napplet-authored scripts run. Assigned namespaces are filtered back to the explicit bare-domain allowlist; the playground does not inject `shell`.
 - Legacy `window.napplet.shell.supports()` compatibility is not the current NIP-5D availability primitive. New host and napplet availability checks should use injected `window.napplet.<domain>` presence and leave per-domain semantic checks to the matching NAP.
 - Five optional per-domain proxies — `createIdentityProxy`, `createThemeProxy`, `createKeysProxy`, `createMediaProxy`, `createNotifyProxy` — can be composed between napplet and runtime to intercept or augment traffic per NAP. They are NOT wired by default (Kehto's runtime already owns dispatch for the currently supported domains); they exist as host-app composition seams.
 - The keys-forwarder pumps host keydown events into `keys.forward` envelopes for napplets that hold the `keys:forward` capability.
@@ -69,7 +69,7 @@ const bridge = createShellBridge({
 
 ### Shell init
 - `buildShellCapabilities` — construct the current draft `ShellCapabilities` payload emitted during the `shell.ready` / `shell.init` handshake
-- `injectNappletNamespacePrelude` — insert a host-owned NIP-5D `window.napplet` domain-availability prelude into verified HTML before authored scripts
+- `injectNappletNamespacePrelude` — insert a host-owned NIP-5D `window.napplet` callable-domain prelude into verified HTML before authored scripts
 - `renderNappletNamespacePrelude` — render only the bootstrap `<script>` for hosts that already own HTML insertion
 
 ### Domain proxies (NIP-5D composition seams)

package/dist/index.d.ts

@@ -266,17 +266,16 @@ interface UnroutedMessageInfo {
  * `window.napplet.<domain>` presence; this shape remains for older consumers
  * that still read shell.init capability metadata.
  *
- * Per canonical NIP-5D (https://github.com/nostr-protocol/nips/pull/2303/),
- * supports() distinguishes two namespaces:
+ * Current availability is the injected `window.napplet.<domain>` namespace.
+ * Compatibility supports() helpers should treat only NAP domains and protocols
+ * as advertised capabilities:
  *
  *   - Bare names for NAP-capability lookups, resolved against the `naps`
  *     array — e.g. `supports('relay')`, `supports('identity')`.
- *   - The `perm:<permission>` prefix for sandbox-permission lookups, resolved
- *     against the `sandbox` array — e.g. `supports('perm:popups')`,
- *     `supports('perm:modals')`.
  *
- * The two namespaces do not cross: a bare-name lookup never matches a sandbox
- * entry and a `perm:`-prefixed lookup never matches a NAP entry.
+ * The sandbox array remains for older payload readers, but Kehto emits it empty.
+ * NIP-5D no longer blesses additional browser sandbox tokens as interoperability
+ * requirements or napplet-visible capabilities.
  *
  * ## Compatibility NAP-SHELL shape
  *
@@ -289,10 +288,7 @@ interface UnroutedMessageInfo {
  *                                  includes `'NAP-01'`
  *
  * `domains` and `protocols` are emitted as a superset alongside the
- * `naps`/`sandbox` fields for back-compat. The compatibility helper has no
- * special `perm:` logic: `supports('perm:popups')` is an ordinary bare-domain
- * membership check, so Kehto's `perm:`-prefixed sandbox entries are folded into
- * `domains` (empty by default, preserving the default-empty sandbox behavior).
+ * `naps`/`sandbox` fields for back-compat.
  */
 interface ShellCapabilities {
     /**
@@ -301,8 +297,7 @@ interface ShellCapabilities {
      * `'inc'`, `'theme'`, etc. — with the same conditional entries as `naps`
      * (`relay`/`outbox` when a relay pool is wired, `upload`/`intent` under their
      * hooks). Carries NO `inc:NAP-NN` protocol strings (those live in
-     * `protocols`). Any `perm:<x>` sandbox entries are appended here too, since
-     * legacy supports helpers resolve `supports('perm:<x>')` against this list.
+     * `protocols`).
      */
     domains: string[];
     /**
@@ -325,16 +320,11 @@ interface ShellCapabilities {
      */
     naps: string[];
     /**
-     * Sandbox permissions under the `perm:<permission>` namespace. Each entry
-     * MUST begin with the literal prefix `'perm:'` — e.g. `'perm:popups'`,
-     * `'perm:modals'`, `'perm:downloads'`. Napplets call
-     * `shell.supports('perm:<permission>')` to check sandbox entitlements.
+     * Empty compatibility field for older `shell.init` payload consumers.
      *
-     * The `perm:` prefix is what separates sandbox permissions from NAP
-     * capabilities; bare-name entries here violate the NIP-5D contract and will
-     * be unreachable through `supports()` (see the living NIP-5D at
-     * https://github.com/nostr-protocol/nips/pull/2303/). NAP-capability lookups (on `naps`) retain the bare-name
-     * convention and do NOT use the `perm:` prefix.
+     * Current NIP-5D keeps the web sandbox baseline narrow: hosted napplet iframes
+     * use `allow-scripts`, never `allow-same-origin`, and do not receive optional
+     * browser sandbox relaxations as advertised capabilities.
      */
     sandbox: string[];
 }
@@ -1191,42 +1181,37 @@ declare function adaptHooks(shellHooks: ShellAdapter, deps: BrowserDeps): Runtim
  * `link` appended when hooks.link.isAvailable();
  * `common` appended when hooks.common.isAvailable().
  *
- * Sandbox permissions are left empty by default — host apps may extend after
- * construction. Sandbox entries (and any host-app extensions) MUST use the
- * canonical `perm:<permission>` form — e.g. `'perm:popups'`, `'perm:modals'`,
- * `'perm:downloads'`. Napplets rely on the `perm:` prefix to distinguish
- * sandbox permissions from NAP-capability lookups; see the living NIP-5D at
- * https://github.com/nostr-protocol/nips/pull/2303/
+ * The sandbox array is retained as an always-empty compatibility field. Current
+ * NIP-5D defines only the `allow-scripts` baseline and does not make additional
+ * browser sandbox tokens a napplet capability surface.
  *
  * ### domains array + protocols map (compatibility NAP-SHELL)
  * The structured shape older shell capability consumers read:
  *
  *   - `domains` — bare NAP domain names (the `naps` set MINUS the `inc:NAP-NN`
  *     protocol strings) with the same conditional entries (relay/outbox under
- *     `hooks.relayPool`, upload/intent/link/common under their hooks). Any `perm:<x>`
- *     sandbox entries are appended here too — legacy supports helpers resolve
- *     `supports('perm:<x>')` as a plain `domains` membership check.
+ *     `hooks.relayPool`, upload/intent/link/common under their hooks).
  *   - `protocols` — `{ inc: ['NAP-01'..'NAP-06'] }`, derived from
  *     `NAP_INC_PROTOCOLS` by stripping the `inc:` prefix.
  *
  * Emitted as a superset alongside `naps`/`sandbox` for back-compat.
  *
  * @param hooks - The ShellAdapter provided by the host app
- * @returns ShellCapabilities with domains/protocols (compatibility shape) plus
- *          naps (NAP vocab) and sandbox (perm:-prefixed) arrays
+ * @returns ShellCapabilities with domains/protocols (compatibility shape), naps
+ *          (NAP vocab), and an empty sandbox compatibility array
  * @example
  * ```ts
  * const caps = buildShellCapabilities(hooks);
  * // caps.domains => ['relay','outbox','identity','storage','inc','theme','keys','media','notify','config','resource','cvm']
  * //               (relay + outbox present when hooks.relayPool is provided; 'upload'/'intent'
- * //                appended under their hooks; perm:<x> sandbox entries appended when extended)
+ * //                appended under their hooks)
  * // caps.protocols => { inc: ['NAP-01','NAP-02','NAP-03','NAP-04','NAP-05','NAP-06'] }
  * // caps.naps => ['relay','outbox','identity','storage','inc','theme','keys','media','notify','config','resource','cvm',
  * //               'inc:NAP-01','inc:NAP-02','inc:NAP-03','inc:NAP-04','inc:NAP-05','inc:NAP-06']
  * //              (relay + outbox present when hooks.relayPool is provided; 'upload'
  * //               appended when hooks.upload is provided; 'intent' appended when
  * //               hooks.intent.isAvailable() is true)
- * // caps.sandbox => []   // host app may extend with 'perm:popups', etc.
+ * // caps.sandbox => []   // retained for compatibility; not a NAP capability surface
  * ```
  */
 declare function buildShellCapabilities(hooks: ShellAdapter): ShellCapabilities;