Tomorrow I'll begin with the #sunrise-choir work, and I'll start out with message formats. So I'll stop exploring the plugin design space for now, but here is a list of open question any solution we'll come up will have to answer:

• are plugins and clients the same?
• can plugins run on different machines?
• should a plugin know the name of another plugin that initiated a connection to it?
• who gets to start connections to other servers? Who gets to close them?
• can plugins run any protocol they like, or do we enforce some sort of muxrpc-like protocol?
• how does automatic plugin lifecycle management work?
• which plugins are allowed to talk to each other?
• what are the cross-platform IO capabilities?
• how do we grant access to the ssb database (capability-wise)?
• which core rpcs are there (gossip, replication, database reads, database writes, blobs, private messages, where does it stop?)?

A few of these are not directly related to plugin management (such as deciding on capabilities and the core ssb server functionality), but they depend on each other enough that we'll likely need to introduce them at the same time. All the message encoding stuff is fairly independent, but rpc protocols, plugins and core ssb functionality are interdependent. Reaching consensus on how to do all of these at once, will likely be the most difficult step in what the sunrise choir set out to do. But also one of the more worthwhile ones, since that is what we need so that clients can code against a spec rather than (j)sbot.