I've been mulling this over a lot, and I feel like my thoughts are slowly converging on a coherent proposal, but that'll take some more time to write up. For now, just more notes to self.

It's hard to limit the scope of this plugin platform, there's the temptation to stay completely unopinionated yet provide all the useful features. Libp2p is a cautionary example in that regard. Reading the website, it looks like the silver bullet that solves all problems. Until you dive into the spec and see all the open problems, partially or underspecified aspects, the bloat (why is there a pubsub service on this protocol layer, isn't this the protocol that pubsub should be built upon?), things marked as TODO, etc.

A realistic, actionable proposal will need to make a few opinionated choices about which use-cases are out of scope, to keep things manageable. I think direct connections between plugins won't actually make it, as these come with a lot of baggage. Different pubkeys per plugin might be ok, I think, but I'm not sure yet (the more restrictive approach would be that each plugin must have the same pubkey as its corresponding server).

And finally there's the question of how much the plugin-server should be aware of connecting to other plugin-servers. There's a few approaches here:

• Don't specify this at all, resulting in a plugin architecture not tied to p2p systems in any way - p2p functionality would be given by plugins.
• Transparently handle p2p connections, maybe giving plugins the ability to adjust parameters. This is the easiest one for plugins, but the most restrictive/opinionated way to go.
• Give an opaque set of primitives for connection establishment and address sharing to plugins, but leave it to them how they use those

I'm currently leaning towards the first or third option, but haven't made up my mind. Either of those three would be suitable for ssb, it's just a question of where to place the inherent complexity, and how much complexity to shave off by reducing flexibility.