Languages like Erlang/Elixir are super solid because of the way they use mailboxes (among other things). Fabrix is already just extending the base "Emitter" class to give it most of its functionality. There's something to be said about giving each spool and each thread/spool it's own mailbox and in turn it's own address for the spool and the threads that it's using. This will helps fabrix distribute better and opens opportunity for a new class of spools, ones that allow connections between different instances of the core.

Example:

<App Address:uuid> -> <Spool Address:uuid> -> <Method Thread Address:uuid>
<App Address:uuid> -> <Spool Address:uuid> -> <Method Thread Address:uuid>
<App Address:uuid> -> <Spool Address:uuid> -> <Method Thread Address:uuid>

doing app.spools or app.models could resolve where those things actually live and mailbox the requests etc,

Many of these types of small enhancements came up while constructing spool-broadcast, and honestly, it makes sense for a fabrix app to not have to reside on a single machine as a micro service, when it's already so close to being distributed with some slight but significant enhancements.

Using proxies, generators, and async/await, we could also keep everything compatible with the existing ecosystem, but also get the huge benefit of fully distributed applications (that still have perks like using other frameworks inside fabrix).

This could be a v2.0 or a v1.7 feature.