FEP-b2b8: Content Warnings #23

david_roetzel commented 2025年03月26日 17:42:50 +01:00

In Mastodon (and thus in other implementations that want to be compatible) we still have the unfortunate situation that we use the summary attribute for content warnings.

The FEP describes summary for Article as I believe it should be, so I think this is fine. But I wonder if this problem / discrepancy should be mentioned in some way.

At the very least I wonder, how would you add a content warning to an Article?

I suspect the answer might depend on the outcome of the work here: https://github.com/swicg/activitypub-trust-and-safety/issues/1

But regardless of that, to be useable for Mastodon and other Mastodon-compatible micro-blogging services, I believe the FEP should address this issue in some way.

But how exactly I am not sure, sorry. Maybe someone can offer an idea?

In Mastodon (and thus in other implementations that want to be compatible) we still have the unfortunate situation that we use the `summary` attribute for content warnings. The FEP describes `summary` for `Article` as I believe it should be, so I think this is fine. But I wonder if this problem / discrepancy should be mentioned in some way. At the very least I wonder, how would you add a content warning to an `Article`? I suspect the answer might depend on the outcome of the work here: https://github.com/swicg/activitypub-trust-and-safety/issues/1 But regardless of that, to be useable for Mastodon and other Mastodon-compatible micro-blogging services, I believe the FEP should address this issue in some way. But how exactly I am not sure, sorry. Maybe someone can offer an idea?

silverpill commented 2025年03月26日 18:39:38 +01:00

Maybe someone can offer an idea?

I propose <details>:

• Standard HTML element, easy to support
• Multiple content warnings can be added
• Additional metadata (e.g. type of warning) can be specified with tag property

>Maybe someone can offer an idea? I propose [`<details>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details): - Standard HTML element, easy to support - Multiple content warnings can be added - Additional metadata (e.g. type of warning) can be specified with `tag` property

dariusk commented 2025年03月27日 18:31:50 +01:00

I think in practice people would continue using summary as CW as long as Mastodon does, until this issue is resolved, and preview is the actual field that carries the payload that's a short description of the content. I am going to implement this in Hometown to show the interaction of CWs as currently implemented in Mastodon and the preview field.

I don't know if including the CW in the Article HTML payload as <details> (or anything) would be a great idea; that would put the burden on consumers to parse it out. The proposal already recommends pre-parsing key images for display on the production side; I would expect CW to be treated as a similar first (second?) class piece of data.

I think in practice people would continue using `summary` as CW as long as Mastodon does, until [this issue](https://github.com/swicg/activitypub-trust-and-safety/issues/1) is resolved, and `preview` is the actual field that carries the payload that's a short description of the content. I am going to implement this in Hometown to show the interaction of CWs as currently implemented in Mastodon and the `preview` field. I don't know if including the CW in the Article HTML payload as `<details>` (or anything) would be a great idea; that would put the burden on consumers to parse it out. The proposal already recommends pre-parsing key images for display on the production side; I would expect CW to be treated as a similar first (second?) class piece of data.

devnull commented 2025年05月01日 18:17:00 +02:00

I wanted to share an additional data point today that GtS apparently treats summary in as:Article as a content warning. This deviates from Mastodon behaviour which only applies CW for as:Note.

I wanted to share an additional data point today that GtS apparently treats `summary` in `as:Article` as a content warning. This deviates from Mastodon behaviour which only applies CW for `as:Note`.

evanp commented 2025年05月08日 04:57:25 +02:00

I don't think embedding metadata in the HTML of the contents is the way to go.

Let's do it this way:

sensitive marks an article as potentially sensitive in the author's opinion. If the sensitive flag is set, the consumer should obscure the content of the article until the user conveys intent to read the article or view embedded media.

To help the user decide whether to read the article or view its media, the consumer should show these properties, if provided, in order:

• dcterms:subject: a property from the Dublin Core metadata terms. Value should be a string or array of strings indicating the topic or topics discussed in the article.
• tag: in particular, Hashtag names. (subject is preferred because it's more human-readable).
• name: as described above, the title of the Article. Authors are more likely to leak sensitive material in the title, so the subject and/or hashtags should be used first.
• summary: as described above. Only as a last resort when other properties are not defined; a well-written summary is likely to include significant excerpts or summation of the sensitive content.

A minimal example:

{
 "@context": [
 "https://www.w3.org/ns/activitystreams",
 "https://purl.archive.org/miscellany",
 {"dcterms": "http://purl.org/dc/terms/"}
 ],
 "id": "https://example.com/article/1",
 "type": "Article",
 "name": "Spoiler for Citizen Kane",
 "summary": "<p>I am going to tell you what Rosebud was. Buckle up!</p>"
 "sensitive": true,
 "dcterms:subject": ["Citizen Kane"],
 "contents": "<p>Rosebud was his sled!</p>"
 "tag": {
 "id": "https://example.com/tag/spoilers",
 "name": "spoilers",
 "type": "Hashtag"
 }
}

I don't think embedding metadata in the HTML of the contents is the way to go. Let's do it this way: [sensitive](https://swicg.github.io/miscellany/#sensitive) marks an article as potentially sensitive in the author's opinion. If the sensitive flag is set, the consumer should obscure the content of the article until the user conveys intent to read the article or view embedded media. To help the user decide whether to read the article or view its media, the consumer should show these properties, if provided, in order: - `dcterms:subject`: a property from the Dublin Core metadata terms. Value should be a string or array of strings indicating the topic or topics discussed in the article. - `tag`: in particular, `Hashtag` names. (`subject` is preferred because it's more human-readable). - `name`: as described above, the title of the `Article`. Authors are more likely to leak sensitive material in the title, so the subject and/or hashtags should be used first. - `summary`: as described above. Only as a last resort when other properties are not defined; a well-written summary is likely to include significant excerpts or summation of the sensitive content. A minimal example: ``` { "@context": [ "https://www.w3.org/ns/activitystreams", "https://purl.archive.org/miscellany", {"dcterms": "http://purl.org/dc/terms/"} ], "id": "https://example.com/article/1", "type": "Article", "name": "Spoiler for Citizen Kane", "summary": "<p>I am going to tell you what Rosebud was. Buckle up!</p>" "sensitive": true, "dcterms:subject": ["Citizen Kane"], "contents": "<p>Rosebud was his sled!</p>" "tag": { "id": "https://example.com/tag/spoilers", "name": "spoilers", "type": "Hashtag" } } ```

evanp commented 2025年05月08日 05:29:42 +02:00

I've added this guidance; hopefully this will be helpful.

I've added this guidance; hopefully this will be helpful.