Fair enough, the microservice comparison is justified, and I agree that ssb would not really benefit from it. To give a short background on where the idea of plugins running on different machines comes from:

Servers need to connect to other servers, so some part of the protocol will end up to be network-aware in any case. There will be something like multi-addr or multiserver addresses to handle connections. But if we already have that, why arbitrarily restrict plugins to only a subset of those connection modes? That's actually the more complex way to go, not the simpler one. This argument does start to crack once you take a closer look at things. For example it would be very simple to implement an optimization where two local plugins communicate directly via a unix domain socket, but connections between remote plugins could become tricky (NATs etc). So remote plugins are not something I absolutely insist one. I've just been considering the most general setting, so that's why they still appear in later posts.

I fully agree that in a setting where the server has more control (enforcing sandboxing, etc.), it makes sense to distinguish between plugins running on the same machine or not. But in the most general setting, the protocol does not need to care about that.

I can't really think of uses of ssb plugins that would warrant that.

Thin clients come to mind. If clients are actually plugins (and I'm pretty convinced that that is the right way to go, or at least the cleaner solution), then the ability to e.g. run patchfoo on a resource-constrained device while connecting to a more powerful server over wlan would be lost if plugins are forced to be local processes.

Another use-case is something like a really index-heavy plugin (e.g. full-text search over large ssb datasets), or a computationally expensive one. It may make sense to host those on a dedicated server, possibly exposing them to multiple users.

In any case, these could just run a local plugin which then talks to the remote endpoint in whatever way it sees fit, outside the scope of the plugin architecture. That would require asking the sandboxing mechanism for permission, so it involves some complications, but it isn't unsolvable. So these situations are not really sufficient arguments against making plugins local-only.

So overall, I'm open about restricting the scope of this. I'd still like to explore server-to-server connections in the general setting though, before doing so.

@Dominic, I'm curious about your opinion on clients being nothing but plugins that don't expose an API. That's a pretty fundamental decision, especially if plugin-startup ends up being managed centrally.