Closed matrixbot closed 5 years ago
Jira watchers: @ara4n
(might be also good to be able to filter on vote count, too, to implement reddit/slashdot style thresholding)
-- @ara4n
I would really like this feature implemented.
A trivial solution compatible with end-to-end encryption would be to send an event with a special msgtype and a reference to the "liked" event_id:
{
"msgtype": "m.reaction",
"ref_event_id": "$1474582900147371glwtU:matrix.org",
"body": "+1"
}
One downside is that retrieving all reactions requires parsing all the events that are more recent. This would be inefficient for very old messages. In those situations clients can load all reactions only if explicitly requested by the user.
Do you see any major drawback with this approach?
Alternatively, a new client-server API method could be added:
PUT /_matrix/client/r0/rooms/{roomId}/reaction/{refEventId}/{txnId}
{
"msgtype": "m.reaction",
"body": "+1"
}
Since the refEventId
is in the URL and not in the payload, it can be seen by the server even with E2E, and used to create an index of the reactions to each event that would be sent along with each event when syncing.
This still requires that the server sends reaction updates in order for clients to update the UI with new reactions to messages that were already synced.
The idea of having 'reaction' traffic rank below normal federation traffic seems like a pretty decent solution to the "5M+ Likes" problem, if there was a way to have clients/HS de-prioritize reactions/votes in general and/or do some sort of bulk-packaging/delayed processing that could maybe help the reaction/vote system scale?
@pik offered some proposals which might help implement this: https://github.com/matrix-org/synapse/pull/1633
So one way of solving the "5M+ Likes" problem could be to use interactive ZK proofs to avoid servers having to replicate all the reaction objects between each other. It could go something like this:
Alternatively, one could go the whole hog and use ZK-SNARKs or even ZK-STARKs, but I'm not convinced the ability to provide succinct non-interactive proofs is that useful here, given Matrix is already interactive by default, and the simpler merkle-tree model is much easier to reason about - plus we have all the code hanging around already.
Hi! By any chance any update on this? Would love to have reactions in matrix, as it's a feature I often have questions about from former discord/slack users :)
so this has been obsoleted by #1849, which has been implemented in synapse and riot develop branches behind labs flags, and largely looks to be working.
Documentation: https://docs.google.com/document/d/1CnNbYSSea0KcyhEI6-rB8R8u6DCZyZv-Pv4hhoXJHSE/edit Author: @pik Shepherd: @ara4n Date: 25/12/2016 See also: https://github.com/matrix-org/synapse/pull/1633
Currently we have no good way to model 'voting' metadata about messages (e.g. FB likes or Reddit/Slashcode up/downvotes). The best we can do is to synchronise around 'update' messages in the v2 CS-API - this could get very noisy and heavyweight for a typical FB-style "1M likes!" scenario.
We could help mitigate this by coalescing certain updates into the original event - both for server->client and server->server synchronisation. However, this can never work in an E2E crypto world (unless we don't encrypt the vote, which doesn't seem great). Worth noting that an E2E room with lots of participants becomes increasingly insecure to the point that it might as well not be E2E, as the room is only as safe as the security of the clients connected to it, so we might be able to sidestep this in practice somehow. Alternatively, we could try to fix the scalability implications of syncing all these 'like' events by somehow QoSing them: federating them at lower priority; having them semi-ephemeral and parented only to the event they describe to avoid disrupting the main message graph; putting them in a separate message graph; etc.
In a non-e2e world, we could coalesce... I believe having a HS say "150 users Liked this message" is no more open to abuse than trusting a HS to accurately report /any/ message from its users. But then we need a mechanism to de-coalesce on demand (e.g. to actually start paginating through the list of 1M users who hit 'Like').
(Imported from https://matrix.org/jira/browse/SPEC-135)
(Reported by @ara4n)