So, I continued that rewrite, then realized I had a fundamental error: when I added same-as support, the code became order dependant! If your same-as device blocked someone, it might still include their friends. This is not what I wanted. Yeah, so I'm not having much fun working on this... It's been 4 months since I started user-invites. I havn't just been working on this, so I have made progress with other things, I guess that is a consolation.

The approach I had been using was to expand the traversal from the starting point (your main identity) to each reachable feed in a width first traversal. In the original where this worked, each expansion added 1 to the hop count of a feed.
It also represented the block distance: the hop count of the feed that blocked. This worked because it always expanded closer feeds first. But when I added same-as support, in certain situations, such as chained same-as, you could have a feed that was actually closer (because of same-as) expanded after a more distant one.

One idea would be to expand the feeds in the order of their hop count, but I decided to try another design first: keep another data structure representing the reverse follow graph: who is followed by who, so that when an edge is added (or removed) from a peer, you can just recalculate their weight. I think this might work, but need to build my intuitions about it by implementing and testing it.