Possibility to define our own emoji

[floviolleau]

I would like to have the possibility to add my own emojis.

Could you please add this feature?

Kind regards

[ara4n]

this is also related to being able to send custom stickers

[ara4n]

see also element-hq/element-web#1692

[Gregoor]

I could work on this, store stickers only locally for now?

[ara4n]

That would be great! Could send stickers as data URLs, or upload them to your homeserver and refer to them via mxc:// URLs.

[Gregoor]

Since there is no method of listing uploaded media (and thereby retrieving stickers on the server), I'd just go with data URLs for now, as it's simpler.

[turt2live]

For those interested: I've started a proposal on this area (including stickers). Feel free to leave comments and suggest alternative ways to do this. The MSC (matrix spec change) can be found here: matrix-org/matrix-spec-proposals#1256

[BloodyIron]

One of the challenges I see with custom emoji is that not all phones/mobile devices/etc will necessarily be able to display them inherently, as that would go outside of unicode. So, this would be uniquely tied to Riot.

Mind you, I don't want to shoot this idea down, I just want to point out that emoji are primarily made possible due to unicode standardisation of them.

[CPCer]

2 years have gone...

[apiontek]

Work is being done per MSC1951 -- I'm not involved, just passing along the info.

[aaronraimist]

This doesn't need an old-composer label

[beardedlinuxgeek]

Nothing to add other than this is the main feature my users are requesting. I think stickers are not so valuable, but custom emojis dominate discord. They are used for polls, calendars, sign ups, and more. A very important feature.

[JimmyCushnie]

There are many custom emotes that have become part of my daily vernacular on Discord, and it's often jarring when I can't use them in Matrix. For instance, there are often moments in conversation where it is appropriate to dab. On Discord, I select one out of a dozen or so custom dab emotes and react to a message with it. In Matrix, all I can do is send a message with the text dab. This works, but it has a very different feel and effect on the flow of conversation.

In my circles, at least, custom emotes have become an integral part of the way online communication happens. Language is constantly evolving, and I think it's important for any chat app to stay on top of that evolution; to enable, not hinder, the way its users communicate.

[apiraino]

fwiw I kind of circumvented this limitation by posting a tiny PNG (~100x100) on a test room, get the JSON source of that message, grab the media URL and script a bot with a "bang shortcut" (example !hey) to post that media item again. Invite the bot and tell it to post that PNG for you.

pros: done in 2 hours. fine for a very limited set of custom emoji.
cons: ugly. a lot of messages from a bot. separate messages to express the emoji, renders bad on mobile element.io android client

[chr-1x]

This is the number 1 thing keeping Element feeling like a second-class chat client for me. Custom emoji are a big part of community culture on places like Discord, Slack, and Mastodon, and missing them makes it feel less like a place where friends hang out and more like a last-ditch communication channel.

It's especially disheartening to not see this anywhere on the roadmap considering how long it's been open. I realize FTUE is a huge deal, and stuff like that and the community redesign are probably taking priority, but it would be nice to see this somewhere on the roadmap. Attracting users and communities will only go so far if you can't retain them, and I feel like this would go a long way towards improving the element community experience that will keep people using the platform.

[Roxxers]

I don't want to sound whiny but honestly I am pretty disappointed the dev team have dragged their feet on this request. It is something that is a staple in online communication platforms right now that are widely used. Discord, Mastodon, Slack, Telegrams much better sticker implementation.

I am unable to run Riot and Matrix as a protocol as a daily driver because actually being able to express myself on other platforms to my friends is much more free-ing. Of course I hate using non-FOSS applications for this (excl Masto). I would be able to convince so many friends to use Riot with this simple feature added. If you want to actually gain users from places like Discord you have to offer feature parity as well, not just better security.

I've seen chatter about other clients but if someone is running a more IRC like client for Matrix, this feature is not for them. Same with the stickers inclusion though, it is a mostly graphical implementation that has to load a remote-ish image. This could also be circumvented by the emojis themselves being hosted on HS's. If stickers are included in the default experience, I see no reason not to add this feature. They are almost one in the same in terms of backend and how they are presented to the user.

