Update the Reaction Announcement to have a revoke bit flag and remove it from being targeted by Tombstones.
Motivation
This comes out of discussion of DIP-#145.
DIP-145 forces a change in Tombstones, but that change is made more difficult by reactions being tombstoned.
When looking at options for tombstone changes, it was discovered that altering reaction retraction may be worthwhile either way.
Specification Pull Request
Current change pull request: #173
Rationale
One of the categories of announcements we have is this: Ones that have a link to external content and ones that do not.
Reactions are the only announcement type that does NOT link to external content that can be Tombstoned.
Second, this change should increase the resolution speed of Reactions as one does not need to check each reaction for a tombstone.
Instead all reactions and retractions are associated at the same level.
Alternatives:
Keep using Tombstones
See DIP-145 discussion
An announcement type specifically for reaction retraction
That's a lot of additional searching
Not allowing retraction
We want users to be able to make mistakes because we do.
Resolution Pattern Notes
How do we want to resolve if someone has or has not reacted?
Assumption: No user may use the same reaction more than once per item to react to.
Accepted: Option 1: Time Based State Transition
This follows the pattern for graph. Merely play through the reaction announcements in order ignoring duplicates and assuming that one cannot retract before one reacts.
This could also be referred to as "Final Answer Wins" as the result is the same.
So a user reacting:
+ => Yes
+ - => No
+ - + - => No
+ - - + => Yes
+ - - - => No
- - - + => Yes
+ + + - => No
Rejected: Option 2: Time Independent Counting
This is a simpler resolution in that it is not time dependent.
Merely count the number of reactions and the number of retractions per user per reaction. If the reaction count is greater than the retraction count, then it is a (single) reaction.
So a user reacting:
+ => Yes
+ - => No
+ - + - => No
+ - - + => No
+ - - - => No
- - - + => No
+ + + - => Yes
Backwards Compatibility
This is a breaking change for the reaction announcement type.
We could just deprecate the current Announcement Type Enum and create a new one, but we have a collection of breaking changes for v1.1 (DIP-145 for example), and this could be included with those.
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
The primary potential issue is that of lazy resolution of reactions.
Instead of properly matching reactions and retractions by following the algorithm for resolution, code might just assume that no one will duplicate or redact a reaction that was not posted and just do a summation of the reactions.
Such code would allow for a user to lower the correct reaction count.
Abstract
Update the Reaction Announcement to have a revoke bit flag and remove it from being targeted by Tombstones.
Motivation
This comes out of discussion of DIP-#145. DIP-145 forces a change in Tombstones, but that change is made more difficult by reactions being tombstoned. When looking at options for tombstone changes, it was discovered that altering reaction retraction may be worthwhile either way.
Specification Pull Request
Current change pull request: #173
Rationale
One of the categories of announcements we have is this: Ones that have a link to external content and ones that do not. Reactions are the only announcement type that does NOT link to external content that can be Tombstoned.
Second, this change should increase the resolution speed of Reactions as one does not need to check each reaction for a tombstone. Instead all reactions and retractions are associated at the same level.
Alternatives:
Resolution Pattern Notes
How do we want to resolve if someone has or has not reacted?
Assumption: No user may use the same reaction more than once per item to react to.
Accepted: Option 1: Time Based State Transition
This follows the pattern for graph. Merely play through the reaction announcements in order ignoring duplicates and assuming that one cannot retract before one reacts.
This could also be referred to as "Final Answer Wins" as the result is the same.
So a user reacting:
+
=> Yes+ -
=> No+ - + -
=> No+ - - +
=> Yes+ - - -
=> No- - - +
=> Yes+ + + -
=> NoRejected: Option 2: Time Independent Counting
This is a simpler resolution in that it is not time dependent. Merely count the number of reactions and the number of retractions per user per reaction. If the reaction count is greater than the retraction count, then it is a (single) reaction.
So a user reacting:
+
=> Yes+ -
=> No+ - + -
=> No+ - - +
=> No+ - - -
=> No- - - +
=> No+ + + -
=> YesBackwards Compatibility
This is a breaking change for the reaction announcement type.
We could just deprecate the current Announcement Type Enum and create a new one, but we have a collection of breaking changes for v1.1 (DIP-145 for example), and this could be included with those.
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
The primary potential issue is that of lazy resolution of reactions. Instead of properly matching reactions and retractions by following the algorithm for resolution, code might just assume that no one will duplicate or redact a reaction that was not posted and just do a summation of the reactions. Such code would allow for a user to lower the correct reaction count.
Dependencies
None
References
The pattern follows that of https://github.com/LibertyDSNP/spec/blob/c493f78bc751764830948624b6890d2c52fda40c/pages/DSNP/Graph.md
Copyright
Copyright and related rights waived via CC0.