having now read this, some notes:

• sbot already provides a manifest method, which is your 'listCommands'.

• I'm with keks on keeping-in-mind need for in-process plugins, at least from the point of view of a specific runtime. separate-process plugins would nearly always work in-process, but not always the other way. Applying long-ago java experience, if the implementation style for a plugin was to implement in-process style, then wrap it with a muxrpc thing, it should be easy.

• indexing: you could have a indexer plugin that other plugins requested indexes from, and you could have a convention that allowed a query module to make use of indexes provided by a query plugin. I think these are both good ideas, not mutually exclusive.

But my most important point:

• instead of a server with unix socket, I recommend sbot manages plugins as child processes, and communicates with them via stdio. This means a trusted core has control over what plugin should be providing what, and I think this will set the ground-work for a really good security architecture later.