heh, this is a funny interaction between your site/markup and Mastodon. the CW text here actually comes straight from your mf2 on https://beesbuzz.biz/blog/5474-Progress, specifically its p-summary. that gets propagated into the AS2 summary field that gets sent to Mastodon. Mastodon [ab]uses the AS2 summary field as its CW text, which is a somewhat benign, kind of accepted, but still definitely non-standard usage.

background:

• Content Warnings w3c/activitypub#232
• https://www.w3.org/wiki/Socialwg/2017-06-27-minutes#.23231_Sensitive_Media
• https://octodon.social/@cwebber/101557191795199946

having said that, i'm definitely open to tweaking bridgy fed's semantics for federating full length articles like this! eg the other extreme would be just the title and a link, but that doesn't seem ideal either. meh.

Yeah just a title and link makes this only slightly better than having my existing IFTTT pipeline (although having the webmention responses and such is a nice addition, which is why I've gone down this rabbit hole again).

I guess I need to do a better job of interpreting the h-entry markup. Also worth mentioning that the resulting formatting is completely different on queer.party.

Also worth mentioning that the resulting formatting is completely different on queer.party.

hmm. that may be because dragon.style is mastodon 2.4.4 and queer.party is 2.7.4. i checked and confirmed that bridgy fed sent identical AP Create requests to both sites.

Ah, I thought dragon.style had been updated recently, but in any case it's surprising anyway that these things would be so different between them.

I think maybe this could be handled with some ActivityPub-specific microformats which could be documented as part of fed.brid.gy or something. For example, have e-content map to the body of the post and p-content-warning, if any, be the CW text, and it can be up to the site owner's discretion as to whether to make the p-title also express p-content-warning for example. (And if there's no e-content it would fall back to p-summary.)

For example, have e-content map to the body of the post and p-content-warning, if any, be the CW text

one difficulty here is that "CW text" is very much a mastodon-ism, not a standard AP feature, and i've tried pretty hard to avoid project-specific heuristics and have bridgy fed just speak plain AP. this kind of thing would be a mastodon heuristic. maybe ok, since in practice the vast majority of bridgy fed usage is mastodon...but still, disappointing.

What happens if you send CW text to a non-Mastodon ActivityPub instance? Does it just get ignored?

(The more I'm learning about this the more I'm really disliking ActivityPub, especially if it's supposed to be the replacement to RSS/Atom...)

good question! again, this is the AS2 summary property, not CW text, since there is no such thing in AS2. i haven't dug into it, though, so i don't know what other services do yet.

(i'm on #indieweb and #indieweb-dev in IRC btw, maybe better to move there.)

and AP is actually pretty good overall. definitely some warts, eg some privacy details, but "CW text"/sensitive content is arguably just a missing feature in all of these protocols - AP, OStatus, and RSS/Atom.

Sure, CW text isn't part of RSS/Atom, but the UX around RSS and Atom makes it such that you're not expected to have it as a separate thing; cut/"more" links are an accepted standard approach. And the thing I'm lamenting here is the lack of structure for things like title, summary, full text, etc.

I'm happy to move this conversation to IRC, although I'll need to find an IRC client first. :)

Okay per the discussion it seems like this issue is outside of the realm of bridgy fed, and it's a combination of Publ not supporting summaries correctly (which has now been fixed pending my next release), my own site templates being kind of loose with the h-entry microformat (now fixed, awaiting said Publ release to be used properly), and Mastodon being incredibly loose with ActivityPub fields.

The one piece of software that seemingly isn't at fault here seems to be bridgy fed, so I'm fine with closing this issue. :)