## sbot process plugins protocol

This is a proposal for a protocol to run plugins as a separate process.

## secure proposal

This is called the "secure" proposal because it is a step towards a secure sandbox design,
but restricting plugins from accessing files or the network is currently not in scope.
but details of apis provided etc are carefully controlled and known, such that this may be extended in the future.

sbot is provided with an executable path, and a manifest.

`sbot.plugins.start ({path: executable, name: string, permissions: perms}, cb)`

sbot expects to find a manifest file at `path.join(path.basename(executable), "manifest.json")`
and will run the process with cwd as `~/.ssb/plugins/{name}` (possible extention: prevent plugins accessing files outside of this). The methods described in the plugin's manifest will be accessible
from sbot's rpc prefixed with the plugin name (as with the current in-process plugins)

The plugin is connected only to the sbot, and may call methods exposed over rpc by sbot.
external access to the methods exposed by the plugin are restricted by the permissions object.
(this is the same format as the current muxrpc permissions used by in-process plugins. `{<role>:{allow:[...]?}` where <role> is "anonymous" if any remote peer is able to access that api.)

(possible extention: restrict access to the local sbot's methods via a similar option, but
this is not relavant until the ability to prevent a plugin from accessing the network and filesystem
is implemented)

Note: the permissions and name are passed directly to the sbot method that starts the plugin, and the manifest is a static file. the plugin must theirfore provide their apis statically, and cannot change their apis. This makes it possible to reason about what has access to what once full sandboxing is implemented.

The plugin provides it's methods directly over muxrpc over stdio without it's name prefixed,
but sbot reroutes calls of that name to the plugin. There is therefore no special muxrpc methods to be added, apart from plugins.start

## insecure proposal

The insecure proposal is intended to be easier to implement, probably easier for development, and enough for now. in the insecure proposal, a plugin is a fully separate process (not a child process)
sbot exposes a local muxrpc server unencrypted on a unix socket at `~/.ssb/.socket`. support for insecure plugins must be enabled specifically via a config setting (Q: bikeshed what setting?). After startup,
plugins connect to that socket, then call `plugins.mount ({name: name, manifest: manifest, permissions: permissions})`. (which mounts the calling connection at {name}). As with secure plugins, insecure plugins can call local methods (incuding other plugins). If the plugin does not call `plugins.mount` it will be treated as a client only. It can still call local methods but not does not provide any.