search

swicg / general

General issue tracker for the group
https://www.w3.org/community/swicg/
43 stars 2 forks source link

inline attachment indicator #20

Closed ghost closed 6 years ago

ghost commented 6 years ago

This seems to come up a lot in cross-network federation so there should be some clarity. A content viewing application has no immediate indication whether a media attachment was meant to be displayed inline or is already displayed inline - in which case displaying it inline would duplicate the media. Different projects treat media completely different in this regard. Mastodon and GNU-Social have traditionally provided images separate from content, while Friendica, Diaspora et al include images within the content markup. Friendica and Hubzilla also provide attachments but these aren't normally intended to be inlined. It would be most valuable to have a hint in a media attachment that it is intended to be added to the content (inline) or was specifically intended to be an attachment (attachment) for data transfer or other reasons. Such an indicator ideally would use the same overall semantics as the MIME Content-Disposition or at a minimum provide a boolean 'inline' indication. Without such indication, the presentation of media in posts will vary greatly by message source and destination. With such an indication, most media will be presented uniformly on any platform no matter what assumptions the provider makes for its own content.

nightpool commented 6 years ago

This feels duplicative with actually having the image in the markup. Shouldn't you just not show it if it is referenced somewhere by the markup? Conversely, if you don't support images inside of markup, shouldn't you just show all attachment images—whether they have the inline modifier or not?

On Mon, Sep 11, 2017 at 4:21 PM Mike Macgirvin notifications@github.com wrote:

This seems to come up a lot in cross-network federation so there should be some clarity. A content viewing application has no immediate indication whether a media attachment was meant to be displayed inline or is already displayed inline - in which case displaying it inline would duplicate the media. Different projects treat media completely different in this regard. Mastodon and GNU-Social have traditionally provided images separate from content, while Friendica, Diaspora et al include images within the content markup. Friendica and Hubzilla also provide attachments but these aren't normally intended to be inlined. It would be most valuable to have a hint in a media attachment that it is intended to be added to the content (inline) or was specifically intended to be an attachment (attachment) for data transfer or other reasons. Such an indicator ideally would use the same overall semantics as the MIME Content-Disposition or at a minimum provide a boolean 'inline' indication. Without such indication, the presentation of media in posts will vary greatly by message source and destination. With such an indication, most media will be presented uniformly on any platform no matter what assumptions the provider makes for its own content.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/swicg/general/issues/20, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV1d1SlpfuwqbbgEx_nLUa-G7uUDAks5shZZZgaJpZM4PTt6P .

ghost commented 6 years ago

The first bit is what we're currently doing. One issue is with the second part.

if you don't support images inside of markup, shouldn't you just show all attachment images—whether they have the inline modifier or not?

On networks which do support images/media inside markup, attachments are often used to specifically indicate that this is not intended to be inlined, perhaps due to NSFW issues. So the network that doesn't support images in markup ends up with something that was not intended by the sender. And if parsing content is required to find out if an attachment was referenced therein, shouldn't this be specified somewhere?

There is a third issue. Currently we are required to actually strip images from inlined content on OStatus and turn them into attachments because otherwise they are not shown (at all) on some providers. With ActivityPub we can't really do this at a network driver level, but must then analyse what software the recipient is running.

It would be the best of all worlds to include media in the content to begin with because then we could provide narrative around multiple media elements. We will always lose some context if forced to break up our content. It can also make signing problematic if the content was signed by an author on a different provider and relayed as a comment by another provider. This isn't hypothetical - we deal with this issue every day.

I see a few possibilities. There may be others.

  1. Make inline media a requirement (third party signatures from converted content may be invalidated)
  2. Allow inline media even if your service doesn't generate it. Services would be required to check each attachment to see if it is inlined already.
  3. Make attached media a requirement. (Some converted content will lose context and third-party signatures may be invalidated).
  4. Provide an 'inline' flag to indicate attached media that should or shouldn't be inlined.

Number 2 and number 4 (together) would be an ideal outcome. Number 4 was proposed on its own because I don't believe achieving consensus on any of the others is a realistic possibility.

ghost commented 6 years ago

Looks like we'll be using type 'Article' for multi-media content and abandoning the 'Note' type, even though there are no specific inline media restrictions imposed by the AS spec. These are only imposed by individual projects; and changing behaviour based on server/platform detection is unpalatable. We may or may not offer the option to downgrade content to a 'Note' based primarily on whether we can do this without context loss and provided the content was authored by a local channel (so there are no signature issues downgrading the content). If we cannot downgrade or the content author doesn't allow downgrading, the content will be sent as an 'Article'.

We will attempt to reconstruct multi-media posts from any Note content with media attachments to the best of our ability but prefer the 'Article' type in all cases; as it is not constrained by monoculture platform policies and third-party signatures will validate.

Closing.