Skip to content
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.

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

Possibility to define our own emoji #339

Open
floviolleau opened this issue Nov 25, 2016 · 142 comments
Open

Possibility to define our own emoji #339

floviolleau opened this issue Nov 25, 2016 · 142 comments
Labels
A-Composer A-Emoji O-Occasional Affects or can be seen by some users regularly or most users rarely T-Enhancement X-Needs-Product More input needed from the Product team

Comments

@floviolleau
Copy link

floviolleau commented Nov 25, 2016

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

Could you please add this feature?

Kind regards

@ara4n ara4n added the P2 label Nov 25, 2016
@ara4n
Copy link
Member

ara4n commented Nov 25, 2016

this is also related to being able to send custom stickers

@ara4n
Copy link
Member

ara4n commented Nov 25, 2016

see also element-hq/element-web#1692

@Gregoor
Copy link

Gregoor commented Nov 28, 2016

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

@ara4n
Copy link
Member

ara4n commented Nov 28, 2016 via email

@Gregoor
Copy link

Gregoor commented Nov 29, 2016

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
Copy link
Member

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
Copy link

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
Copy link

CPCer commented Jun 2, 2019

2 years have gone...

@apiontek
Copy link

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

@aaronraimist
Copy link

This doesn't need an old-composer label

@beardedlinuxgeek
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link

chr-1x commented Sep 2, 2020

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
Copy link

Roxxers commented Dec 14, 2020

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
Copy link

@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
Copy link

Roxxers commented Dec 14, 2020

@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
Copy link

@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
Copy link

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

@victort

This comment has been minimized.

@konomikitten
Copy link

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.

@InklingGirl
Copy link

InklingGirl commented Apr 5, 2024

I'm almost feeling masochistic enough to rebase my old PR and fix it up. Please I hope someone can step up and relieve me of this burdennn....
Happy to support with any questions and concerns also

Marked as 'spam' despite being relevant, insane cope.

@joshsimmons could you please investigate this? "insane cope" doesn't seem kind.

link

@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 element-desktop, not a contributor–developer bound by w/e hugbox CoC you have in place. I greatly appreciate all the work coding F/LOSS from the team, but marking on-topic replies – from actual community contributors – as 'off-topic', & then dobbing on the person who irreverently & cheekily called that out (many months ago, might I add), does not engender much confidence. Hopefully some of that energy goes towards actually getting this feature off the ground after almost eight (8) years.

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. 👍

@ShadowJonathan
Copy link

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.

@t3chguy
Copy link
Member

t3chguy commented Apr 5, 2024

🤦

@AgentScrubbles
Copy link

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.

@itsrachelfish
Copy link

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.

@andrewgioia
Copy link

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.

@williamkray
Copy link

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.

@gentleAmateur
Copy link

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.

@andrewgioia
Copy link

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.

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.

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.

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.

@ara4n
Copy link
Member

ara4n commented Apr 12, 2024

Speaking with my Element CEO hat on:

  • I would love Element to have custom emoji (and better sticker packs)
  • I completely get how it's a fundamental part of the culture of many online communities - as important a step forward as normal emoji reactions are to chat, if not more so.
  • However, Element is very resource constrained at the moment: we currently do huge amounts of legwork for Matrix (spec maintenance, synapse, client SDKs, all the E2EE, most of the VoIP, security, trust & safety, bridges etc) - as well as all our Element-specific stuff. This causes a major cash crunch, as you can see at https://matrix.org/blog/2023/12/25/the-matrix-holiday-update-2023/#in-other-news and https://matrix.org/blog/2024/01/2024-roadmap-and-fundraiser/ and https://matrix.org/blog/2024/04/open-source-publicly-funded-service/ and others.
  • This means we don't have bandwidth to work on elective stuff: we can only work on stuff which is being funded by customers. And right now we don't have any customers willing to pay for custom emoji or better sticker packs.
  • So, the only way for this to move forwards is:
    • Find someone to contribute it to Element: our apps are FOSS after all. The MSCs exist; implementations exist on Element forks, and if a mergable PR appeared against Element X and Element Web I could make a strong case to get it merged.
    • Find someone to pay x$$K (where x is quite high, given it has to cover the opportunity cost of doing other work) that can pay Element devs to get it done.
    • Donate a similar amount to the Foundation in case they can route $ to someone to implement it.
  • Otherwise, I promise that we'll get to it either when we find someone to fund it, or when Element gets profitable.
  • But until then, you need to understand that Element has ended up making payroll by selling messaging apps to people like the UN, NATO and the French and German governments. And they value other things (reliable encryption; performant apps; UX which outperforms WhatsApp) more than building a Discord killer.
  • I'm sorry that we didn't get to this before we hit the current funding crunch. We've been trying to get to it since at least 2021 (c.f. https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-special-2021/#2022) so it's not like it's not on the radar. But it will happen eventually.

