In the fediverse, an instance is a community. A group.

Let’s say your local beekeepers community has a forum. Is it strange that you register there, create a profile and tailor that profile for that community alone?

Now, let’s say you also organize political rallies for a local party. They too have a forum, where you register as well. Would you want your political profile to sync, or be linked with your “beekeepers profile”? Most likely not. You would probably be annoyed to find that when you change your profile image on the political forum, it automatically changes on all other forums you have profiles on.

Yet this is what centralised social networks do. If that beekeepers’ community and your political party are on Facebook and host their communities there, this exactly what happens. A fellow beekeeper can now see your political alliance. Changing your name or profile image for only the beekeepers is impossible. Facebook will probably even start pushing your political updates to your fellow beekeepers, now. And even if such a centralised network offers features to keep your activity separated, they themselves know your alliances now: they know you are a political active beekeeper. Reddit, with its subreddits, or Linkedin with its groups suffer the same issues.

But not with a federated network! Federation offers a clear, clean and simple way to keep your activities contained to a group: the server your account is on! It is a very natural way to isolate your different profiles. As can be seen in the forum-example. A server, is often called an instance.

Rather than one account subscribing to Facebook groups, or Subreddits, thereby disclosing a lot of information about yourself, you can now simply create an account on separate servers. Very similar to the earlier forums example.

Quite some people have asked us how Flockingbird envisions “groups”. Simple: we don’t!. Flockingbird has no group features planned.

We believe that in a federated network, servers are groups. In a clear, clean, simple and secure way.

Adding a groups model on top of that federated model, we believe, is a nightmare: it requires highly complex moderation systems. It requires complex, and easily misaligned privacy settings or models. And the list of groups you belong to, alone leaks far too much information, so that needs another complex privacy model. Furthermore, activity within closed groups also has to be limited in visibility: an update about the upcoming social media campaign within your local political party must be kept private and never accidentally shared with, say, the local beekeepers group. With overlapping people, possible even over different servers, this becomes even harder. The scenarios in which it can go wrong are so numerours and intricate, that mistakes will be made. Complexity is the enemy of security. And privacy. For us, keeping the privacy model simple and understandable is a critical feature.

It does raise one important question, though: What If I want to belong to several groups?. Or what if I want my accounts to be linked.

The easy answer is “just register another account on the other group” and “add a link to your profile with an explanation about your other profile”: I am also active as in the local beekeepers community, for example.

We believe the actual requirement for that is not that big. E.g. Stackexchange, with all their separate communities, has a clearly separated model: if you are part of, say, the Ubuntu Stackexchange, you have an account there. And if you are also part of the Database Administrators Stackexchange, you have a separate account there. Stackoverflow, being centralised, chose this model deliberately. It does offer ways to easy “register with an existing other stackexchange account”, via a single sign on mechanism. Yet it offers a vast range of opportunities: from presenting yourself different to different communities, to moderation: you may have extensive permissions in one community, but not in another. Or even get banned on one community, without that harming your presence in other communities.

Another problem is that this requires you to register (and remember) all those accounts. If you want to be part of a hundred communities, you’ll have to register a hundred accounts, remembering a hundred passwords. Ugh! We believe that the current ActivityPub fediverse, “suffers” from this issue anyway, already. You cannot log in on, say, a Pixelfed server with your existing Mastodon or Peertube account. A single-sign-on solution to “fix” this is being worked on by various people. Once that lands, and becomes more common, it offers another option for people to link their accounts.

One thing that is no different from existing federated networks, is that you can always follow (link with, tag, contact etc) anyone from any other community. That is what the whole federation is about!

Besides those more technical reasons not to implement groups, we have two somewhat ideological reasons to go for a “a server is a group” model.

We want to leverage existing, real-world networks. And we want to encourage many small servers over a few big ones.

Existing networks can be anything from your colleagues at work, to an alumni-group at your university. From a local business network to a political party. In a centralised model, someone would create a group for the alumni on a central server. In a federated model with additional groups, this would happen at one of the few large server instances. In a federated model without additional groups, it requires hosting another instance.

Obviously that gives us even more reason to make hosting instances really easy; but more on that in a later blogpost.

Such existing networks have existing trust models, and existing (often informal) community guidelines, and -moderation. For example, at your local coworking space you may be more restrained in what you share, than with your game-buddies. This is natural. We think this model, again, is a perfect fit for federation. This goes for trust too: in a federated network you need to trust the people operating the servers (in a centralised network, this is no different, just that you don’t have much choice there). This trust aligns well with existing networks too!

It is important to realize that the moderator of a fediverse server can see, change, hide or sell all your activity on that server anyway: you do need to trust that person (or people) a lot anyway. We believe that this trust model is already complex, but understandable; but only if it fits on existing trust networks, not when it adds complexities. With a server is a group, you have to trust the moderators of the political-party-server with all your political writings and discussions. With additional group-models, you may need to trust your local beekeepers-moderator with those political writings and discussions: highly confusing and often ill-fitting.

With this model, we offer a lot of freedom, while keeping things simple, and understandable.

• You can, if you want, link your accounts on several servers by adding links to those other accounts. But you can choose not to do that if you don’t want accounts to be linked.
• You can present yourself different to different communities easily. Full freedom here: you are free to choose different usernames, avatars, privacy-settings and so on; or choose the same, if you so wish.
• It leverages existing social networks and their existing trust models.
• It encourages more, small, dedicated servers: encouraging federation!

Do you think this is wrong? Do you think additional group models are required? Please let us know in the comments below, or with a message on our Mastodon account.