Discussion: Should media content have DSNP Content URIs?

[wesbiggs]

By including the URL of attachments in ActivityContent Notes we force URL changes to attachments (caused, for example, by changes to the hosting provider) to trigger content hash changes for the Note, and client apps to infer that content has been altered even if it has not. A possible fix for this is to require separate announcement of blobs/media, which would allow them to be assigned a DSNP Content URI; we would then reference that as the attachment address.

This approach aligns with atproto, where "blobs" are always referenced by URLs based on their CID.

Pros: Better ability to track and reuse assets, more stability of content URLs that reference these assets.

Cons: Additional announcement type for clients to process and manage, DSNP URL scheme less immediately interoperable with other ActivityStreams clients.

[wesbiggs]

Notes from Community Call 2025-03-06:

• Requires media objects to be tracked so updates can be discovered
• Tradeoff between immutability and updateability and how these changes should be reflected in the user experience
• Pre-existing reactions, replies, etc. create more complexity in handling update cases (to either a Note or a media object)
• "If you can't fix it, feature it" implies responsibility at the app level to highlight questionable provenance, etc.
• Proposal applies to "uploaded" media objects only, not "pure" links to URLs
• The cost to systems to parse a content thread is increased by this approach; increases the minimum viable solution architecture for applications
• In general, we prefer simplicity in the specification and ease of use from a systems point of view