Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC3725: Content warnings #3725

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

robintown
Copy link
Member

@robintown robintown commented Feb 14, 2022

Signed-off-by: Robin Townsend <[email protected]>
@turt2live turt2live added client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal proposal-in-review labels Feb 14, 2022
@shmerl
Copy link

shmerl commented Oct 7, 2022

Any news on this?

@robintown
Copy link
Member Author

What this needs next is an implementation. Anyone is welcome to provide one :)

Comment on lines +84 to +86
and replacing the content warning types `m.spoiler`, `m.nsfw`, `m.graphic`, and
`m.medical` with `town.robin.msc3725.spoiler`, `town.robin.msc3725.nsfw`,
`town.robin.msc3725.graphic`, and `town.robin.msc3725.medical` respectively.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really sure if we need to use unstable prefixes for the warning types, since it's already within an unstable field.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unstable prefixes are required here because the meanings could change still, and developers will need to then do slightly more complicated lookups/matching. For example, if m.nsfw changed scope, the unstable implementation may need to create a whole new field instead of a town.robin.msc3725.nsfw.v2 type.

which are just one of the many event types that might require some kind of
content warning (images, videos, files, etc.). This MSC proposes a more general
content warning system to fill that gap, using
[Extensible Events](https://github.com/matrix-org/matrix-doc/pull/1767) to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I can tell, there's not really any reason this is dependent on extensible events. We can just as easily add the m.content_warning field to normal events (similar to what we did with m.mentions.

content warning, clients can then take measures to require consent from the user
before displaying the content.

## Proposal
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, this proposal allows for both the type and description to be unspecified, which doesn't make sense. I think that we should require at least one to be specified.

```

The `type` field is optional, and represents the general, machine-readable
reason for the content warning. The following types are provided:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe mention here that there can be other values (as long as they have unstable prefixes).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants