Emotes: Short for emoticons, a shortcode/image pair that are used inline in messages and in reactions.
Emojis: Shortcode/image pairs with unicode representations. Currently supported in most clients. A subset of emotes.
Shortcode: A short piece of text surrounded in colons to represent an emote/emoji. Ex. :shortcode:
Every emote proposal uses a shortcode and a way to store the image and make the client render it.
Under this proposal they are not sent in the message source as img tags, which is what many non-Element clients use.
In this proposal, the message source is not edited and it is sent as a shortcode. Rather, it is up to the client to
load it when rendering messages.
In the current implementation/proposal it is rendered in the message html as follows:
<img class="mx_Emote" title=":shortcode:" src="blob:https://example.com/blob-guid">This is similar to current implementations in structure, but rather than having clients render img tags
from the message source they are added during construction of the message html. Encrypted rooms can use the blob obtained after decryption
while unencrypted ones can directly use the mxc url.
Room emotes are per-room emotes that are defined in an m.room.emotes event. They can be uploaded from the room settings by moderators or above. The emotes are defined inside of a dict which has the shortcode as a key and the either encrypted or unencrypted source for the emote as a value.
For encrypted rooms the m.room.emotes event follows the format:
{
"content":{
"short": IEncryptedFile (a json object with information on how to decrypt the file)
}
}
For non encrypted rooms the m.room.emotes event follows:
{
"content":{
"short": “mxc://abcdefg”
}
}
Note: this format could be modified, but would have to be agreed upon so the clients can load the emotes in properly.
Other proposals regarding this issue: MSC2545 and MSC1951
Below is a comparison highlighting the differences between this and other proposals.
Emotes in private rooms can be encrypted so that potentially sensitive data is not publicly available to server members.
Emotes in public rooms are necessarily unencrypted.
One important note is that although emotes are encrypted they are available to anyone in the private room, and server
admins can see the emotes in the room state so they are not e2ee like messages.
If the file keys or room state is encrypted MSC3414 and if server admins lose the ability to join any private room
it would then be e2ee.
The current advantage is that the emotes will not be obtainable for other users on the server who are not in the private room.
The client does not edit the actual sent message but renders emotes locally. Leaving the message source untouched
could be helpful for future updates or deleting emotes/changing the way emotes are rendered.
Current implementations use data-mx-emoticon types in the img tag. This uses the mx_Emote class name although that
could also be changed since it is rendered locally.
Compatibility with other MSCs: Although certain aspects of other MSCs cannot be kept the same, many general ideas from
those could be carried over.
It might be possible to implement this in public rooms if the client pulls every user’s public emote data to load.
Generally, however, user specific emotes goes against the idea of emotes being a shared set of images.
Additionally, user specific emotes could be handled by sending image data in the message json, but that would be
separate from room emotes as defined in this proposal since room emotes should update when the room settings are updated.
Requires existing clients to change their implementations.
This could be extended to spaces although the main current implementation does not have this.
Spaces would take priority over individual room emotes if there is a shortcode clash.
Add custom emotes for reactions and the emoji picker.
Other MSCs introduced the idea of shareable packs. This could be compatible with image packs except for encrypted rooms.
It would be simpler to allow users to download a zip file of all the emotes in a room.