If a fediverse post contains something that the receiving server doesn't support, we need a defined way to show that to the receiving user. For example if I make a pixelfed post with 6 photos and mastodon only shows 4 of them, there needs to be a way to signal to the receiving side that there is content they can't see. This has been an issue forever but one of those little edges that makes the whole experience worse for everyone. cc @andypiper any ideas for how we could make progress on this?
This also touches on work that @snarfed.org is doing with Bridgey. When a post from AP land gets federated over there they have added a way for client apps to display the whole post even tho Bluesky only supports 300 chars.

@liaizon @andypiper
this is rooted in the dogma to ever push the full content and never GET.

Reconsidering this could finally lead to https://www.w3.org/TR/websub/ + GET. A landslide towards simpler #federation. IMO well #worth while.

WebSub

WebSub provides a common mechanism for communication between publishers of any kind of Web content and their subscribers, based on HTTP web hooks. Subscription requests are relayed through hubs, which validate and verify the request. Hubs then distribute new and updated content to subscribers when it becomes available. WebSub was previously known as PubSubHubbub.

@liaizon @andypiper i was disappointed that the mastodon quoting fep specifically identified that a quote would be invisible to software that failed to implement the spec, particularly since there was so much emphasis elsewhere to characterize failure to implement in starkly moralizing terms. one would think that if we intend to use terms like consent, the remote end failing to implement the spec would be able to understand the terms of the interaction. gts reply controls (which the fep cites, but mastodon has no intent to implement) do in fact provide just this kind of fallback, and in all respects demonstrates a more sincere respect for consent.
@liaizon @andypiper there is a further angle which i am thoroughly unfamiliar with how to handle but seems quite relevant in which the mastodon quote fep requires the cryptographic redaction of a quote approval's target when propagating it across servers. this is raised as a security concern but it also results in servers being used to propagate information that they cannot themselves validate (and the quote fep does not impose hashing, which means a quote approval or rejection can be fabricated from whole cloth while remaining hidden to the intermediary).
@liaizon @andypiper i mention it here although it does not pertain to post content as per OP because in both cases i feel there is a gesture towards a more general protocol (gts stamps, redaction of target, hashing of info) that would be appropriate to codify in the very general sense of OP. since we're using something like json-LD which intends to be introspectable, codifying information that is or isn't supported, or requirements to impose for downstream, seems achievable in ways an alternative encoding loses out on.
@liaizon I think @Floppy had some thoughts on this and possibly a FEP, but I forget the specifics.
@andypiper @liaizon mine was more along the lines of making sure anything was *followable* (i.e. don't filter by actor type), which is slightly different, but they're both around that same idea of interoperability with radically different content. I think @dansup was thinking about it recently IIRC
@liaizon Btw the Mastodon issue for this specific case is https://github.com/mastodon/mastodon/issues/14336 – but it would be nice to have some sort of standard indeed!
@nclm this is so depressing, there is even a PR for it
@nclm hey @tribela I see you are the one who wrote this PR, have you gotten ANY feedback from the mastodon team about it and if not would you like to?
Hey @wolf I see you in the comments for this issue wanting to push it going forward. Are you still motivated to advocate for this change?
@liaizon aye. It’s… a sore spot for me at the moment; I legitimately believe the current behavior kinda screws everyone, I really see no upside in SILENTLY throwing origin content to the floor
@wolf yes I agree. I was just reading the issue thread and sorta can't believe there was a PR just sitting there this whole time that's been ignored.