MSC4356: Recently used emoji

[Johennes]

Rendered

Implementations:

• element-hq/element-web@a7f92f3
• feat: Add Element recent emojis for shared emoji reactions matrix-rust-sdk#5641

[bmarty]

I know that the plural form of emoji can be emoji but to avoid confusion, maybe using m.recent_emojis help to clarify that we have a list of emojis?

[anoadragon453]

Client developers should be able to determine the type of a field from the spec, rather than relying on the field name.

As a native English speaker, recent_emoji sounds best to me.

[anoadragon453]

Thanks for writing this up! 😁

[anoadragon453]

Client developers should be able to determine the type of a field from the spec, rather than relying on the field name.

As a native English speaker, recent_emoji sounds best to me.

[anoadragon453]

One alternative would be to structure m.recent_emoji as the following:

"recent_emoji": {
  "😅": {
    "last_used": 10000000,
    "count": 7
  },
  "👍": {
    "last_used": 20000000,
    "count": 84
  }
}

where e.g. 10000000 is a unix timestamp of the last time the emoji was used.

• A dict would allow a client to access the attributes of a given emoji more efficiently than an array.
• Documenting when the emoji was last used can be helpful. If it wasn't used for a long time, a client could drop the emoji from the list; even if it had been used many, many times in the past.

To save bandwidth, this could instead be represented as:

"recent_emoji": {
  "😅": [10000000, 7],
  "👍": [20000000, 84]
}

[Johennes]

Are you suggesting to add this to the (discarded) alternatives or to use this instead of the current scheme? At the moment, this proposal simply captures what some of Element's clients had implemented previously.

I personally like using objects for the emoji properties, as in your variant, because that makes the semantics of the different values more explicit. I suspect that with request compression, it should have a negligible impact on bandwidth.

For the outer structure, an array, as in the current proposal text, would have the benefit that it automatically stays ordered by last usage time. Then again, the set of tracked emoji will probably be relatively small. So this optimization might be superfluous.

[Johennes]

To illustrate what this change would mean for the current implementations: Element Web currently generates suggestions by taking the first 24 array elements (meaning the 24 most recently used emoji), then stably sorts that list by usage count.

With the alternative suggested above, this logic would require a sort of the entire set by last_used, truncating the result at a length of 24, then stably sorting the remainder by count.

Also for illustration: My own io.element.recent_emoji event currently contains 52 elements only (Element Web allows for up to 100). If this is representative, any performance considerations might be moot.