|
| 1 | +# MSC4356: Recently used emoji |
| 2 | + |
| 3 | +Like other chat platforms, Matrix supports emoji as a way to visually express ideas or emotions. In |
| 4 | +practice, most people use a limited set of emoji only. Since emoji are commonly used as a quick way |
| 5 | +to react to something, it is desirable for clients to offer users shortcuts to their favorite emoji. |
| 6 | +Some emoji picker libraries support this feature by locally tracking emoji usage. This doesn't work |
| 7 | +well in a multi-device environment, however, because such history cannot easily be shared between |
| 8 | +clients. |
| 9 | + |
| 10 | +This proposal introduces a way for clients to maintain a shared storage of recently used emoji to |
| 11 | +enable emoji suggestions across clients. |
| 12 | + |
| 13 | +## Proposal |
| 14 | + |
| 15 | +A new global account data event `m.recent_emoji` is introduced. In `content`, it contains a single |
| 16 | +property `recent_emoji` that is an array where each element is itself an array. The first element in |
| 17 | +this nested array is the emoji, the second element is a counter for how often it was used. The outer |
| 18 | +`recent_emoji` array is ordered descendingly by last usage time. |
| 19 | + |
| 20 | +``` json5 |
| 21 | +{ |
| 22 | + "type": "m.recent_emoji", |
| 23 | + "content": { |
| 24 | + "recent_emoji": [ |
| 25 | + [ "😅", 7 ], // Most recently used, 7 times overall |
| 26 | + [ "👍", 84 ], // Second most recently used, 84 times overall |
| 27 | + ... |
| 28 | + } |
| 29 | +} |
| 30 | +``` |
| 31 | + |
| 32 | +When an emoji is used in a message or an annotation, the sending client moves (or adds) it to the |
| 33 | +beginning of the `recent_emoji` array and increments (or initializes) its counter. |
| 34 | + |
| 35 | +As new emoji are being used, clients SHOULD limit the length of the `recent_emoji` array by dropping |
| 36 | +elements from the end. A RECOMMENDED maximum length is 100 emoji. |
| 37 | + |
| 38 | +Clients MAY freely customise the logic for generating recommendations from the stored emoji. As an |
| 39 | +example, they could select the 24 first (= most recently used) emoji and stably sort them by their |
| 40 | +counters (so that more recently used emoji are ordered first on ties). |
| 41 | + |
| 42 | +## Potential issues |
| 43 | + |
| 44 | +Clients could choose wildly different ways to generate recommendations from the shared storage |
| 45 | +leading to significantly different UX across clients. |
| 46 | + |
| 47 | +## Alternatives |
| 48 | + |
| 49 | +Further metadata such as the concrete access time or the room could be tracked together with emoji. |
| 50 | +It is unclear, however, if this would lead to materially better suggestions, however. |
| 51 | + |
| 52 | +## Security considerations |
| 53 | + |
| 54 | +This proposal doesn't mandate encrypting the `m.recent_emoji` account data event. Since emoji are |
| 55 | +most commonly used in annotations which are not encrypted, servers could already track and abuse |
| 56 | +this information today, however. |
| 57 | + |
| 58 | +## Unstable prefix |
| 59 | + |
| 60 | +While this MSC is not considered stable, `m.recent_emoji` should be referred to as |
| 61 | +`io.element.recent_emoji`. |
| 62 | + |
| 63 | +## Dependencies |
| 64 | + |
| 65 | +None. |
0 commit comments