To defederate or not defederate: user-based vs. server-based content filtering in the fediverse
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:
- instances
- communities/tags
- 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?