@Dominic

then what happens if the peer you are replicating has chosen a different one and you don't have that?

Unavailable message content is something we'd need to handle in any case. It could happen for all kinds of reasons: Garbage collection of rarely accessed messages, or just a server crashing during replication, at a point where metadata has already been transmitted, but (part of the) content has not yet. This is a problem we will face regardless of any message size limit.

You wrote that the message size limit gives "bounds on how much you are committing to when you replicate a feed". Offchain-content can do even better, it lets you chose your own bounds, rather than having to accept the prescribed, arbitrary ones.

To answer that question, we need to experiment - and the nice thing about that particular experiment is that it doesn't mean changing anything that already exists.

Sure, as long as those APIs are clearly marked as experimental and unstable, so we don't force ourselves to support it for backwards compatible. Having to attempt parsing of all blobs and creating indexes if parsing succeeds would be a huge (computationally) commitment.

The whole question of how much of the server-client communication is part of ssb is one we will need to figure out eventually, just like the plugin story. That'll be a lot more effort than the message format changes.