Aggregations (experimental) #1633

pik · 2016-11-19T14:27:34Z

Matrix is currently missing an implementation/spec for processing Aggregation type events.

This includes some functionality necessary and expected by users from a chat client, such as being able to edit a message or add a reaction a to a message sent by another user.

While it's possible to implement said functionality as direct and hard-coded endpoints, this would have a number of drawbacks:

Specs are hard to alter without breaking things, the more exact the standard, the less maleable to future needs
Specing hard-coded suppport for a function such as 'message edit' does not provide anything for users wishing to have richer client experiences (emoji reactions)
Specing hard-coded support for a particular kind of aggregation is restrictive and still provides nothing for users of Matrix/Synapse as a federate-distributed message log rather than as a chat client.

This is a stab at an open-ended aggregation approach:

Experimental for soliciting feedback (not intended to be merged in current state).
Only works with postgresql backend atm because of different semantics between sqlite3 and postgresql JSON operations.

Currently the following is functional:

A room creator can POST an aggregation_spec to /room/(?P<room_id>[^/]+)/aggregation$
Synapse will process aggregation type events 'm.room._aggregation' in the background and fill in information for the target_id in the aggregation_entries table.
append and replace type operations are supported e.g. emoticon support to a room could be added by
the room creator POSTing the following:

emoticon_aggregation_spec = {
    'constraints': [],
    'aggregation_event_name': 'm.room._aggregation.emoticon',
    'aggregation_field_names': ['emoticon'],
    'aggregation_type': 'append',
    'aggregation_event_schema': {
        'type': 'object',
        'properties': {
            'emoticon': { 'type': 'string' },
            'msgtype': { 'type': 'string' },
            'target_id':  { 'type': 'string' }
        },
        'required': ['emoticon', 'msgtype', 'target_id'],
        'additionalProperties': False
    }
}

This in turn would cause Synapse to run background_updates which will process 'm.room._aggregation.emoticon' type events and append them to an array in the aggregate_entries table e.g.:

target_id        | $14794019940aHDNb:pik-test
room_id          | !QKscJgkpWveOZhvGME:pik-test
event_name       | m.room._aggregation.emoticon
latest_event_id  | $14794147870yHlCA:pik-test
aggregation_data | ["{\"emoticon\": \"::smile::\", \"event_id\": \"$14794020481Zmmku:pik-test\", \"sender\": \"@pik:pik-test\"}", "{\"emoticon\": \"::flowers::\", \"event_id\": \"$14794022480fdPPD:pik-test\", \"sender\": \"@pik:pik-test\"}"]

When retrieving events for a client Synapse LEFT JOINS on the aggregation_entries table and send a single bulk entry for each target_id e.g.

In [354]: cli.api._send("GET", "/events/%s" % '$14796538688CLcYU:pik-test')
Out[354]: 
{'age': 6149350,
 'aggregation_data': {'m.room._aggregation.emoticon': {'aggregation_data': ['{"emoticon": "::smile::", "event_id": "$14796538949JTYis:pik-test", "sender": "@pik:pik-test"}'],
   'latest_event_id': '$14796538949JTYis:pik-test'}},
 'content': {'body': 'hello world', 'msgtype': 'm.text'},
 'event_id': '$14796538688CLcYU:pik-test',
 'origin_server_ts': 1479653868980,
 'room_id': '!DNrCCfWAYShGxMhnzw:pik-test',
 'sender': '@pik:pik-test',
 'type': 'm.room.message',
 'unsigned': {'age': 6149350},
 'user_id': '@pik:pik-test'}

TODO

Clean Synapse API Implementation

There are a number of approaches to returning 'aggregated' events depending on whether they are pruned from the events table or not in the database. While the client when receiving a set of bulk events for a target_id will always have a latest_event_id used in the aggregation and would know to ignore events prior to this, it would be preferable to not send those events at all to the client after they have been aggregated. This should mean either filtering the retrieved event array (e.g comparing to a cache of already known aggregated values) or pruning the aggregated events from the events table in the db entirely.

Emoticon / Edit support in vector-web (riot) client.

This is a little bit complicated because the client should support both receiving bulked (aggregated entries) and singular events (for singular events it should imitate the server aggregation strategy).

matrixbot · 2016-11-19T14:27:35Z