spec for out-of-process plugins

I started on a more well defined spec for plugins as discussed with @keks and @cryptix

https://hackmd.io/5MWu8qlnRnakrz4IaDcaNQ

I've tried to make it as specific as possible. Also, very relavant to @cel's ssb in C grant proposal

thoughts and comments please!

Here is the previous thread for reference & consistency: %oxtXLx0...

( just in case: oop-plugins-padsnap.md )

@dominic @keks @cryptix
Sounds good. One issue I am wondering about is how information about the server and/or peers will get passed to the plugins. If a plugin exposes a public method and a peer calls it, can the plugin know the peer's address/id? The ebt plugin, for example, uses this. Currently it is shared by putting a id property on the RPC object which is in the same process. Some methods don't need this information; are there benefits to not giving plugins this information?

Can plugins get notified when peers connect or disconnect?

A plugin may want to read the sbot config which currently plugins get for free in the init method. I guess a plugin in a separate filesystem could just use the filesystem, or load the ssb-config module on its own, or maybe a call a config plugin to get/set properties. Or maybe the plugin loader will already have loaded ssb-config, to figure out what path to connect to the RPC file at (if using the insecure proposal)

Can a plugin call methods on a peer? Have a core method to proxy calls to peers? Then peer connections need an identifier other than just the id, since there may be multiple connections per id.