"Opt-in" flag
Rationale
Smilodon eschews heavy content moderation for an opt-in workflow. Harassment reports are still honored. However, Smilodon instances need to interact fairly with existing moderation-oriented instances. We propose that Mastodon (upstream) adopts a "content_moderation" flag, which will be inherited by Smilodon.
Design
On either type
- "content_moderation" flag is set at an instance level
- "content_moderation" flag is included with each post (or otherwise communicated between instances, ideally in a way suitable for any ActivityPub server, not just Mastodon)
On Mastodon
- "content_moderation" is off by default, must be actively set by the admin
- admin may choose to allow inbound messages with
content_moderation=F
On Smilodon
- "content_moderation" is off, cannot be set on
- all inbound messages are allowed
Message receipt logic
When messages are sent between instances, they will appear (or not) as follows:
Feed | M > M | O > M | * > O | unlisted > * | silenced > * |
---|---|---|---|---|---|
1. Local timeline | N | N | N/A | N | N |
2. Unfiltered federated timeline | Y | N | N/A | N | N |
3. Search results [a] | Y | N | Y | N [b] | N? [c] |
4. Mention feed | Y | N | Y [d] | N? | N? |
5. Followed feed | Y | Y | Y | Y? | Y? |
6. Report flag | Y | Y | Y | Y? | Y? |
- [a] Including federated hashtag timelines
- [b] Doesn't show up in local search results
- [c] Will show up in local search results
- [d] Mention feed should be off by default
Notes:
- "Unlisted" refers to an instance where all posts are tagged as unlisted.
- "Silenced" refers to a silenced instance, not a silenced user.