Enable a mechanism (e.g. a tag) that specifies which pubkeys are allowed to make the next transition. This may need to be partially defined in the state machine itself as a parameter. Think for example a game of chess; the state machine defines two pubkeys as players and which one goes first (white player). By allowing the state to only be changed by a pre-defined pubkey(s), you simplify possible forking and can remove the need for custodians in some state machines.
This primarily only works for well-defined state machines that follow a well-defined flows (such as turn-based games, legal contexts, etc).
Thank you for your suggestion. Currently, the way the spec can handle these situations is within the context of the state machine itself, I though not specifying other conventions makes the spec more versatile. All public keys (pubkeys) that can participate and their respective roles should be part of the context to determine if a transition is legal or to identify the next participant. For example, consider the chess game modeled as a state machine from your example, that allows for playerA and playerB to be defined. When the state machine definition event is published, the pubkeys of both participants are included in the context. This information is sufficient to determine who can play and in what order. In this case, playerA will start, and if playerB tries to send a transition event, no state change will occur since only playerA is allowed to start. This is enforced by a guard, which is also defined in the state machine definition event and supported by 'engine' tags. These tags define the dependencies from which the guard originates.
Does this approach sound good to you, or was your comment more about notifications for the participants?
On the other hand, for dynamic state machines where the number of participants is not known in advance or the number of them is not fixed the same approach still valid. Instead of defining each participant's pubkey in a separate field of the context, you could have a 'participants' field which contains an object with a key-value structure with field and pubkey values that can grow dynamically.
Yes, this makes sense to me. I guess it could be the initial state / context of the state machine that defines who the participants are and any ordering.