`host_request_resource_allocation([BulletInAllowance])` is not integrated with People-chain `claim_long_term_storage`

[bkontur]

A product calling requestResourceAllocation([BulletInAllowance]) should ultimately result in a claim_long_term_storage call on People chain

(which then XCMs authorize_account to Bulletin and returns the slotAccountKey to the Host). Today this end-to-end path is not wired: packages/host-container/src/createContainer.ts:435 exposes handleRequestResourceAllocation as a NOT_IMPLEMENTED stub, and nothing in the AP layer (packages/host-papp/) triggers the People-chain claim.

People-chain side of the integration is already in place — see paritytech/individuality#893.

Current Host implementations bypass the v0.2 design entirely:

• useragent-kit signs Bulletin TransactionStorage.store directly with the well-known //Alice dev key — see
  crates/host-chain/src/bulletin.rs:55–84 (submit_preimage_at —
  queries Alice's nonce at line 64, builds the Alice-signed extrinsic via
  build_bulletin_store_extrinsic where the Alice mini-secret is
  hardcoded). The entry point submit_preimage_testnet flags this
  as "intended for testnet/headless provisioning only. Production hosts should route through a real wallet or service account policy."

• dotli never overrides handleRequestResourceAllocation at all — it uses the legacy v0.1 handlePreimageSubmit path at
  packages/ui/src/container.ts:706, which calls
  submitPreimageTransaction(value, getTestSigner()). getTestSigner
  hardcodes //Alice with a TODO: "Replace with production signer (People chain XCM authorization + unsigned submission). For testing on Paseo, Alice's account is pre-authorized via
  authorize_account."

---

Note: this gap was identified via a Claude-assisted cross-repo analysis across the products constellation — truapi, triangle-js-sdks, useragent-kit, dotli, dotns / dotns-sdk, playground-cli / playground-app / host-playground / host-api-test-sdk, triangle-e2e, individuality, polkadot-bulletin-chain.

[bkontur]

At least, I would like confirmation if it is even doable to integrate to claim_long_term_storage from triangle/host

[duewarn]

It should be implemented on Mobile side.
Already supported in Android by https://github.com/paritytech/polkadot-app-android-v2/pull/563, iOS ETA is tomorrow.

[bkontur]

It should be implemented on Mobile side. Already supported in Android by paritytech/polkadot-app-android-v2#563, iOS ETA is tomorrow.

Thank you, what about other triangle parts like desktop?

[duewarn]

Thank you, what about other triangle parts like desktop?

Desktop/dot.li depends on support in Mobile

[Devpen787]

ChopDot reproduced the Desktop side of this gap on 2026-08-11 with a freshly
paired real Polkadot Desktop Dev profile and the Polkadot App.

Environment: Desktop 0.1.2, host-papp 0.8.10,
@parity/product-sdk-host@0.14.1, resolved @parity/truapi@0.5.1, and
@parity/product-sdk-statement-store@0.6.2.

The product called the real StatementStoreAllowance allocation path. Desktop
opened Post statements on your behalf, but Continue produced no mobile
approval and failed with:

Submit failed, no allowance set for account

Desktop then repeatedly logged the same failure from WebRTC transport/signaler
activity. A developer-only probe completed container, identity, and Statement
Store service discovery, then stopped at allowance before publishing a canary
or changing any product money state.

I opened a focused Desktop reproduction at
paritytech/polkadot-desktop-community#29.

Could you confirm which currently distributed Polkadot App versions contain
the Mobile support referenced above, whether Desktop 0.1.2 is expected to
work with them, and the supported recovery path when an already-paired Desktop
session has no usable base Statement Store allowance?