Event-driven approach

[vovacha]

Problem statement:

After the Event is emitted, there is no possibility to use it afterward. It would help to decouple pallets and reduce code repetition.

Use cases:

• 
Increase experience, reputation, and trust levels after different user actions in the protocol. The Sense pallet will be widely used -> code repetition, tightly coupled pallets.
• Similar to the first. Mint a collectible after some user actions. RMRK/Tangram pallets will be widely used -> code repetition, tightly coupled pallets.
• FRAME Identity was created/updated. It's required to mint a reward for the user as a result -> patching the pallet is required.
• Anything else?

Let's discuss solutions / add use cases.

[vovacha]

The best instrument to solve these problems is a global event listener. But it doesn't exist yet, and probably would require major Substrate architecture changes since the pallet itself has its own namespace by design.


The alternative approaches:

1. 
Asynchronous approach. Message bus (queue) -> off-chain worker -> some Signer calling extrinsics.

   Pros: Chaining possibility.
   

Cons: No determinism in the context of a result block. It doesn't solve the dependencies problem - we should still bring everything to the pallet scope. Increases complexity. Chaining is possible, but so far, I can't see any real use cases for it.



2. Synchronous approach. Something like a public function with match event {}.

   
Pros: It's possible to calculate the Weight. The result is determined by the concrete block number.
 Chaining probably is also possible with some recursion limit.
   
Cons: Similar to the previous - it doesn't solve the problems or solves partially, but brings overhead.


My conclusion: 
I think the best would be to list all the use cases and then decide if it's worth increasing complexity or not.

[2075]

well, it seems like some of the info got lost.

imho the essential information was, to use a pallet as an async process worker based on block time. like this it is

• low complexity,
• non blocking,
• does not require changes to the core,
• is decoupled and
• can access all the relevant scopes if we provide the relevant extrinsic / function to be executed in a portable way.

there is

• prior art in figma: https://www.figma.com/file/jetYJdX81OWKrJAJcknkJr/Module%3A-Event-Bus?node-id=504%3A115
• oudated pseudo code in the original subzero repo: https://github.com/playzero/subzero/tree/dev/modules/rfc