4.6 KiB
Homesteading the Fediverse
Some things you might want to know about the Fediverse:
Federation as a concept
The political definition of a federation is "a union of partially self-governing states or regions under a central (federal) government". The fediverse isn't exactly like that, in that there is no federal government. However there are protocols which govern the communication between instances and that might be analogized to being a sort of elementary constitution or mutual agreement binding all participants together. The protocols are merely ways of moving data around though, and don't impose any sort of moral code.
Keep the number of users on each server small
The importance of this can't be overstated. Servers with lots of users always eventually have problems where the interests of the users are not the same as the interests of the server administrator. If you are the server administrator, or if there are only a small squad-size group of people on the server, then it's a lot easier to resolve differences and everyone's interests are likely to be similar.
Drama will happen
It's inevitable in any social network, but fortunately your options for dealing with it are better than they are in the giant proprietary monoliths. In the proprietary world Google or Facebook don't give a damn about the fate of individual users. On a server with a small number of users if you're getting griefed then the administrator is likely to care and be able to do something about it.
Don't be afraid to block
Especially if other servers are publishing content which may not be legal in your jurisdiction then don't be afraid to use domain or user blocking from the Administrator control panel. The same applies if users on other servers are trying to harass you. Blocking creates politics and drama but this is a feature not a bug. It allows you to craft your own distinct community and user experience while also existing in the wider federation. It's hard to do this on sites like Twitter or Facebook. Try to keep blocking to a minimum though and avoid doing it for insubstantial reasons. If you have other users on your server then publish the blocked domains list somewhere they can see. That avoids disappointment and enables you to have a discussion about the validity of blocking decisions.
Network structure maps on to social structure
Over time follows and blocking rules come to match the underlying social geography of affinity groups. Blocking will happen and users will move around or start new servers. Drama related to blocking will dissipate.
Keep your follows under the Dunbar number
Keep the number of other frequently active users you're following to under a couple of hundred. Your actual number of follows might be larger than this but could include users who rarely post anything.
Once there are more than a couple of hundred highly active users in your timeline then you'll just be overwhelmed by irrelevant stuff and whatever community you may have been part of will be drowned in the entropy. There are no algorithmic timelines to hide posts, and even if they're introduced then they create their own problems as an opaque form of censorship. Real community happens at tribal scale. It's something which people often don't like to admit because they get fixated upon bigger and bigger numbers, but it definitely seems to be true.
Avoid big public servers
It may seem like a good idea and it may seem like you're doing a service to the community by allowing random strangers to register, but servers with thousands of users only cause problems - social, administrative, financial and possibly also legal. The financial strain of running a powerful server with high reliability may be enough to encourage the administrator to begin pushing advertising onto the system, or sell user content, and then before you know it you have identical problems to Twitter. Instead try to encourage people to set up their own servers. Follow this principle and a lot of arguments and stress will be more easily avoided.
This site can also be accessed via a Tor browser at http://yjxlc3imv7obva4grjae6u3qw527koaytrgjgdp364hmthrst3jodiid.onion. This documentation is under the GNU Free Documentation License version 1.3