Bot core receives stream of events; steps through them in turn
Bot has lots of model objects, each one registers itself with a type identifier (eg. m.room.message), corresponding to event types.
Bot core simply palms the event to all handlers of the relevant kind. They can then return a "processed event". Bot core will add that to the event queue.
Separate loop of the bot will pull events out of the queue and fire them. By default they'll do nothing, the outer layer can register handlers (and request a list of handlers, to make it easier to manage removing).
Can also add filters/splitters, a special kind of handler that will return new events to be fired; can be used for making up internal event types, eg. a splitter that looks at the first word in the message and fires an event of that type, to make a command handler.
The whole bot will be synchronous. However, all network/disk/DB/etc., basically all external, will just create a task and push it into a separate work queue which will fire off at maximum possible rate. Try to avoid making get calls.
Raw events will not be exposed, only processed events. This is not a "you have full control" framework. This is a clean, unified, easy-to-use framework.
Main chat lib defines API - is NOT a class, the module itself is a singleton
Specific proto libs are classes, instansiate with the module + account info, it'll hook itself into the module. For convenience, if the module isn't provided they'll do it themselves, and provide a .run() wrapper. If that's used with a provided module (set a flag), they emit a warning.
