Two products are building on People chain personhood right now: humanity-spa and dim2-spa (Jollity). Both need the same things from the SDK, and both currently either hand-roll them or cannot express them at all from product code.
The Humanity team has proposed solving part of this with dedicated host calls instead: https://github.com/paritytech/humanity-spa/blob/develop/host-extensions.md. That approach would weld product domain logic (membership state, game phases, prize claims) into every host, so each rules change becomes a host release on four platforms. It is the same coupling problem RFC-0024 is currently removing for personhood keys. Everything in that document decomposes into a small set of SDK primitives plus typed domain helpers, which would work on any host and can be shared between Humanity and Jollity.
Goal of this tracker: everything listed in host-extensions.md should be expressible product-side through product-sdk.
Rough dependency order: 287 and 288 are standalone. 289 waits on the truapi JS client shipping the RFC-0024 wire methods. 290 needs proofs from the accounts surface but the extension building itself can start from the chain metadata. 291 builds on all of the above.
Context on host support: Android merged RFC-0024 natively (paritytech/polkadot-app-android-v2#969), the shared Rust core implementation is in review (paritytech/host-rust-core#360), desktop has an implementation branch, and the JS client bindings do not exist yet. The manifest RFC (paritytech/host-rust-core#206) is still open, so cross product proof allowlisting cannot be expressed yet. Details in the individual issues.
Two products are building on People chain personhood right now: humanity-spa and dim2-spa (Jollity). Both need the same things from the SDK, and both currently either hand-roll them or cannot express them at all from product code.
The Humanity team has proposed solving part of this with dedicated host calls instead: https://github.com/paritytech/humanity-spa/blob/develop/host-extensions.md. That approach would weld product domain logic (membership state, game phases, prize claims) into every host, so each rules change becomes a host release on four platforms. It is the same coupling problem RFC-0024 is currently removing for personhood keys. Everything in that document decomposes into a small set of SDK primitives plus typed domain helpers, which would work on any host and can be shared between Humanity and Jollity.
Goal of this tracker: everything listed in host-extensions.md should be expressible product-side through product-sdk.
Rough dependency order: 287 and 288 are standalone. 289 waits on the truapi JS client shipping the RFC-0024 wire methods. 290 needs proofs from the accounts surface but the extension building itself can start from the chain metadata. 291 builds on all of the above.
Context on host support: Android merged RFC-0024 natively (paritytech/polkadot-app-android-v2#969), the shared Rust core implementation is in review (paritytech/host-rust-core#360), desktop has an implementation branch, and the JS client bindings do not exist yet. The manifest RFC (paritytech/host-rust-core#206) is still open, so cross product proof allowlisting cannot be expressed yet. Details in the individual issues.