[feature] Subscribe-able allowlists / denylists

[tsmethurst]

Instances should be able to subscribe to a public list (some kind of JSON format hosted on, for example, github or anywhere else) to populate their allow/deny lists. This allows for the possibility of community-moderated blocklists or indeed community-moderated allowlists.

Eg., you have a github repo (or whatever) where people can make PRs to add entries to the allowlist or the denylist. Discussion happens. The entry is added or not. Instances subscribed to that allowlist/denylist update (perhaps every 24hrs automatically or with a manual action or even a git webhook??). If you don't like the list, fork it and make your own. Or just don't use it at all.

Note: this should, of course, happen at an instance level not a user level, to avoid targeting individual users.

[not-not-the-imp]

Lets hope this is the right place to talk about allow-list / deny-list in a federated context. I'll start with a simple approach, then a different way to frame the possibilities, then something more complex around the step once we have a system to federate relationship status update.

The simplest approach ? The instance could be to use the nodeinfo facility to display the allow/deny lists. That exists already and with an incremental version number, anyone can scrap that data and use it

Now with a framing of "an instance is actually an account" An instance can send messages. Currently mastodon make those local only (ha the ironyn) and threat them differently than other messages. An instance can block people, just like users do. An instance can mute people, just like users do. An instance has reports, which are like a notification that user get, just different in its intent. Users have follow list, and instances have a negative of that: a deny-list, a set of instances that its account cannot follow.

This leads to few ideas:

• An instance could have a default account that could post, locally or otherwise.
• An instance account could be followed, maybe by users or other instance account.
• An instance account could post de-federation statement, in a standard format, locked, or unlisted, or publicly
• An instance account could post a federation statement
• An instance account could opt to get a notification/report on another instance account profile to make sure federation news don't get missed.
• Users could @ the instance account to start a discussion about moderation, other could join in.
• User could DM the instance account with instance to block instead of having to report a call out.

That means no RSS, as this would rely on conventions, so maybe quite loose and harder to parse until a format solidifies The benefit is no accounts needed to comment and no need to move info back and forth for admins.

Now for the more fluffy vision stuff One part that is really missing in mastodon (which is a shame for a decentralize network) is a way to make sense of the network. While all the "A defederate from B" message are interesting and important, they don't help understand the shape of the network.

Having programatical access to every allow/deny lists of the node I interact with a first step to get better moderation. It would be even better if the system understandood the N:N relationship of the instances in the network. Human sieve through lists to find something actionable, but the computer can map the network instead and infer a lot that lists don't reveal. Furthermore, the instance has access to a social graph with the instance traffic it sees, so we have more than a simple map of the network, we also have some visibility of the flow.

Once the network is mapped, it can be visualized (eg a 3d version of what fediverse.space was). A few example of what that could mean for moderators and admins:

• I just blocked nazi.nazi. Could I see who else block them? Could I see who doesn't block them? Could I see which way the traffic flows?

• My 10 best mate instances (as per the social interaction graph) just defederated from nazi.nazi. Could that instance get flagged? Could I implicitly trust my 10 neighboors and have a preemptive block now and a notification to review it later?

• A new instance spawned right in my deny list network. Could I mute it until I review it? Can I block it by default?

• An instance I trust post a federation announcement, on an instance I don't know Can I pull some of that new instance content automatically?

Conclusion There is many way to do better than mastodon in regards to federating moderation decisions. Having a vision of what we could ultimately do with the data might inform how to go about it.

[tsmethurst]

Oooh thank you for this! I will have a read tomorrow morning when I'm a bit fresher and get back to you <3

[aschrijver]

This is related.. some ideas I brainstormed a bit about on 2 topics: Federated Moderation and Delegated Moderation, both steps to make moderation a first-class citizen of the Fediverse.

• SocialHub: Federated Moderation: Towards Delegated Moderation?
• FediverseFutures on Lemmy: Federated Moderation: Towards Delegated Moderation?

[not-not-the-imp]

Someone wrote a paper on this and some software that implement something like federated moderation The short version: https://cblgh.org/trustnet/ The full paper (4MB, 100 pages): https://cblgh.org/dl/trustnet-cblgh.pdf The software implementing the ideas: https://github.com/cblgh/trustnet

cblgh's trustnet would be a contender, if not for the final mechanism, at least to learn and refine GTS acceptance criteria for a federated moderation system.

[aschrijver]

Very nice, @not-not-the-imp .. going to add that to these 2 threads.

[Seirdy]

I support this feature, but it'd need to ship with retractions support. The best way to do this is to include a noop severity level for a blocklist entry, and allow an import to downgrade an entry with a reason. Perhaps there could be functionality for admins to review downgrades before applying them.

[tsmethurst]

So what I'm thinking for this now is that when you create a subscription, you should be able to choose whether to automatically accept everything on the subscription, or to have the subscription propose 'draft' domain permission entries, which you can then browse through and approve/dismiss.

Ideally, these would have the following characteristics:

• Proposed drafts should show to the admin the consequences of approving the draft (connections cut off, accounts removed, etc). We'll need a new API endpoint for this whereby you submit a domain name, and you get back stats for that domain.
• When a draft is dismissed, the admin should have an option to make their instance remember that it was dismissed, and not create a new draft every time the blocklist is refreshed. We could do this by just keeping the draft in the database but setting some flag to 'hidden'.

Eventually, admins ought to also have an option to only have their instance create drafts if there are follow/following relationships that will be severed, else just automatically accept without creating a draft.

[tsmethurst]

@Seirdy the above ^^ is similar to what you described, but more in line with the current internals of GtS