@Piet

The merkel tree seems like a really beautiful idea.

Yeah, binary trees are magical.

I particularly agree with @Dominic's point:

the context and meaning of later messages is some times related to earlier messages ... what sort of impact does that have on the application? what kind of applications works with this, or is broken by this?

That's definitely something application designers need to consider, yes. But we'd be giving them more options, not constraining them. An application would choose whether it wants self-contained messages (working with arbitrarily chopped-up feeds), or whether it wants to perform reductions over multiple messages into a single piece of application state (à la event-sourcing). The latter case would break.

But it is possible for applications to get the best of both worlds: Any message that relies on previous messages can link to them, and the application can then instruct the server to (transitively if necessary) fetch those via merkle-ooo. But in any case, all of that is part of the application layer, not the protocol layer. (CC @Dominic)

Now that I think about it, making these event-sourcing-backlinks part of the protocol would save a bunch of roundtrips. Hmm... (I don't think that's goinging to be a good idea, but it's one to consider nonetheless)

As for older applications: I'm not aware of any current client that uses event-sourcing accross multiple message types, so a partial feed subscription mechanism like the type-prefix based one should be sufficient to prevent any breakage. And the type-prefix solution also allows events-sourcing accross different message types authored by the same application if they share a common namespace (e.g. the fictional "chess.move" and "chess.annotate") messages. That's a simple middleground where you can assume that the clients have the full log and can thus do event sourcing without any explicit backlinks, yet disinterested clients don't need to download the full feed.

I'm trying to find the killer real world pain in ssb we can solve that justifies the implementation and increase in complexity throughout the stack.

To me, "ooo introduces messages with second-class security guarantees" is more of a "killer real world pain" than any kind of application you could come up with. But then again, I may have a non-standard view of what constitutes "real world" concerns.

The ooo security guarantees are what led me down this rabbit-hole, partially subscribable feeds were just a byproduct. But I guess it easier to lobby for those. The all-or-nothing approach of current ssb may be the last part of the protocol that doesn't scale well. But again, I feel like that might not be "real worldy" enough for everybody. So I guess someone else should do the marketing =D