Background
#880 Tried to introduce protocol-level changes on emoji-reaction, and that's quite not backward compatible and requires major fw changes in core. And that's likely to take years to get approval and implmented.
Proposal
To keep things moving a little big faster, this proposal suggesting impl the emoji-reaction purely on the client side as extension to the existing @[Name] convension.
Option 1: reply with message hash @[Name] r:[hash]:[emoji] eg @[Alice] r:a1b2:👍, this guarantee certain level of uniqueness and a consistent short payload.
Option 2: reply with truncated context message @[Name] r:[truncated mes]...:[emoji] eg @[Alice] r:I like meshco...:👍, this sacrifice the uniqueness and payload length but more human friendly for clients that doesn't impl this proposal.
Implementation and fallbacks
This proposal is client side only and can fallback to some kind of human-based eye parsers. Client could identify this message with regex, then do a reverse message matching to locate the corresponding message. Draw reaction (optionally with counter), and reaction sender could use visual identification (maybe circle/bold/underline?) on ACK.
Background
#880 Tried to introduce protocol-level changes on emoji-reaction, and that's quite not backward compatible and requires major fw changes in core. And that's likely to take years to get approval and implmented.
Proposal
To keep things moving a little big faster, this proposal suggesting impl the emoji-reaction purely on the client side as extension to the existing
@[Name]convension.Option 1: reply with message hash
@[Name] r:[hash]:[emoji]eg@[Alice] r:a1b2:👍, this guarantee certain level of uniqueness and a consistent short payload.Option 2: reply with truncated context message
@[Name] r:[truncated mes]...:[emoji]eg@[Alice] r:I like meshco...:👍, this sacrifice the uniqueness and payload length but more human friendly for clients that doesn't impl this proposal.Implementation and fallbacks
This proposal is client side only and can fallback to some kind of human-based eye parsers. Client could identify this message with regex, then do a reverse message matching to locate the corresponding message. Draw reaction (optionally with counter), and reaction sender could use visual identification (maybe circle/bold/underline?) on ACK.