Skip Navigation

To defederate or not defederate: user-based vs. server-based content filtering in the fediverse

Hello everyone

Since the announcement of threads to join the fediverse and the resulting discussions I have been thinking about the matter of content distribution and filtering in the fedi. Here is a possible solution to it.

In essence, one can distinguish between server-based and user-based content filtering.

  • server-based content filtering regulates which instances federate with each other and which content is cached on the own instance.
  • user-based content filtering regulates what content the end user sees.

Content can also be categorized, for example, according to its origin. Sorted according to the quantity produced, there would be:

  1. instances
  2. communities/tags
  3. users/channels

From this I then derive the following behaviour:

  • server based content filtering should be used when servers want to prevent certain content from being cached or when they want to set up a small exclusive gated community with a few selected federated instances.
  • user-based content filtering should allow granular filtering of all the above content groups with the help of white and blacklists. This could look something like this:
instances communities users
blacklisted
whitelisted

Each field could contain a drag and drop function or a field for importing a blocklist as well as a search function to find instances/communities/users. Instances could also define in advance which default settings an account created with them could come configured with. The instances defederated by the server could optionally be displayed with a checkbox, but then in a grayed out look to make it clear that they cannot be changed by the user.

What do you think?

3 comments