They also have visible half-conversations with a similar number of other people whose tweets are “protected” so that only “confirmed followers” can read them. I don't see OStatus doing anything with the latter, and I don't think those people are going to move to public streams, and if they don't move, the other people interspersed with them won't move because it'll become impossible to talk to them. This is more or less the same reason I still reluctantly keep a LiveJournal: the open-Web facilities for “but only show it to these people” are severely lacking (and I haven't found a good way of doing anything about this yet).
There's also the issue of social networks including things that are de facto currency-like: “number of followers” on Twitter is an obvious one. In a distributed network these usually can be faked, or at least are that way on the UI side since it's hard to generate a UI for that that doesn't drive the user's security-related cognitive load through the roof. (Or reveal more information about subscriptions than people prefer, but that's a shakier reason since some existing networks already reveal that graph.)
Is there any push for OStatus or other distributed social network approaches to handle these use cases? I haven't been able to find any, and OStatus seems to think the restricted stream case is explicitly out of scope.
I personally though would prefer to have the main use case - the one with just public data - work first and learn from that and get that rolling before moving to the more complex stuff.
I'm tempted to compare to how deploying new transport protocols over IP is nearly impossible for consumer clients now, because everyone's built NATs that assume TCP and UDP, because those were the common cases and therefore the important ones and now anything else is instantly hosed. It's a bit of a bad example, though, because in the case of transports there are other reasons as well.
Google Plus seems to have achieved this fairly well. I haven't had the time to take a look at their API yet, but I can't imagine it's any less than what LJ provided.
Here's another one: Dreamwidth runs an LJ-derived codebase, arguably an improved one (they had considerably better separation of “subscribe” and “authorize” last I checked, rather than a “friends list” that conflates these), and some of the people I contact on LJ have moved there, but they all have continuous crossposts back to the original LiveJournal, and if I moved there I think either no one would read anything I wrote, or else the comment streams would be so disjoined that I would be effectively a strange-looking LJ user anyway.
That last is also a concrete example of why nonexclusivity is not a complete solution. The resource that's being fought over is not where one can read but where a bunch of other people do read. If everyone views your content at Phuubaar's House of Crossposts, then if Phuubaar cuts you off, you are still hosed in the general case even if you provide the same stream somewhere else, because those users are not going to know about it or are going to find it too inconvenient to subscribe.
And the tooling around Atom and RSS aggregation all seems to be built around the idea that feeds are almost always public. I haven't had any success with the idea of creating a private Atom feed and expecting any of my friends to be able to read it. Either it'll require authentication, at which point the software usually won't be able to access it, or I can try to use a capability-URL style, at which point one of them will punch it into their favorite everyone-shares-everything social aggregator (Google Reader?) and then my (illusion of) confidentiality is gone.
This is terrible, and I don't know how to fix it.