snarfed
mastodon publish: enable content warnings? (blocked on new mf2)
Would it be possible to read an html element from a page being pushed to brid.gy and to apply a content warning based on that tag when pushing to the mastodon api?
So the p-summary or e-content will be collapsed behind the the content warning at the mastodon (or in my case pleroma) side.
this would be great!
sadly, we discovered in bridgy-fed that the devil is in the details here. mastodon abuses the ActivityStreams 2 summary field to represent content warnings, which is very non-standard, and only kind of accepted now because of mastodon's size. the microformats2 corollary is p-summary, which denotes an actual summary, not a warning that hides the content.
background:
- w3c/activitypub#232
- https://www.w3.org/wiki/Socialwg/2017-06-27-minutes#.23231_Sensitive_Media
- https://octodon.social/@cwebber/101557191795199946
bridgy prefers to follow existing mf2 usage, not invent it, so we'd need to resolve that conflict, find different mf2 class(es) for content warnings, and see examples in the wild. https://indieweb.org/content_warning currently only lists one site that's publishing content warnings, without specific mf2. feel free to propose some and use it on your site!
if my 3+ years on the fediverse has taught me anything it's that things don't tend to get changed for the benefit of others on Mastodon so I gather then it would require a new mf2 class, preferably non-vague about its use and if that was established it could be mapped to the summary field?
Sorry the answer to that is right there in the https://indieweb.org/content_warning link you supplied:
"Post content of a CW would be the normal post. It would just need some way to indicate that it was a post with sensitive content and potentially a way to either provide a reason or a category. This could be as simple as adding something like a p-warning-reason or something to that extent."
yup! and then get at least some preliminary consensus on http://microformats.org/wiki/irc and/or https://indieweb.org/discuss that this is the right direction.
OK, thanks! will have a think and try to see if I can gain some traction towards consensus.
OK, thanks! will have a think and try to see if I can gain some traction towards consensus.
This is something I'm into and didn't know what kind of name I wanted to use in the property naming.
OK, thanks! will have a think and try to see if I can gain some traction towards consensus.
This is something I'm into and didn't know what kind of name I wanted to use in the property naming.
Still thinking about how to word this, mainly due to my novice status in the world of indieweb.. but, Jacky how does p-content-advice sound\feel?
Hm, advice is interesting. I want this to signify that it’s a tag of sorts; something that can be indexed (for a negative filter search of sorts). This is making me want to lean into something like this format:
<code><span class="p-content-category p-category">gore</span>
<span class="p-content-category p-category">blood</span></code>
Leaning into what we have for tagging already would allow us to build a common way of filtering things out (or in). This is something that would have to be pushed up into the Microformats spec, IMO.
Also, I took some time to see how our friends in ActivityPub took this: https://github.com/w3c/activitypub/issues/232, some important notes there regarding overloading. One downside is that they relied on Mastodon to be the defacto representative of AP, in Microformats; the format is the leader!
(Originally published at: https://v2.jacky.wtf/post/d7187860-6d7a-4cc9-9465-792daaab2b30)
That ties in well with non-mastodon activitypub folks' idea of how the content warning could or should have been represented in the protocol so having separate tags per category makes sense for future-proofing should there ever be a shift. I like it.
I prefer advice over warning semantically but neither really need to be used as per your example.
great conversation! also, just fyi, it would probably fit better and get better feedback on #microformats IRC and/or https://github.com/microformats/microformats2-parsing/issues.
So @tantek brought up the idea of using p-content-warning as a property here and I’m into using that! However, there’s no client support for this (as we’ve just made it up, lol) so I’ll see if I can get it into https://indigenous.realize.be/ and https://publish.koype.net/ on my end.
(Originally published at: https://v2.jacky.wtf/post/2d524f3d-9c76-4b9a-8049-7a0038db8458)
This seems to have sat for a couple of years with no serious objections. Is there anything that can be done to move it forward (or backward – out of limbo, anyway)?
In the mean time, I'm going to start marking my blog up with p-content-warnings where appropriate and hope that fed.brid.gy starts using it before I get around to implementing something horribly hacky myself.
@pdcawley thanks for the nudge! Often you're right, long-lived feature requests like this aren't necessarily blocked on anything, they just haven't been prioritized. PRs are always welcome!
Btw though, if you're looking for this on https://fed.brid.gy/, you want https://github.com/snarfed/bridgy-fed instead!