@dominic glad you like it!

re paths: it's the directory in the config. the loader than looks for a bin and manifest.json inside the folder. I chose this but am not ultimatly happy about it since it would also be nice to expose the version of the plugin to the loading sbot. so maybe moving the bin into the main of package.json would make sense overall?

re prefixes: yes, I also think it should happen that way. The manifest/api is already returned like that but I'm not sure where the prefix-stripping should happen. I guess the run.js needs to use a wrapped packet-stream-codec? Though touching that with a mapper on each packet sounds very perf intensive...

another thing I don't really understand from the code I copied from you is this (also in run.js now):

// in practice, the localCall method is created
// from the local api and manifest
function localCall (type, name, args) {
  console.log('CALLED', type, name, args)
  var cb = args.pop()
  cb(null, { okay: true })
}),

I don't know how it fits into the picture, or what its job is in the muxrpc stream construction.

I also made the package npm testable but its not asserting anything yet, just seeing that it can run the example plugin.

I think it would be good to have a plugins2 method to load/reload/kill a plugin on demand, though I think I recall only implementing plugins at startup?

yes, I agree, realoading crashed ones would be nice! From what I've seen, I'm not sure the manifest can be updaed after the inital load?