Skip to content

MSC4356: Recently used emoji #4356

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

MSC4356: Recently used emoji #4356

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
ad61e4f
MSC4356: Recently used emoji
Johennes Sep 16, 2025
6e1cf39
Add note about the absence of further counter reset mechanisms
Johennes Sep 17, 2025
1ff30d4
Make proposal compatible with MSC4027
Johennes Sep 17, 2025
58d45ad
Specify explicit upper limit of 2^53-1
Johennes Sep 17, 2025
d67a3f8
Remove duplicate "however"
Johennes Oct 20, 2025
594df05
Add guards against counters being too small or too large
Johennes Oct 20, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 65 additions & 0 deletions proposals/4356-recent-emoji.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# MSC4356: Recently used emoji

Like other chat platforms, Matrix supports emoji as a way to visually express ideas or emotions. In
practice, most people use a limited set of emoji only. Since emoji are commonly used as a quick way
to react to something, it is desirable for clients to offer users shortcuts to their favorite emoji.
Some emoji picker libraries support this feature by locally tracking emoji usage. This doesn't work
well in a multi-device environment, however, because such history cannot easily be shared between
clients.

This proposal introduces a way for clients to maintain a shared storage of recently used emoji to
enable emoji suggestions across clients.

## Proposal

A new global account data event `m.recent_emoji` is introduced. In `content`, it contains a single
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

property `recent_emoji` that is an array where each element is itself an array. The first element in
this nested array is the emoji, the second element is a counter for how often it was used. The outer
`recent_emoji` array is ordered descendingly by last usage time.

``` json5
{
"type": "m.recent_emoji",
"content": {
"recent_emoji": [
[ "😅", 7 ], // Most recently used, 7 times overall
[ "👍", 84 ], // Second most recently used, 84 times overall
...
}
}
```

When an emoji is used in a message or an annotation, the sending client moves (or adds) it to the
beginning of the `recent_emoji` array and increments (or initializes) its counter.

As new emoji are being used, clients SHOULD limit the length of the `recent_emoji` array by dropping
elements from the end. A RECOMMENDED maximum length is 100 emoji.

Clients MAY freely customise the logic for generating recommendations from the stored emoji. As an
example, they could select the 24 first (= most recently used) emoji and stably sort them by their
counters (so that more recently used emoji are ordered first on ties).

## Potential issues

Clients could choose wildly different ways to generate recommendations from the shared storage
leading to significantly different UX across clients.

## Alternatives

Further metadata such as the concrete access time or the room could be tracked together with emoji.
It is unclear, however, if this would lead to materially better suggestions, however.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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]
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Security considerations

This proposal doesn't mandate encrypting the `m.recent_emoji` account data event. Since emoji are
most commonly used in annotations which are not encrypted, servers could already track and abuse
this information today, however.

## Unstable prefix

While this MSC is not considered stable, `m.recent_emoji` should be referred to as
`io.element.recent_emoji`.

## Dependencies

None.