This is @deoxxa's overview of the various components of OStatus: https://www.fknsrs.biz/blog/don-statusnet-node-part-one-read-protocols.html

It's worth reading. IMO the component to think about is PubSubHubbub. Specifically, the hubs, which serve as notification intermediaries between publishers and subscribers.

Key notes:

1. Hubs do NOT need to be Twitter-like user homes.
2. Hubs are very capable of tracking user behavior, even if notifications are encrypted.
3. Hubs need to be reliable.

So the question: how to make hubs that are/have

* reliable
* trustworthy
* non-exploitative of users
* non-authoritarian (wrt censorship)
* proxy-able
* graceful failover
* graceful obsolescence
* potentially anonymous
* potentially transient

I think in the absence of these considerations, mastodon networks will, as others like @bcrypt have pointed out, tend to consolidate around a few large instances that will have too much trust & reliability burden placed on them.

I'm uncomfortable with hub-runners deciding which other instances they do and do not federate with. People can certainly run filtering services, but they should be independent of instances/hubs, not tied to them.

For similar reasons, I don't think hubs/instances should be thought of as communities with individual cultures, because you then turn the hub-runner into the de facto community leader.

Running a SMTP/NNTP/OSocial server shouldn't make you a doyenne. People get high off of that power.

@auerbach in practice the servers are little communities. they just are, I don't know how to justify it but they end up working that way. but part of that is that who you talk to and how is shaped by the contours of the software.

earlier version of mastodon made no distinction between local and remote users, this caused constant problems for the rest of us on gnu social because mastodon users kept shitting all over GS users for violating community norms when we weren't really in their community

@auerbach the local and federated timelines end up being a means of managing complexity, and they create something that gives incentive for a person to run their own node in the first place. in the last couple days I've gotten a MASSIVE spike in activity on my GS server, I now have to think about is it worth expanding to deal with capacity to facilitate talking to all these remote nodes. my incentive is my local community whom I like, rather than just the giant mass of mastodon users
@auerbach (by "activity" I mean, the load on my server caused by servicing remote follows by other nodes of people on mine.)

@MoonMan Okay, it's pretty funny I'm talking to "MoonMan" about this subject.

I don't disagree that community clusters can form. In fact, I assume that they will, and that's precisely why I think content discrimination should be separated out from instance administration. An instance administrator can run a blacklist/filter as well, but formal separation of function will make it so that instance users are not subject to the whims of the instance admin.

@auerbach i want the social network you're asking for, but I think there are a lot of technical issues accomplishing it on this platform with the way these servers work and its a distraction from what they already do best.

not meaning to weigh you down with back and forth, just my thoughts from some of the challenges running my own server. my server is https://shitposter.club/ and probably about 60+% of mastodon servers block us outright. my acct on this server is for inter-server comms :-)

@auerbach @MoonMan
Isn't reviewing the policies of the instance admin part of the process of picking an instance? I'm with @Elucidating in that the isolation is a feature.

I mod on several subreddits, and I think that the ability of each community to set their own rules and is a workable model. Being able to say "nothing even remotely transphobic is allowed and I'm the final arbiter" protects my users from BS under the banner of "discussion".