On the People chain, acting as a person is not a normal signed origin. The transaction carries the AsPerson transaction extension with one of the AsPersonInfo variants: AsPersonalAliasWithProof (fresh ring VRF proof plus context), AsPersonalAliasWithAccount (plain signature by a previously bound alias account), AsPersonalIdentityWithProof / WithAccount, and AsPersonalAliasWithAccountRevised for ring revision changes.
Today only native host code can build these (the mobile apps construct them internally, for example when binding the score alias). A product can get the proof itself just fine via createRingVRFProof, but there is no way to put that proof into a transaction with product-sdk-tx, so flows like these are impossible from product code:
- People.set_alias_account, binding a contextual alias to a product account so later transactions can act as the person with a plain signature
- Game.sign_up_with_alias for recognized players
- any call that should run under a person origin instead of an account origin
Ask: support building and submitting transactions that carry the AsPerson extension, taking the RingVRFProof returned by the accounts surface as input, covering at least AsPersonalAliasWithProof and AsPersonalAliasWithAccount, with the message binding rule handled correctly (the proof signs a hash of the call implication, so build order matters).
This is the main missing piece between "the SDK can prove personhood" and "a product can act on it on chain".
No external blockers for the extension building itself: the AsPerson extension and its variants are in the live chain metadata, and the proof input already comes from createRingVRFProof. The key handle variant of the proof call (#289) can slot in later without changing the transaction side.
Part of #286
On the People chain, acting as a person is not a normal signed origin. The transaction carries the AsPerson transaction extension with one of the AsPersonInfo variants: AsPersonalAliasWithProof (fresh ring VRF proof plus context), AsPersonalAliasWithAccount (plain signature by a previously bound alias account), AsPersonalIdentityWithProof / WithAccount, and AsPersonalAliasWithAccountRevised for ring revision changes.
Today only native host code can build these (the mobile apps construct them internally, for example when binding the score alias). A product can get the proof itself just fine via createRingVRFProof, but there is no way to put that proof into a transaction with product-sdk-tx, so flows like these are impossible from product code:
Ask: support building and submitting transactions that carry the AsPerson extension, taking the RingVRFProof returned by the accounts surface as input, covering at least AsPersonalAliasWithProof and AsPersonalAliasWithAccount, with the message binding rule handled correctly (the proof signs a hash of the call implication, so build order matters).
This is the main missing piece between "the SDK can prove personhood" and "a product can act on it on chain".
No external blockers for the extension building itself: the AsPerson extension and its variants are in the live chain metadata, and the proof input already comes from createRingVRFProof. The key handle variant of the proof call (#289) can slot in later without changing the transaction side.
Part of #286