DIP-286 Content Moderation Announcement

[wesbiggs]

Abstract

Provide a new Announcement Type that enables the author of a Broadcast to hide Replies to her post.

Content Moderation Announcement

• announcementType: enum value
• fromId: must match the thread author's DSNP User Id
• targetContentURI: the item being moderated

The effect of the announcement should be to remove the item, and any of its descendants, from the "thread view" of the conversation.

Note that this differs from a Tombstone announcement both in who can make the Announcement, and what happens to the targeted content. The targeted Reply Announcement continues to exist, and may be accessible in other ways (e.g. viewing the replying user's timeline). It only affects the thread.

Motivation

We represent a "thread" as a Broadcast followed by a tree of Replies (and their associated Reactions). We tend to think of a thread, particularly in the realm of public content, as a space that can be curated by its author.

While users can Tombstone their own content, there is currently no facility in DSNP for the author of a thread to remove comments that are adjudged to be abusive, unwanted, or otherwise unwarranted. This DIP adds the affordances for this.

Specification Pull Request

Current change pull request: TBD

Rationale

Why were the design choices made? What other solutions were rejected and why?

We could also see a design that would allow any ancestor node in the tree to hide descendant Replies. This way of thinking leads to a view of many sub-spaces, each with their own controller. We think putting the "duty of care" squarely on the original author is at least defensible; as it is the original author's space, they are responsible for maintaining it. The author of a Reply, who elicits abuse as further Replies, would need to appeal to the author of the Broadcast for help removing the offending items.

Backwards Compatibility

Any proposal that breaks compatibility with previous versions must describe how the change will be implemented and handle the migration period.

Reference Implementation and/or Tests

What could this look like implemented or what tests could be provided to assist in validation of implementations?

Security Considerations

Any change will effect the security of the system in some way. Describe the implications this DIP on security, both technical and human.

Dependencies

• List of dependent DIPs if any.

References

Any references or other related links that might be helpful.

Copyright

Copyright and related rights waived via CC0.

[wesbiggs]

Community Call 2024-11-07

• Handling is similar to Update Announcement and can change the context of a conversation
• Positive: Enhances user control of their thread
• Negative: Allows a user to manipulate their conversation, perhaps in sneaky ways
• May need to specify how the author of the moderated-away content can still reach it
• If Bob comments on Alice's post, and Alice moderates it away, can people who follow Bob continue to see it, and in what context? How is the possible loss of context handled?
• "Detach" may be a useful term here

[wesbiggs]

Community Call 2024-12-05

• Discussion of 3rd party (application provider-based) moderation

• Users control their content, but applications also are responsible for the content that they announce via DSNP

• Typically, applications enable users that use that application and host their content (to the extent it is posted via their platform), but only under their terms of service

• Applications also have a choice to filter content that is posted elsewhere on the network

• How does a conversation maintain continuity if parts of it are not visible?

• Ideas about rationing the amount of moderation

• Moderation is not necessarily binary

• Distinctions in policies between apps

• Common Sense Media analogy (multiple spectrums/dimensions)

• How to ensure moderator "bad actors" can be penalized, etc. (metamoderation)

• Is "voting with your feet" an adequate mechanism? Are there guardrails that can be created to standardize?

• Intersection with tagging for broader review

• "user revoked", "provider revoked"

Affordances:

• User can revoke things in their thread
• Provider can revoke things that don't fit their T&Cs (should we shift terminology from "moderation" to revocation/"unhosting")
• Regulators might have a legal revocation framework

Alternative approach:

• Private channel for providers to make determinations before they hit the public log?

[JoeCap08055]

So:

user-initiated moderation:

• Providers should not display moderated content in the context of my thread
• content may still be visible in the poster's timeline, for instance.
• depending on the T&C of the offending user's Provider, a user-initiated moderation may trigger a Provider-initiated moderation

provider-initiated moderation (ie, T&C or legal violation, etc):

• Providers should not display moderated content in ANY context.
• I (originating Provider) hereby announce that I am no longer pinning/hosting this content.
• Effectively a provider-initiated Tombstone.