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.
New Announcement Type
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
A Note should be created for every Repost announcement, even if there is no additional commentary from the reposting user. This allows all Repost Announcements to have a DSNP Content URI. Additionally, important metadata such as the reported time of reposting is in the Note.
In line with changes to Reply Notes, a Repost Note should include "inReplyTo": "{dsnp_content_uri}" for additional validation and clarity of context. (While "inReferenceTo" might be more appropriate, standardizing on a single property to use across the two types feels more useful.)
Relationship to Other Announcement Types
Reposts should be able to reference Broadcast, Reply, or other Repost Announcements. The Reply and Reactoin Announcement definitions should be updated to allow reference to Repost Announcements.
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.
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.
New Announcement Type
Repost:
A Note should be created for every Repost announcement, even if there is no additional commentary from the reposting user. This allows all Repost Announcements to have a DSNP Content URI. Additionally, important metadata such as the reported time of reposting is in the Note.
In line with changes to Reply Notes, a Repost Note should include "inReplyTo": "{dsnp_content_uri}" for additional validation and clarity of context. (While "inReferenceTo" might be more appropriate, standardizing on a single property to use across the two types feels more useful.)
Relationship to Other Announcement Types
Reposts should be able to reference Broadcast, Reply, or other Repost Announcements. The Reply and Reactoin Announcement definitions should be updated to allow reference to Repost Announcements.
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.