@piet I don't know which of those it is, it's a suggestion (and a thought that occurred to me previously). The point is to see how you react, and thus extract more context about how you are thinking about the problem. That this suggestion has fallen somewhat flat actually tells me quite a lot - the way you were approaching the problem was quite different. Of course, you were approaching the problem the obvious way, to you but I don't know how that differs from my way, and neither do you. So I just suggest things and see how you react.

Another piece of essential context: ebt/replication is the heart of ssb, I want it to be really really good. If you can't do what you need with my api, there is two basic possibilities: either A) there is a better way to do the thing you are trying to do, that may be easy for me to point out, given my deeper understanding of the code, or B) I didn't anticipate your needs, and thus implemented the wrong interface, and so the code should change.

I wouldn't say it's a playful musing though, it's more like:

• here is a suggestion that would be straightforward to add to the ebt code, would it solve your problem?

and the answer seems to be "no, I actually have a different problem". I hadn't actually considered using the number of messages you expect to receive as the prioritization. And that leads me to more questions:

• what happens if someone new comes into replication scope, and they have a massive feedL (they are newly a foaf, does it skip updates from close friends to pull that down?)
• to know someone is far ahead, you'd need to receive the remote request, so you'd need to ask for that feed, but you'd need to ask for it in pull mode (rather than push mode), which isn't currently accessable but could be an easy PR to epidemic-broadcast-trees.