[andrewshadura]

@Roxxers, one does not simply implement custom emoji. It has to be defined in the spec and then implemented. The spec is still being discussed in MSC 1951.

[Roxxers]

@Roxxers, one does not simply implement custom emoji. It has to be defined in the spec and then implemented. The spec is still being discussed in MSC 1951.

I was going to add this to my comment, since I know it does need to be in the spec. But most of my comment still applies to that. It's not been discussed in many months, its been open for 1 and a half years. Its still dragging its feet. It has issues both for the spec and the web client implementation, yet is not on any roadmaps? No one seems to want to comment on these issues in months? Everyone I've talked to in my communities wants this feature yet no work seems to actually be going into including it into the spec. Yes its anecdotal but it's not like people are doing empirical polls on how much people want this feature for me to cite.

[williamkray]

@Roxxers, one does not simply implement custom emoji. It has to be defined in the spec and then implemented. The spec is still being discussed in MSC 1951.

I was going to add this to my comment, since I know it does need to be in the spec. But most of my comment still applies to that. It's not been discussed in many months, its been open for 1 and a half years. Its still dragging its feet. It has issues both for the spec and the web client implementation, yet is not on any roadmaps? No one seems to want to comment on these issues in months? Everyone I've talked to in my communities wants this feature yet no work seems to actually be going into including it into the spec. Yes its anecdotal but it's not like people are doing empirical polls on how much people want this feature for me to cite.

if you're impatient, fluffychat and perhaps other clients already support this, you can just direct those people who don't want to wait to use them.

[nourkagha]

Any further updates on this? Would love to be able to make private rooms and communities feel more like personalised spaces.

[Johennes]

Everyone, let's please stay on topic here.

We don't currently have custom emoji on our own roadmap. I agree that we've done a poor job in managing community contributions around this in the past and I understand everyone's frustration about it.

