Possibility to define our own emoji #339
Comments
|
this is also related to being able to send custom stickers |
|
see also element-hq/element-web#1692 |
|
I could work on this, store stickers only locally for now? |
|
That would be great! Could send stickers as data URLs, or upload them to your homeserver and refer to them via mxc:// URLs.
|
|
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. |
|
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 |
|
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. |
|
2 years have gone... |
|
Work is being done per MSC1951 -- I'm not involved, just passing along the info. |
|
This doesn't need an old-composer label |
|
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. |
|
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 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. |
|
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 pros: done in 2 hours. fine for a very limited set of custom emoji. |
|
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. |
|
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. |
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. |
|
Any further updates on this? Would love to be able to make private rooms and communities feel more like personalised spaces. |
This comment has been minimized.
This comment has been minimized.
|
I really want to convey to the developers in charge that having custom emojis would be a game changer for element/matrix in general. I know it seems like a silly thing to a lot of people but there is also a lot of people who really want to express themselves with emoji. Having this feature would drive adoption of element/matrix significantly. Please try and make this happen soon as possible, if possible. |
@eslerm it may not be 'kind', but neither is censoring an on-topic reply, which is why I replied to it that way in the first place, flabbergasted that it had been marked as 'off-topic', which does indeed seem like 'insane cope' on the part of whichever repo mod did so. In any case, I am merely a user who wants this feature in EDIT: apologies that this comes off quite harshly, but getting a notification like that puts one on the defensive. Glad it seems to have been resolved. 👍 |
|
Having no custom emojis is keeping twitch users and discord users off of Element and Matrix, having no stickers is keeping Furries off of Element and Matrix. I'm not joking when I say that, if Element wants to keep them disinterested in joining and contributing, they should keep delaying this issue, because that's exactly what they're doing. |
|
🤦 |
|
I've had chats with my teams at work, and my friend groups on Discord. Call it petty if you will, but no custom emoji support is holding back adoption, both from companies and casual folks. Both groups said that they won't consider moving without even basic custom emoji support. |
|
Likewise I have a friend group who uses SLACK as a chat app. They have been considering moving to matrix for YEARS but never made the transition due to the lack of custom emojis. It's not just Discord, Twitch, and Telegram - even Slack has supported custom emojis for years. I know there's a lot of comments similar to this one already, but I think it's important that the matrix team realizes how important this "trivial" feature is to so many people. |
|
Another wholehearted +1 to this sentiment. It's unfortunately the main reason holding my friend group back from moving to Matrix/Element from Discord. I cannot overemphasize how important this is to adoption, as crazy as that might sound. No one will even consider it without custom emotes, which are table stakes for a chat client today. |
|
lots of people here talking about how they can't move their team to matrix due to this missing feature... y'all know that there are many other clients available for matrix, and several of them support the experimental/non-final-msc version of custom emoji, right? check out cinny or nheko or fluffychat. not to detract from the importance of Element including this feature, but it's akin to saying "i'm not going to buy a car until it's legally required that all cars have airbags" when there are several cars with airbags on the market while element figures out the bureaucracy involved in standardizing airbag-installation. the biggest risk is eventually you'll need to reconfigure those custom emoji to align with the formally standardized specification. |
|
If your friend group won’t move to a more secure messaging platform solely due to lack of emotes, then they don’t really understand how vulnerable they are using Discord. However, I will wholeheartedly say that avoiding Element due to their lack of emote support is a smart decision, as any client that takes a decade to add a simple, already solved feature such as this, which multiple other clients have already added in a standard-conforming way, is not a product that bodes well for longevity and positive user experience. Element has obvious internal problems that hamper their technical capabilities, and this is the prime example. I’ve already moved most of my mobile texting to FluffyChat, which supports custom emotes and is a far better user experience in almost every way. Faster, smaller app size, and more customizable. The only downsides are lack of calling and thread support. |
This is true and I use Cinny on desktop, but of these only Fluffychat has a mobile app and it's not a good experience. Element is the paramount Matrix client and it needs to actually support this for its and the protocol's adoption. This is why this issue continues to generate such activity and emotional responses.
They understand the issues with using Discord. I understand them as well as I continue to begrudgingly use it. Discord wins out because it's easier and more pleasant, supports fun features like custom emotes, and it all Just Works™. I'm not talking about getting a group of technology and FOSS enthusiasts onto Matrix/Element, I'm talking about the 99.9% of the rest of the population who need these things so that we all can also benefit from the improved security. |
|
Speaking with my Element CEO hat on:
|
as in hundreds of thousands of dollars? Just want to make sure I understand that.
Definitely a chicken or the egg problem. You'll never get profitable unless you implement features the userbase wants. Ive seen multiple pr's closed over the years. Just pick one of those. Create a new branch for people that want emojis. There's so many ways to do this.
wdym? Discords whole business model revolves around custom emojis. People literally spend $100 a year to use custom emojis in servers. Im one of them. |
In the time that I've observed Matrix and Element's effective functioning, I've seen that this is not a viable course. We have matrix-org/matrix-spec-proposals#2545 and matrix-org/matrix-spec-proposals#1951, neither of which have moved forward much, or have been blocked by other MSCs that are related to internals. Moreover, I've heard that the author of MSC2545 actually largely burned out over all the discussion in that MSC. And while the shepherd system exists (allowing someone to push forward an abandoned or stale MSC), it is not easy to participate in it as someone who doesn't have access to matrix-org's repos, which induces a ton of friction. On the Element side of things, while FOSS is touted, I have seen time, and time, and time, and time, and time, and time again, that community work is deferred and de-prioritised. It is a financial decision I can understand, but it is effectively blocking major community contribution into matrix, as while the community wishes, and has wished, to hold out their hand to collaborate on things, we've been let down, ignored, and/or deprioritised for the above money-making features, from element's side of things, to spec proposals, to contributing and helping to make the spec better in many ways. My personal experience reflects this: I am absolutely not convinced that Element and Matrix's specification is open to Open Source contributions, when both history has told, and the current system incentivises, effective mothballing of the whole thing. A system is what it does. So essentially, you're telling us: "We don't have enough money, we can't afford to have developers review your changes, so if you want anything done about the problems you see in element, pay us"? Because that matches my experience, and is a large reason why my motivation for anything matrix-dev has wholly deflated, and I'm sure some community members can concur. |
|
While this is good rhetoric, I think you've cherrypicked a bunch of instances where community contributions have got stuck (and matrix-org/synapse#11256, which wasn't a contribution but a demand), while ignoring all the instances where contributions haven't got stuck. You've also unhelpfully conflated Matrix and Element together. In terms of spec progress for MSC2545 and MSC1951: this is nothing to do with Element. If what you're asking for is to get these MSCs FCP'd, then @joshsimmons (and I, with my Matrix SCT lead hat on - and in future the Governing Board) can get these prioritised. And even if the folks on the SCT who work for Element may be stuck dealing with foundational stuff like performant sync, reliable/secure encryption, state res; etc, there are now enough non-Element folks (tulir, clokep, kitsune and travis (whose dayjob is in practice with the Foundation these days)) to counterbalance that. I can't see any reason why these MSCs shouldn't be put on the SCT menu to get them FCP'd, especially given the amount of client implementations. However, this is the Element meta repository, and this issue is complaining about Element not yet having added implementations for these MSCs. In terms of Element being hostile to community contributions: Element's UX has historically been a disaster thanks in part to a) not having a product design team, b) historically allowing a free-for-all for contributions. Sometimes this worked out; sometimes it really didn't. Nowadays, there's an actual product team who decides what goes into the app and what doesn't, and unsolicited PRs which change the UX of the app may well get rejected, especially if there wasn't an up front discussion to check if they would be accepted. Now, personally, I think this process is a bit too harsh (and I'm trying to get the team to avoid "perfect being the enemy of good" on this) - e.g. on the ringtone PRs. It also feels that Element is missing a contribution guide which manages expectations. But overall: PRs which are aligned with what Element's product team want to do get merged (even if they change UX) - for instance element-hq/element-x-android#2667 is an example of a contribution from the SchildiChat team which got merged within 24h last week (after a quick discussion in the public EXA room). Meanwhile, absolutely massive community PRs have been merged too - e.g. MTRNord's i18n work on EW. So it's definitely fair to say that the barrier for contributing to Element's clients has increased, given the desire to focus how the app develops (and what the app team has to maintain). This is why forks like SchildiChat exist, so that folks can scratch their itch without being blocked on Element's product team. However, I believe it is completely incorrect to say that Matrix itself is contributor-hostile: instead, folks seem to be cherrypicking their favourite stuck MSCs and extrapolating it to conclude that the whole MSC system is broken. That's not to say that the MSC system is perfect; Josh has been running a process over the last few months to help debug it and try to avoid MSCs getting stuck, but it's not the disaster you're making it out to be.
In terms of Element contributions, the options are:
I'm sorry your motivation has deflated. I, for one, look forward to a world where the Element team has more bandwidth to wrangle community contributions. But until then, all I can do is to ask for some level of understanding and (yet more) patience. |
|
It's actually crazy how out of touch you are with the userbase. You picked the smallest impact PRs to prove your "point"? Why are you saying that you are open to contributions when all the community is allowed to do is some i18n changes or a small bugfix? Your product team is not helping at all improve Element's usability. Element was better without a product team when it was organically grown through community PRs. I guess you can just ignore all the nonexistent(?) PRs if you just close your eyes. @nmscode has worked on a mergeable PR for months and then at the end drop that Labs is being deprecated even though your devs told us to use labs at the start. Other emotes PRs were closed after discussion with the authors of those PRs because that's what the Element team said was needed to make this land. Then, after no other competing PRs were open, a person who doesn't work at element anymore told us our approach is untenable. Why did you waste @nmscode 's time for months? These are all things that show that Element is hostile to community contributions. We have been patient for years. You have not shown any one in the community any goodwill. Now you reap the rewards of having no funding or community goodwill. This is all on Element's management. |
|
Honestly, I haven't been personally tracking attempts to PR custom emojis to EW, so I apologise that it sounds like I missed a PR which has got stuck. If someone can point me at it then I can debug what happened and try to get something constructive out of this. |
|
@JiffyCat and others: your attacks are out of line. You seem to be forgetting that in any free software project, anything the developers decide to do or not do is entirely up to them and their goodwill. You’re free to not like this simple fact, but keep in mind that attacking Element for not paying much of their attention to such a ridiculously unimportant feature as custom emojis (that you consider crucial for yourself for some reason), you are absolutely not helping your cause. What you are, in fact, doing, is making them less likely to work on it (because of the hate they are receiving), and also what you’re gaining is that everyone silently following this discussion is going to dislike you for treating them the way you do. |
|
I'm no moneybags investor, & I can't speak for other users, but I know I would feel more comfortable financially contributing to the project w/ my own small-dollar donations – as I've done w/ other F/LOSS projects I appreciate – if I had more confidence in the development momentum of what I & others consider desirable features such as custom emoji & stickers support. |
|
@nmscode thanks for the summary - in retrospect this was on my radar at the time but it got eclipsed by more existential stuff. also, thanks for all the work which clearly went into this, and I'm genuinely sorry that it got stuck (for the reasons which Johannes patiently explained on the PR). Since your PR was opened the EW team has (drastically) shrunk, and practically speaking there is no way the team is going to be able to work on this as their day job in the near future (until if/when we get financially sustainable). Meanwhile there are concerns about MSC3892 (e.g. matrix-org/matrix-spec-proposals#3892 (comment)) which need to be sorted out. I'll talk to folks this coming week to see if we can figure out a way to unblock this. I can try to convince an existing Element customer to fund it, or try to persuade someone to work on it in their spare time (although after the less than constructive interactions here, i suspect this will be tough). At the least, with my SCT hat on, I can get the SCT to unblock review on the MSCs so that if anyone from the community wants to have another run at this, they're actually implementing an MSC which is on track to be merged to the spec. @andrewshadura thanks for attempt to highlight that raging at overstretched FOSS maintainers isn't constructive. |
Not to rehash an old discussion, but I already responded to those concerns. In addition, to prevent that from blocking the PR, I put the whole feature behind labs so that people could still use it with the understanding that it will change and may have some bugs. I also added compatibility with MSC2545. That MSC has its own serious issues, but is fairly popular. The original idea was that users could test and give more useful feedback on the MSCs if they could actually use the features on dev Element at https://develop.element.io/ and that would garner interest and snowball into more people willing to help move this forward. Lastly, as other users have stated, this feature has the potential to help Element increase revenue, which should definitely be explored given your current predicament. |
|
For clarity, from the SCT side, these MSCs are already a priority though blocked behind media linking and authentication interactions, which are active works in progress through the Trust & Safety team at the Foundation. As the team gets closer to media linking, custom emoji and stickers are much more possible to review. This is the plan for Matrix 1.11's release cycle, as announced. Clients are still welcome (and encouraged) to implement the MSCs ahead of formal acceptance at the spec level, though will be required to use unstable endpoints for now. |
|
So I just spent an hour discussing this with the whole matrix spec core team. Conclusions are:
On the Element side; I'm proceeding with:
|
If my PR makes it into labs on develop.element.io, I (and others) will help support/put more work into it. This should alleviate some of the work load from the Element team. |
|
Again I want to remind everyone, @nmscode has done all of the emote work for free including writing 80%+ test case coverage, following all contributor guidelines, and passing all CI checks. |
|
@nmscode said:
awesome, thank you. i wouldn't blame you for running a mile at this point, so the offer to help maintain is enormously appreciated. @AndrewRyanChama said:
The reason it's relevant is because right now there are three open overlapping/competing MSCs for custom emoji: MSC1951, MSC2545, MSC3892 (and the closed MSC1256). Element is not in position to spend time reviewing, merging and maintaining a PR which isn't backed by a MSC likely to make it into the final spec, therefore it's in everyone's interests for the Matrix SCT to clarify which of the MSCs is going to move forwards (and address any structural issues in it, such as 65KB limits, before it gets even more uptake). Obviously, clients are welcome to implement whatever experimental MSCs they like. I'm just trying to unblock the core problem here that folks want custom emoji in Element (which implies there being an accepted MSC for custom emoji to get behind).
If it were the Element team doing it as their day job, it'd need multiple hundred thousand $. If that sounds high, it's because it needs to cover:
Given the opportunity cost alone makes this high (because the Element devs are stuck doing other paying-customer stuff as their day job), this is why I'm trying to find a way to get it incorporated outside of dayjob commitments. |
|
The MSC provides confidence in the solution - this is done implicitly when engaging with customers, including opening and reviewing MSCs as needed. The MSC backing here is to ensure community contributions are more likely to be accepted, as there's confidence that the solution is the correct one (or close enough to the correct one to be essentially the same). |
|
Another thing I want to add to this discussion is that on the back end the code does not necessarily have to change drastically for different MSCs. Of course, some things will change but in terms of actually integrating into Element the code could easily be changed around to satisfy whatever MSC ends up being final. I have a little experience with this in that I added compatibility mode for two MSCs in my PR. Although they were different a lot of the underlying structures were reusable. This is why I think the approach of keeping it in develop for testing and then modifying after any spec changes would be much faster (and more cost efficient) than starting from scratch after an MSC is accepted (whenever that happens). |
and others
I would like to have the possibility to add my own emojis.
Could you please add this feature?
Kind regards
The text was updated successfully, but these errors were encountered: