Interesting idea. Depends on the way you want to implement it. Gossip has some bad issues for using in a social network:
It is slow
It makes information unreliable. When I watch a profile of a user, some of its information might be outdated.
Even smaller pods with only a fistful of users will receive a lot of data they usually don’t need.
But as I said, if implemented nicely these issues gossip could be a nice way of distributing cool information to distant pods. Postings with a lot of likes or reshares could get distributed to otherwise hardly reachable areas of the network.
I don’t like the idea of federating posts any other way than pushing the out as fast as possible where they need to go - if someone is following some particular thing they want the posts when they are made, not when they happen to find their way in.
Saying that, this would be a cool thing to investigate for some other metadata that might need to go around. Since there is a lot of scare here among users of using project resources to make the network grow, maybe some metadata could be gossipped around instead (more complex, slower, but hey it’s decentralized).
But for posts, which are the central thing of a social network, a more direct way is needed.
I don’t suppose you dislike your own proposal. But I asked about mine, which apparently is not clear enough, because nobody is able to comment it. Is there anything I could explain about it?
commenting on the initial gossip idea: we really don’t want to have complete synchronization amongst servers, in our system information is (and should be) sent around in a need-to-know basis.
Personally I think we might get pretty decent results with a well-planned fetch component for public posts - which would be comparatively easy to implement.