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

Content Warnings #232

Closed
cwebber opened this issue Jun 18, 2017 · 12 comments
Closed

Content Warnings #232

cwebber opened this issue Jun 18, 2017 · 12 comments

Comments

@cwebber
Copy link
Collaborator

cwebber commented Jun 18, 2017

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?

@nightpool
Copy link
Collaborator

nightpool commented Jun 18, 2017

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.

@strugee
Copy link

strugee commented Jun 19, 2017

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.

@lambadalambda
Copy link

The mechanism Mastodon uses in OStatus is already a bad hack, I hope this 'summary' mechanism doesn't make it into AP.

@strugee
Copy link

strugee commented Jun 19, 2017

@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.

@lambadalambda
Copy link

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.

@nightpool
Copy link
Collaborator

nightpool commented Jun 19, 2017

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.)

@cwebber
Copy link
Collaborator Author

cwebber commented Jun 20, 2017

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.

@nightpool
Copy link
Collaborator

@cwebber I don't think that having specially content-warning annotated tags is actually going to solve mastodon's usecase though.

@cwebber
Copy link
Collaborator Author

cwebber commented Jun 21, 2017

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.

@cwebber
Copy link
Collaborator Author

cwebber commented Jun 27, 2017

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

@Angular-Angel
Copy link

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.

@caitp
Copy link

caitp commented Dec 16, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants