@keks with this api, it would be easy to implement either pattern.

in pseudojavascript:

return {
  //named this method mountRemote so as not to confuse it with local `mount` method
  mountRemote: function (name) {
    //remote id
    var id = this.id
    //get locally held reference to remote rpc
    var _rpc = sbot.peers[id][0] 
    rpc.mount(name, function (type, name, args) {
      return getPath(_rpc, name).apply(null, args)
    })
  }
}

I disagree that putting the plugin loader be out of "core" makes the small core, because the plugin loader is something that everything interacts with. It is the core. The smallest core possible would be muxrpc server + plugin loader, everything else, including gossip, replication, and database could be loaded as plugins. (although some would need to be in-process maybe)

I dislike the model of plugins managing their own connection, because it is not possible for the trusted core to strongly identify a plugin, and thus it's not possible to have a semi-untrusted plugin. If you wanted to restrict what methods a plugin can access, the plugin could just claim to be a different plugin when it calls the server. But if the core controls actually running the plugin, it can statically identify it, decide what permissions it has (both to RPC and OS).

fs.readFile(path.join(path_to_plugin, 'manifest.json'), 'utf8', function (err, val){
  var manifest = JSON.parse(val)
  var proc = child_process.spawn(path_to_plugin)
  var rpc = MuxRpc(manifest, sbot.manifest())(sbot)
  //XXX oops! not how I proposed it initially!
  sbot.mount(name, function (type, name, args) {
    rpc.remote(type, name, args)
  })
  pull(toPull.source(proc.stdout), rpc.createStream(), toPull.sink(proc.stdin))
  proc.on('close', function () {
    //restart after delay?
  })
}

hmm, okay this made me realize that my initial proposal was insufficient. Probably I'll need to refactor muxrpc so that you can insert things into the localCall method that the stream holds.