@kevindk9
Copy link

x$$K

as in hundreds of thousands of dollars? Just want to make sure I understand that.

or when Element gets profitable.

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.

And right now we don't have any customers willing to pay for custom emoji or better sticker packs.

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.
Ill never use element until there are reacts and emojis.

@ShadowJonathan
Copy link

ShadowJonathan commented Apr 13, 2024

So, the only way for this to move forwards is:
Find someone to contribute it to Element: our apps are FOSS after all. The MSCs exist; implementations exist on Element forks, and if a mergable PR appeared against Element X and Element Web I could make a strong case to get it merged.

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.

@ara4n
Copy link
Member

ara4n commented Apr 14, 2024

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.

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"?

In terms of Element contributions, the options are:

  • If a PR is contributed which is aligned with the direction of the product team, and is mergeable without significant review iteration, and if we have confidence that the contributor will help maintain it (given all new features come with a massive maintenance cost, and right now we don't have bandwidth to maintain the current features, let alone new ones), then it's in with a shot for being merged. The way to check whether it's product-aligned is to ask in the public Element room first.
  • Alternatively, yes, finding an organisation with $$$K to pay for the feature to be implemented (and its subsequent maintenance) is another way to get it done.
  • That said, right now, we don't have much elective bandwidth to even review contributions. Obviously I'm doing my best to fix that situation asap (i.e. over the coming months), but right now folks will need even more patience than they've been displaying so far. Coming with pitchforks demanding that nonexistent(?) PRs are merged during a funding crisis is not helpful.

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.

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.

@JiffyCat
Copy link

JiffyCat commented Apr 14, 2024

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.

@ara4n
Copy link
Member

ara4n commented Apr 14, 2024

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.

@nmscode
Copy link

nmscode commented Apr 14, 2024

matrix-org/matrix-react-sdk#9240
https://pr9240--matrix-react-sdk.netlify.app

matrix-org/matrix-react-sdk#8897

matrix-org/matrix-react-sdk#8087

@andrewshadura
Copy link

@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.

@InklingGirl
Copy link

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.

@ara4n
Copy link
Member

ara4n commented Apr 14, 2024

@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.

@nmscode
Copy link

nmscode commented Apr 14, 2024

Meanwhile there are concerns about MSC3892 (e.g. matrix-org/matrix-spec-proposals#3892 (comment)) which need to be sorted out.

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.

@turt2live
Copy link
Member

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.

@ara4n
Copy link
Member

ara4n commented Apr 15, 2024

So I just spent an hour discussing this with the whole matrix spec core team. Conclusions are:

  • SCT needs to recommend one of the 3 MSCs so that future image pack implementations converge on the same impl
  • That MSC needs to get some love so it can actually get merged into the spec
  • @anoadragon453 has volunteered to shepherd it on behalf of the SCT.
  • Progress on image packs MSCs do not need to get blocked behind media linking & authentication (MSC3911 and MSC3916), although there's obvious overlap between them. (Linking & auth already try to take image pack use cases into account).

On the Element side; I'm proceeding with:

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).

@nmscode
Copy link

nmscode commented Apr 15, 2024

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).

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.

@JiffyCat
Copy link

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.

@ara4n
Copy link
Member

ara4n commented Apr 15, 2024

@nmscode said:

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.

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:

So I don't see why this discussion about the spec is relevant here

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).

How much money are we talking here? Money can be arranged if this work would be done for hire.

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:

  • the opportunity cost of the work that the team is otherwise committed to do (e.g. PQC for Matrix, for NATO)
  • design from the element design team
  • sorting out the spec
  • product & eng mgt for it on EW, EXI and EXA (and possibly EI and EA too)
  • actual dev to get the code reviewed and merged + UI tests
  • maintaining it for the rest of time.

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.

@bblacher
Copy link

bblacher commented Apr 15, 2024

@AndrewRyanChama If the functionality was funded by an Element customer they would push the MSC through first I think.

EDIT: pinged the wrong person, sorry :)

@turt2live
Copy link
Member

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).

@nmscode
Copy link

nmscode commented Apr 15, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Composer A-Emoji O-Occasional Affects or can be seen by some users regularly or most users rarely T-Enhancement X-Needs-Product More input needed from the Product team
Projects
None yet
Development

No branches or pull requests