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.
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:
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
References
Any references or other related links that might be helpful.
Copyright
Copyright and related rights waived via CC0.