The most recent contribution (matrix-org/matrix-react-sdk#9240) has been blocked on spec alignment as we don't think it's using the right technical approach. The author has since seemingly abandoned it.

If anyone is still interested in working on this, here's a proposal that hopefully allows us to make progress:

• Base your work on MSC2545. The SCT are planning to discuss custom emoji for v1.9 which is due in November but this proposal seems well received so far. As far as I understand, it was also already implemented by other clients.
• Start with just the sending part. We are planning to make changes around the room settings which could complicate finding a solution for how to configure custom emoji. Smaller PRs that separate concerns are also generally preferable.
• Put your work behind a labs flag
• We require 80% test coverage but if you'd first like to get agreement on the code and UX, it's ok to add the tests to your PR later

The, unfortunately, abandoned matrix-org/matrix-react-sdk#8087 might serve as inspiration.

[JiffyCat]

It's really not that hard to make one comment explaining why you "feel" the 9240 PR is unsafe here since it's so closely tied to MSC3982. Will you respond if I @ you on MSC3982 with the exact same question?

Instead of deciding based on your own feelings, you can let users try both approaches in labs and figure out what they like.
MSC2545 is also "unsafe" since all emote images are publicly available as mxcs regardless if the room is encrypted or not.

[Johennes]

As I mentioned in my initial response on matrix-org/matrix-react-sdk#9240, the problem we're seeing is that the rendering happens exclusively on the receiving side. That means it's possible for the image behind a short code to change after your message was sent, altering it's meaning and intent.

As also mentioned in that same response, we would reconsider this if the SCT decided to accept MSC3892. If you're interested in arguing for this way, I'd suggest you to engage with the spec process. There is also nobody stopping you from implementing MSC3892 in another client. But, unfortunately, we're not interested in doing so within Element at this time.

[nmscode]

As I mentioned in my matrix-org/matrix-react-sdk#9240 (comment) on matrix-org/matrix-react-sdk#9240,

You just said "This creates a rather large vector for abuse" in that message which was unclear.

That means it's possible for the image behind a short code to change after your message was sent, altering it's meaning and intent.

Now we know the reason. I already responded to this concern in matrix-org/matrix-react-sdk#9240 (comment) and have already stated that I think it should be up to the user to decide if this is an issue. Room admin can also delete messages which can alter the meaning behind what you send. That feature is still allowed though. The larger issue in the theoretical case you presented is that you have a rogue room admin. A rogue room admin presents much larger issues than emotes being changed.

There is also nobody stopping you from implementing matrix-org/matrix-spec-proposals#3892 in another client. But, unfortunately, we're not interested in doing so within Element at this time.

Element is a company and thus your product team has final say on this. If it will not be allowed in Element I understand.

I will say, however, that I find this concern to be quite selectively applied. The MSC2545 problem is also a security/privacy issue that concerns user safety. It is odd that one is allowed to go through while the other is unequivocally blocked. Other clients adopting it does not fix the issues. The MSC team dragged their feet on this, which is why clients adopted the available MSC at the time. Using that as a justification is circular reasoning.

[Johennes]

Thank you for linking it and explaining your reasoning again. I don't think we'd want for the user to decide whether this is an issue or not because most users will probably neither foresee nor understand this. It's true that MSC2545 has shortcomings as well but they seem smaller. Reactions are already unencrypted today, for instance. Accepting one shortcoming also doesn't mean we need to accept every possible shortcoming.

If you're adamant on pursuing the MSC3892 route, the way to make progress on this are the MSCs or another client. I think we've made our current point of view on this clear enough by now.

[nmscode]

I don't think we'd want for the user to decide whether this is an issue or not because most users will probably neither foresee nor understand this.

I disagree, I think the general idea is simple enough for people to grasp when using the app compared to looking through MSCs or PRs.

I would not consider leaking more information on an app whose only real selling point is privacy and encryption a "smaller" shortcoming. Reactions being unencrypted is a perfect example of how accepting one shortcoming doesn't mean we need to accept all of them. That is just my opinion though hopefully it can help someone.

Thank you for at least giving a clearer answer so that people will not needlessly spend time on this, since the requirements are hopefully done changing. Good luck with this.

Edit: If anyone reading wants to use/try the PR custom emote functionality without building it themselves from the branch they can still use it here https://pr9240--matrix-react-sdk.netlify.app/ even though the PR is closed.

[Johennes]

Re-posting my earlier message for anyone still interested to work on this.

If anyone is still interested in working on this, here's a proposal that hopefully allows us to make progress:

• Base your work on MSC2545. The SCT are planning to discuss custom emoji for v1.9 which is due in November but this proposal seems well received so far. As far as I understand, it was also already implemented by other clients.
• Start with just the sending part. We are planning to make changes around the room settings which could complicate finding a solution for how to configure custom emoji. Smaller PRs that separate concerns are also generally preferable.
• Put your work behind a labs flag
• We require 80% test coverage but if you'd first like to get agreement on the code and UX, it's ok to add the tests to your PR later

The, unfortunately, abandoned matrix-org/matrix-react-sdk#8087 might serve as inspiration.

[AndrewRyanChama]

In that case I would like to express for everyone that I will absolutely not be working on any continuation of my past PR, and anyone else is free to work on this functionality without any chance of overlapping or redundant work.

[speatzle]

@Cknight70 According to this message from Tuesday The Spec Core Team is currently Reviewing the Custom emoji/stickers MSCs during their off hours.

Quote:

Reviews on the custom emoji/stickers MSCs are underway, though not published yet. These reviews are being conducted in the off hours for SCT folks (due to so much else going on around Matrix) and may take a bit longer to publish than expected, sorry. We expect that they will be up for FCP before the Matrix 1.9 release date, though may not be merged until Matrix 1.10 next year. Matrix 1.9 is expected to be released on November 29th, 2023.

[Akselmo]

Seem a lot of friends of mine would be willing to hop on Matrix if Element had custom emojis, since they generally like the client, but custom emoji/sticker support being lacking is a bummer for many.

I believe these days such feature is pretty much expected, and I do hope Element can bring it to the game as well. Pretty much all clients would then have custom emojis (because many clients already do it through unofficial spec(?)), not just Element, and bring more feature parity between all the clients.

If I understand correctly, this seems to be a spec issue?

[ShadowJonathan]

its more a governance and priority issue, the spec proposal has been out for many years, and there's been a bunch of work done on it, but it hasn't budged inbetween, even though the community members involved have been open to working on it

now its in a limbo state, where the original community members have burned out on the spec proposal, and adopting/shepherding it would take some SCT time and priority that they currently dont have

long story short; dont expect this to be resolved for a year at minimum, and imo dont expect it to land in matrix for 3 years, if ever, at the rate things are currently going

[Akselmo]

Could the custom spec that is being used (im.ponies something?) be just adopted by Matrix?

(I know nothing of spec work so these are probably very stupid questions)

[ShadowJonathan]

yes, that's the MSC (Matrix Spec Change) proposal process

There's a few;

• MSC2545: Image Packs (Emoticons & Stickers) matrix-org/matrix-spec-proposals#2545
• MSC1951: Custom sticker packs and emoji (mk II) matrix-org/matrix-spec-proposals#1951

[turt2live]

To expand on the status from a spec perspective: the SCT is waiting on further input from the community before we can realistically push the MSCs through the process. The discussion place for that conversation is here: matrix-org/matrix-spec#1679

Unfortunately, the SCT does not have bandwidth ourselves to push the feature along - it requires someone else to think about the problems and design solutions.

[Akselmo]

Okay, thanks. I do hope it gets added to the spec since this is quite frequently asked feature when I talk about Matrix clients with my friends and others. I unfortunately have nothing substantial to add (again i'm just a common user and synapse homeserver owner), but I am glad that I got a response.

[Cknight70]

I honestly don't buy it's a bandwidth issue when multiple people have proposed specs and also code to make custom emojis work, one case for over a year with months of waiting for "product/design" to respond. element team has neglected even basic community fixes with testable prs like this element-hq/element-android#8602

As long as the element team does not have a process for handling community prs better than their track record I highly doubt we will see anything done by the community.

[Johennes]

At least for Element Web, there is a concrete proposal on how to proceed in #339 (comment). I'm, sadly, not able to provide further support because I don't work for Element anymore but that's where I'd start. If in doubt @langleyd would be a good contact.

[turt2live]

For clarity: I can't speak to the Element team's bandwidth here¹. I am speaking purely from a Spec Core Team (SCT) perspective, where we quite simply do not have the capacity to pursue the concerns on our own. We've opened an issue to gather community feedback on the concerns we do have, and welcome comments to help move the MSCs forward.

It sounds like Element will not have bandwidth to add the feature themselves either, and has generally been against adding long-lived unstable feature flags to their code (which I believe may be driving the PRs being closed, unfortunately). Hopefully with community input on the spec issue the MSCs will get pushed far enough along that Element can feel confident accepting/writing a PR.

Footnotes

1. Though, I am employed by Element currently. I don't track the client teams' roadmaps or bandwidth scheduling as closely these days. ↩

[AndrewRyanChama]

We've opened an issue to gather community feedback on the concerns we do have, and welcome comments to help move the MSCs forward.

I don't want to be pessimistic here but you're saying we're totally hard blocked on any movement here until 3911 is done. And since both SCT and Element don't care about this feature, we'll have to take whatever they unilaterally design on 3911 with no consideration at all for this feature.

Then maybe 2 years from now once 3911 is ships, we can finally start working on an all new proposal that will be compatible with it. Soo... optimistically, we can have image sets in 2027 🙃? I heard Mozilla closed a 21 year old bug today 😝

As for #339 (comment) I'd assume that this proposal is no longer valid now that 2545 is dead, but who knows, maybe Element has a different opinion.

[turt2live]

People do care, but are bandwidth constrained, as has been explained dozens of times already.

The SCT is working on trying to get the feature through, and has asked for help from the community in making that happen. Without that help, it will indeed take several more years to land.