@cinnamon

It requires more network roundtrips to follow the rope all the way back during replication

Who said the network wasn't aware of the rope structure and couldn't deliver the rope from a single request? =D I'm currently exploring this in unrestrained design mode, not bound by SSB's limitations, and this would be totally possible. In the ranges doc of bamboo there's an option for replicating along the shortest path, which is exactly following the lipmaalinks. So then all that remains is to put the state changes into their own log. Whether that would be done through a second log disjunct from the main log, a sub-log, or just a protocol-specific logical thing that the replication layer is aware of, is fairly unimportant. But the targeted complexities are: Send a request of size O(1) ("please give me the rope foo in the range from x to y), receive a response of size O(log(n)), one round trip overall.

A tangent: [...]

I can understand the urge for a per-feed mutable register, but by now I think that the rope approach combined with hierarchical feeds solves this in a nicer way. In general, I'm always very skeptic of "It is inefficient if we do it on every message, but it will be totally fine if we do it every n messages". It still means copying the state data a bunch of times.

Could the replication / access control be integrated into the friend graph information as an aspect of your relationship with someone?

I don't quite understand that question, can you elaborate on this? Conceptually granting access and following somebody are completely orthogonal. UIs might hide this and just have a button that both follows and grants access, but I don't see any reason for complecting these on the technical level.