DIP-290 Reposting

[wesbiggs]

Abstract

Provide a facility for one user to repost (share, highlight) another user's content in their own content stream. The ensuing thread is separate from the thread of the shared item.

Additional goal: Make it easy for a user to tell if their content has been reposted (i.e. without having to retrieve all content). Enable accurate counting of public reposts.

Solution:

New Announcement type for Repost:

• announcementTypeId: enum
• fromId: user doing the sharing
• targetContentURI: DSNP Content URI of the post being shared
• url: of sharer's comment Note
• contentHash: of sharer's comment Note

In line with changes to Reply Notes, a Repost Note should include "inReplyTo": "{dsnp_content_uri}" for additional validation and clarity of context.

Motivation

This is a popular feature on social networks and allows a conversation that started with one set of users to be discovered and/or discussed by a second set of users. It gives the reader the ability to jump to the canonical content item that was originally posted if desired.

Specification Pull Request

Current change pull request: TBD

Rationale

Why were the design choices made? What other solutions were rejected and why?

Could have added an optional field to Broadcast. In general we try to avoid optional fields and types with variable semantics.

Could have just included the full text of the original in the share Note. This would not allow for easy counting of shares, and provides no authenticity guarantees or help to user agents.

Could have added a new type of attachment or special property within a note to declare the shared post. Again does not allow for easy discovery/counting of shares.

Backwards Compatibility

Any proposal that breaks compatibility with previous versions must describe how the change will be implemented and handle the migration period.

Because this is a new Announcement Type clients will have to be updated to "see" it (and might see Replies that reference it and have trouble finding a home for them).

Reference Implementation and/or Tests

What could this look like implemented or what tests could be provided to assist in validation of implementations?

Security Considerations

Any change will effect the security of the system in some way. Describe the implications this DIP on security, both technical and human.

Dependencies

• List of dependent DIPs if any.

References

Any references or other related links that might be helpful.

Copyright

Copyright and related rights waived via CC0.

[wesbiggs]

Community Call notes 2024-11-07

• Concerns about the amplification of unverified content / disinformation, incitement to violence
• Is a "community notes" type of solution useful or would it be ignored by the intended audience?
• Can we define best practices (e.g. introduce some friction) that help promote pro-social behavior at the application level?
• Users are used to and want this behavior; the community would come up with an approach/workaround if these mechanisms are not in the protocol itself
• Promotion and virality of content are at a different layer from the protocol

Types of usage seen:

• Repost with no additional content
• Repost with commentary - text above/below
• Repost with commentary interwoven/embedding

Technical approach:

• Do we need convention or restrictions on whether or how deep repostings can be reposted?
• What types of Announcements can be reposted?