@keks okay, lets focus in on the part that I think we agree about, then cycle back around to the question of how the plugins become connected to the system.

subproposal: muxrpc api exposes a "mount" method on the local object (local, meaning: not over rpc), the signature for mount would be mount(name, pluginCall). and pluginCall has the signature pluginCall(type, name, args) (note: name is an array, because methods can be nested) This is the same signature as used internally by muxrpc to make local calls and remote calls. normally, a remote call comes in to muxrpc, and that becomes a call on the local api and the name is used to look up the particular method to call. in the case of a call of a remote mounted method, the call message would just be proxied into the mounted rpc with the first part of the name removed.

Note: in this design, there may be many client/peer connections, but plugins always have a single connection to sbot. plugins cannot see events emitted on sbot, or which client/peer made a particular call. I think this is okay for now. It still gives us quite a bit to work with, and a range of plugins (such as various database indexes) don't need that anyway.

The above proposal is intended to clarify how one might proceed with an implementation, without making a final decision wether to connect plugins via stdio or unix socket. stdio seems really easy to me (having played around with that sort of stuff before) so would be happy to create a demo of that, if the above proposal is agreed.