@cft Thanks for the feedback =)

Wow, quite a complex thing

No, it really shouldn't be, that's why I am so unhappy with the presentation =/. The system is actually rather simple, you set up ranges and then transmit log data from oldest to newest. But then there are tons of details, it becomes hard to see the forest in between all those trees. Having to distinguish between metadata and payloads, allowing to skip over some but not all things, correctly handling concurrent actions, these things add up. It's not that any of these are complex to handle, there's usually one obvious solution. But spelling it all out makes it look like a lot is going on. And to be honest, I just wanted to get this thing out there because it has taken so much time to spell out all the details...

Can you add some high-level introduction and definitions?

Those are supposed to be defined in the bamboo spec. Which I'm currently rewriting, so I can't link to those definitions just yet. An actionable takeaway here for me is that I'll add a glossary at some point.

Also, it seems that you have “standing proposals” - maybe we could and should call them “subscriptions” then?

Yes, I'm unhappy with the terminology as well. I did a last-minute change away from more standard terminology ("query", "request", "subscription"), because I want to convey that these things are fundamentally bidirectional. Once two endpoints have established that they both care about some feed starting at a certain point, then any of them can push data to the other once it becomes available. That's why I chose "synchronizing" rather than "serving" or "replicating". Perhaps "equalizing" would be another choice. Or simply "sharing"? "Merging" or "joining" in the sense of lattice operations (the whole thing can be seen as computing the join over the two data sets of the endpoints)? "Jointly advancing the knowledge frontier" seems a bit heavy-handed. But I agree that calling this point-of-synchronization-thing a "proposal" even after it had been confirmed is confusing.