Yeah, you're right. I was considering alternatives, where, e.g. we have dedicated hooks for each protocol, or context providers, but that moves the complexity to another place instead of getting rid of it. Also it can cause some performance issues, because such hooks / contexts would have a lot of dependencies, which can cause unnecessary renders.

Compared to the alternatives, the proposed solution feels like a good tradeoff, but if you have some other ideas, it would be great!

This is something I mentioned briefly in the description The only changes were about moving some types around and earlier in the stack. Moving the logic around causes import cycles that lead to e.g. broken tests. I hoped to work around these, but it seems with every diff I'm introducing new hacks. I'm considering a more general solution - the main problem is that our actions.js files mix types, constants, and hooks. We should probably split these.

Yes, splitting sounds like a good solution, that's usually how I solve import cycles.

It seems like there's a way of simplifying it. In the message spec, we're defining useCreationSideEffectsFunc - so it is possible to define a hook within the spec. We could do something similar here. By doing this, we would avoid providing unnecessary utils to all the protocols. For now, I think we can continue with the existing pattern, but later we should simplify it.