It's typical for developers to rely on Flow.ourIdentity or (FlowStateMachine.ourIdentity if you like) for a consistent result in regards to the initiating identity. This may seem trivial but in practice provides an implicit identity context to a flow and all subflows or other components used during execution of it's FlowLogic.call.
My question is, how could an app-specific implementation/initialization in FlowLogic reliably "store" an AccountInfo (or PublicKey, or AnonymousParty) object to provide a similar context and API for all code within a FlowLogic.call stack?
It's typical for developers to rely on
Flow.ourIdentity
or (FlowStateMachine.ourIdentity
if you like) for a consistent result in regards to the initiating identity. This may seem trivial but in practice provides an implicit identity context to a flow and all subflows or other components used during execution of it'sFlowLogic.call
.My question is, how could an app-specific implementation/initialization in
FlowLogic
reliably "store" anAccountInfo
(orPublicKey
, orAnonymousParty
) object to provide a similar context and API for all code within aFlowLogic.call
stack?