Closed cwebber closed 7 years ago
Some background: currently, content warnings are mainly implemented on Tumblr (the community, not the software) in two different ways:
Using the "Show More" feature, you would describe the content "above the cut", and then put the main body of your post "below the cut". This requires every user to "opt-in" to seeing the post by taking a deliberate action. This is analogous to content warnings on mastodon today, and maps reasonably well to the summary/content distinction.
A tag with a keyword for users to block, like "#self harm cw". This is the "opt-out" form of content warnings, and allows users using browser addons to block posts that they don't want to see, using XKit Blacklist or Tumblr Savior. This is analogous to the regex filter on mastodon today, and it derives it's strength from the fact that it doesn't necessarily require deliberate action on the part of the user creating the content—if I block "Trump", it will block any post that mentions that keyword, rather then just ones that the original poster deliberately flagged as content warnings.
Maybe we should still keep the "ContentWarning" type in there, I dunno?
Seems like this would be important for UIs that did implement Content Warning support? I.e. if I want to hide all posts with a particular CW tag, how would I implement that? summary
would have to be parsed somehow, no?
@nightpool one problem with the second bullet point though is that it relies on the reblogger appropriately tagging the content. If someone I follow reblogs something and doesn't tag it, I'm screwed if the right keyword isn't mentioned in the body.
Maybe there isn't a great way to solve the problem I just mentioned? I dunno. In AP-land though I can imagine people "adding on" content warnings as they reshare. At least at a protocol level; I dunno what that UX would look like.
The mechanism Mastodon uses in OStatus is already a bad hack, I hope this 'summary' mechanism doesn't make it into AP.
@lambadalambda can you clarify why you hope it doesn't make it into AP? I don't know how CWs are implemented with Mastodon's OStatus stack, but AFAICT what's under discussion here is just how to implement this user-facing feature with ActivityPub, which wouldn't have anything to do with the way the OStatus implementation worked.
The way OStatus does is is via putting the spoiler text in the 'summary' field. Then, if any summary field is present, it hides the content for click-through. There really is no reason for this cw text to be in a summary field, it was just done that way in OStatus for backwards compatibility (and in a bad way, because it overloads the semantics of the summary field).
I don't have anything against codifying CWs in AP, but it should have a proper mechanism and not overload fields that are used for other things.
one problem with the second bullet point though is that it relies on the reblogger appropriately tagging the content
@strugee That's currently the case on Tumblr, but I don't see why it has to be the case on ActivityPub. You should very easily be able to get the tags on the original post programmatically, because they're embedded in the post object (even if you don't display them to the user for UX reasons)
(it's actually one of the long standing improvements I have slated for XKit Blacklist, although I haven't actually found time to implement it.)
Capture from the SocialWG group: the working group seems to have consensus that having specially content-warning annotated tags is the right way to go, but we should discuss with the CG to get buy-in.
@cwebber I don't think that having specially content-warning annotated tags is actually going to solve mastodon's usecase though.
Yeah, we talked about this on the Community Group call. Tags are generally granular, and the benefit we discussed was being able to filter on specific tags depending on whether you're not okay with gore but are okay with politics, etc. But Mastodon isn't going to change its behavior any time soon from content warnings as a big block of text, which means this isn't really useful.
Maybe we should close this; it looks like Mastodon will continue to use the summary field and we don't have anyone itching to add ContentWarning type tags right now as far as I know. We do have the sensitive
property per #231 anyway.
I'm closing this with "commenter satisfied" since I'm the one that raised it, and Mastodon seems uninterested in doing ContentWarning as a type so it looks like we won't be moving forward with it realistically. We can still explore adding the sensitive
property to tags per #231
I personally would not mind having content warning functionality as a tag system. I think using the summary field for it is indeed a hack and would prefer a more robust method.
Is there any way a user who boosts a post could tack on a CW to the message? I realize this is very close to quote tweeting
Mastodon has Content Warnings and they seem like a pretty good idea. Currently, it looks like Mastodon will implement Content Warnings using the summary field which is pretty clever.
Previously I thought / assumed that Content Warnings could/would be done on the tag property with a special type, like
{"tag": [{"type": "ContentWarning", "content": "American Gods spoilers"}]}
but maybe this summary solution is a better idea. Maybe we should still keep the "ContentWarning" type in there, I dunno?