@Piet looking good! My feedback is coming from a "blurred" vision of all these modules (just giving some context, that I don't have a perfect assessment of the situation), so one question I have is: how are you going to stop ssb-friends from calling replicate? These lines https://github.com/ssbc/ssb-friends/blob/173bf283c5a58a266026c813f7df62cd9f9605a4/index.js#L115-L123

In my opinion, gossip & replicate & ssb-friends & ssb-ebt is a mess, and would hope you could untangle some of that mess. E.g. it would be good if ssb-friends was passive: it only answers questions, it doesn't proactively do something. Because that's its actual promise: "the logic around who to replicate or not", but those lines are doing much more than just being the logic around who to replicate, they are also actively asking for replication.

I still want to update the https://github.com/ssbc/stack-diagram so that it reflects this entanglement between gossip & replicate & ssb-friends & ssb-ebt so we get a better understanding of it, but as inspiration (not request), I wish it would be:

Layer 1:

• connection-manager (stores a list of connectable peers, passively pauses/resumes, proactively chooses who to connect to)
• ssb-friends rewritten a bit (passively answers questions like isFollowing & isBlocking & hops streams)
• ssb-replicate-simple (a rewrite of the current sbot/plugins/replicate)
• ssb-replicate-ebt (I just noticed ssb-ebt and sbot/plugins/replicate are basically mutually exclusive! the former fallbacks to the latter)

Layer 2:

• replication-manager (roughly like you sketched, but it allows choosing between ssb-replicate-simple or ssb-replicate-ebt, and does this logic which is also configurable whether we first loop over hops=1 then hops=2, or whether we mix all hops together)

The reason I'm thinking in layers is that it would solve some of the entanglement between these modules. In principle, Layer 1 modules should not assume the existence of other modules in Layer 1, they only have access to Layer 0 modules (e.g. secure-scuttlebutt, multiserver, ssb-config, etc). Then, Layer 2 modules assume the existence of Layer 1 modules and mix and match their APIs. In other words, 1 is local tactics, 2 is strategic. Then UI apps can just communicate with Layer 2 modules and do operations like: configure the replication strategy, start/stop, query the progress. I don't think much more is needed in the API of a high level module like that.

Anyway, probably more feedback than you needed. I don't know how much of all of this is doable in this quest, but the more clear our goal is, the better we can know whether what we're doing is valuable and useful in the long term. It seems like a good action plan would be to start rewriting Layer 1 modules first.