We already have a split and fragmented network due to the rampant site blocks. I will only suggest that on a system built around permissions, this is rarely needed and users are able to filter what they see at the edge as you suggest. I’ve only blocked 3 individuals over the course of 11 years and have never blocked a site. This doesn’t mean I’m overly tolerant - I’m not. But permissions do all the dirty work of keeping foul-mouthed strangers out of my timeline. The only place they sneak in is occasionally through public groups where we are both members. Then we pull out “superblock” which implements “make this person vanish from my life”.
I believe Mastodon and Pleroma both provide activities of type Block or Flag or possibly both, but these typically are only shared with and amongst admins. There’s is no technical reason why you couldn’t share such activities with your followers and let them make use of (or perhaps ignore) these activities rather than just restricting this ability to admins. I would have built such a “block together” functionality already using these activities (it isn’t rocket science and the protocol supports it) - but my projects don’t actually need it.
Diaspora’s aspects is just a fancy name for mailing lists. They don’t provide or enforce any permissions per se, they just restrict posts in the current stream view and set the post audience to those in the given list. My own fediverse history pre-dates Diaspora slightly and we’ve been providing fine grained permission control since about 2010 and the full permissions framework was completed around 2012. We used Facebook’s permissions as a usage model initially, but have since gone beyond that. This lets you decide who can send you their posts and comments, who can comment on your own posts, who can see your friends and followers or even the relevant totals, who can access your posts and who can access your photo albums and personal cloud storage resources. This list of rights is extensible so when we added a wiki to the project, we also added a ‘view_wiki’ and ‘edit_wiki’ permission. You can set any of these to a list (aspect) or enumerate the allowed/disallowed folks individually, or make them public. There are other possibilities as well, such as everybody on this site, or connections only, or mutual connections, or only people using a specific protocol. It’s all in your hands. If you lack the relevant permission, we refuse the action.