Products currently need to know their own DotNsIdentifier to call APIs such as host_account_get, where ProductAccountId = (DotNsIdentifier, DerivationIndex). The host already knows the calling product's identity for scoping permissions, entropy, storage, and allowances, but there does not appear to be a product-facing way for the sandbox to learn the dotNS name it was actually deployed under.
This creates a mismatch: a product bundle may be deployed under different dotNS names, but account derivation and product-scoped APIs depend on the canonical deployed name, not a hardcoded value inside the product.
Relevant references:
docs/design/host-api-protocol.md defines host_handshake as only returning Result<(), HandshakeErr>.
src/data/v02/types.ts documents host_account_get as requiring the product to provide ProductAccountId.
src/data/v02/types.ts defines DotNsIdentifier.
Proposal:
Add a product-facing way to get the runtime product identity, for example:
type ProductIdentity = Struct({
dotNsId: DotNsIdentifier,
});
fn host_product_identity_get() -> Result<ProductIdentity, GenericErr>;
Alternatively, include this in the successful handshake response.
Expected behavior:
- The value is supplied by the host from the deployed/resolved product identity.
- It matches the identity used by the host for product-scoped permissions, entropy derivation, local storage namespacing, product accounts, and allowance scoping.
- It is available after handshake and does not require user authentication, since it reveals the product's own identity rather than user data.
- Product SDKs expose a simple helper, e.g.
truApi.getProductIdentity() or truApi.getProductDotNsId().
Acceptance criteria:
- Spec types and docs define how a product obtains its deployed dotNS identifier.
- SDK exposes the value to products.
- Host implementations return the deployed dotNS name used for scoping.
- Product account examples no longer require hardcoding
"my-product.dot" when the product wants its own account.
Products currently need to know their own
DotNsIdentifierto call APIs such ashost_account_get, whereProductAccountId = (DotNsIdentifier, DerivationIndex). The host already knows the calling product's identity for scoping permissions, entropy, storage, and allowances, but there does not appear to be a product-facing way for the sandbox to learn the dotNS name it was actually deployed under.This creates a mismatch: a product bundle may be deployed under different dotNS names, but account derivation and product-scoped APIs depend on the canonical deployed name, not a hardcoded value inside the product.
Relevant references:
docs/design/host-api-protocol.mddefineshost_handshakeas only returningResult<(), HandshakeErr>.src/data/v02/types.tsdocumentshost_account_getas requiring the product to provideProductAccountId.src/data/v02/types.tsdefinesDotNsIdentifier.Proposal:
Add a product-facing way to get the runtime product identity, for example:
Alternatively, include this in the successful handshake response.
Expected behavior:
truApi.getProductIdentity()ortruApi.getProductDotNsId().Acceptance criteria:
"my-product.dot"when the product wants its own account.