MSC2545: Image Packs (Emoticons & Stickers) #2545
Conversation
|
People wanting to try out an implementation of custom emotes on the web can use their existing homeserver account through this riot-web instance. |
turt2live
added
kind:feature
Fluffychat Android works too :) |
|
What about adding a mandatory level of pack indirection ?
and then use what is proposed here inside This allows bundling and updating packs independently, and overcome the 65k limit by quite a margin. |
Not quite sure what you mean, here. That, for room emotes, you can specify other state keys that just extend that one pack? While not explicitly stated in this MSC (yet?), if multiple packs have the same |
|
Ok nevermind, I misread. I thought |
|
how hard would it be to add versioning and uuids to emoji packs |
You already have versioning with state events - or do you mean something like That being said, what if multiple packs have the same uuid but different emotes? Merge them? What if you spread one pack over multiple state events to overcome the 65k chars limit and then give them all the same uuid? Should they appear as one pack? How should that work with emote_rooms? |
if emotes are added to a pack, then the version number should be changed, and yeah i meant like a 1.0 thing, if multiple packs have the same uuid and the same version number, but different emotes, then the conflict should be reported to the user, after thinking about it might make more sense to have a last modified date instead of a version number, and it just uses the newest one, because if you want to remove an emote from a pack, then it shouldn't add it back from an older version of the pack, and i don't see how any of this is affected by it being in a room or a user account |
Would a user care about the version of an emote pack? How to determine which version is newer? Grammer for version numbers would need to be defined, etc. |
|
Like, maybe the uuid and versioning stuff could be added in a separate msc building onto this - the goal of this was to keep things as simple as possible |
ok if one pack was spread over multiple events, i would have them share the uuid and also have part numbers, like "part":1 "part":2 etc for A, mainting the order of emotes, and B, to prevent them from overlapping eachother.
state events have timestamps right, so you could just use the newest state event instead of bothering with version numbers |
origin_server_ts can't be trusted and can easily be forged
What would it need part for? It shouldn't matter if they are ordered correctly or not, emotes are an unordered set |
oh you could just put a modified tag in then with like unixtime or something
the most important reason for the part value is to distinguish continuations of the pack from updates and being able to order the emotes could matter to some pack maintainers, i would want to be able to do that for example |
In a federated system there is no one true timesource. That is a mathematically unsolvable problem.
Updates would replace the previous state event. You don't need any "part" attribute for that. As for ordering, you could say they are ordered alphanumerically by the state key. |
There was a problem hiding this comment.
Hello all. I plan to breathe new life into this MSC by addressing any outstanding concerns and making changes as necessary.
I'm aware that this MSC has already been successfully implemented in numerous clients (thank you!), and I intend to remain compatible with those implementations as much as possible.
I very much look forward to seeing custom emotes and stickers become a part of the Matrix spec. Let's make it happen!
Whenever they are defined.
|
Any updates on this? |
|
Any updates on this? ❤️ |
|
Is there a way to mark https://github.com/matrix-org/matrix-spec-proposals/pull/2545/files#r677009720 as not resolved?
One of the following needs to happen before that concern is resolved:
|
|
Signed-off-by: SkyePrism skye.prism@outlook.com |
Thank you to @kevincox for bringing this to the attention of the MSC authors.
There was a problem hiding this comment.
Hello! I have heavily refactored the MSC in 5663906 to make it clearer.
The one functional change buried in that commit was clarifying that the alt attribute of a custom emote should be a description of the image, whereas the title should be the shortcode (what one would expect to appear in a tooltip). This felt more in line with what clients do today, and with the original intention for those attributes in the HTML spec.
Below are some outstanding questions I had after closely reading through the MSC again. Please weigh in to help this MSC move towards FCP 🚂
| The `height` attribute MUST be present. This maintains backwards-compatibility | ||
| with clients that do not support custom emotes. |
There was a problem hiding this comment.
height is not a required field in <img> tags as defined by the HTML standard. Neither is it required by the Matrix spec.
So is it really required, or can we let it be omitted (and default to 32px)?
There was a problem hiding this comment.
Default it to 32px if not present. No need to enforce it
There was a problem hiding this comment.
I would tend to minimize the backwards compatibility burden (remove this), if reasonably possible. How big of an issue will it cause when the first clients implementing this MSC start sending 1024px emotes to clients only naively implementing inline images? I reckon is should be easy for everyone to implement data-mx-emoticon, so maybe it is ok here to move fast and break things. Would this be considered an attack vector?
There was a problem hiding this comment.
true the default to 32px seems sensible
There was a problem hiding this comment.
Ah I see, it's for clients that don't support custom emojis. 32px sound good then.
I've updated the justification in bccfa91.
proposals/2545-emotes.md
Outdated
| Any other character is explicitly allowed. This allows shortcodes | ||
| containing non-Latin characters for communities of those languages. |
There was a problem hiding this comment.
Should spaces be disallowed in shortcodes? I feel that if a shortcode has spaces in it, it may be tricky to filter for it in a client that pops up a search UI when typing :. Typically I would expect typing a space when searching to cancel the search.
There was a problem hiding this comment.
I agree with you, shortcodes should not have spaces. It would bring more complexity to case. Disallowing spaces in shortcodes is a best practice that improves usability, technical reliability, and consistency. If you want to support multi-word shortcodes, consider using alternative separators like hyphens or underscores
There was a problem hiding this comment.
Spaces have been disallowed in 2f14ae1.
| #### `m.image_pack.rooms` account data event | ||
|
|
||
| The `m.image_pack.rooms` account data event consists of the following: | ||
|
|
||
| - `rooms` **Required, Map[String, Map[String, Object]]**. A map of room ID to | ||
| another map: from `state_key` to an empty object. | ||
|
|
||
| This data structure allows specifying a single room image pack given the pack's | ||
| room ID and `state_key`. |
There was a problem hiding this comment.
Should we combine the m.image_pack and m.image_pack.rooms account data events into a single account data event? Such that m.image_pack would have a rooms field with the contents of the existing m.image_pack.rooms account data event?
My initial assumption for why this was originally done was account data event size limits. But actually, I don't think individual account data events have event size limits? Instead, it would make more sense for a homeserver to limit the total amount of account data a user could store.
So, what purpose is there in having two separate account data event types defined?
There was a problem hiding this comment.
I have question(s) about this:
-
Users can define global packs for their account to be used in rooms or users could specify set of emojis only to be used in specific rooms?
-
Would admin/moderator allow and upload what they think its best suiting for room if its community driven
-
Can we limit that specific rooms dont allow emojis or just allow emojis defined by room from question 2
There was a problem hiding this comment.
I wonder, is there precedence for subtyping events like this? I wonder if it is wise to do. That would be an argument in favor of combining.
I would assume this was originally done so m.image_pack is the same as state and account data event; easier to write parsers and spec. This would be an argument against combining.
Given how widely adopted this MSC is, I wonder how fundamentally we should still change it, or at least consider the impact of these changes to the migrations necessary to implement. I this case the migration should be fairly easy (if .rooms is found in account data, move and delete it).
There was a problem hiding this comment.
Users can define global packs for their account to be used in rooms or users could specify set of emojis only to be used in specific rooms?
The former.
Would admin/moderator allow and upload what they think its best suiting for room if its community driven
I'm not sure I understand the question.
Can we limit that specific rooms dont allow emojis or just allow emojis defined by room from question 2
If you're asking whether a room admin can prevent custom emojis from packs that aren't defined in that room, then no. Just as a room admin can't prevent only certain images from being sent in a room today.
They could do it via a bot that analyses messages, but not through the auth rules defined by the spec (at least in today's room versions).
I wonder, is there precedence for subtyping events like this? I wonder if it is wise to do. That would be an argument in favor of combining.
Good question. Looks like there is some precedence similar to the naming convention:
- SSSS:
m.secret_storage.key.<key_id>,m.cross_signing.master,m.cross_signing.user_signing - MSC3890:
org.matrix.msc3890.local_notification_settings.<device_id>
Though I think rather than trying to split up a large event into smaller chunks, this naming is simply a matter of namespacing (i.e. everything really to cross signing should be called m.cross_signing.*.
So perhaps that's what this proposal was originally aiming to do.
I would assume this was originally done so
m.image_packis the same as state and account data event; easier to write parsers and spec. This would be an argument against combining.
Personally I would advise against this, for if m.image_pack the state event or account data event ever diverge in the spec, such combined implementation will have to be separated again.
I actually don't really see a reason to combine these objects. Plus splitting them up does mean that a client can query them separately if desired. Given it would be more churn for existing implementations of this MSC to switch, I'm minded to keep things how they are.
There was a problem hiding this comment.
Looks like there is some precedence similar to the naming convention:
* SSSS: `m.secret_storage.key.<key_id>`, `m.cross_signing.master`, `m.cross_signing.user_signing` * [MSC3890](https://github.com/matrix-org/matrix-doc/pull/3890): `org.matrix.msc3890.local_notification_settings.<device_id>`
These look like different cases? Here in MSC2545 we propose to have both m.image_pack and m.image_pack.rooms. Does a m.cross_signing (not m.cross_signing.*!) event exist that my Ctrl+F is missing?
Besides that, yes I am sure this proposal was aiming to sort its events into a common namespace, which is more than reasonable.
There was a problem hiding this comment.
🎉 Overall, I can't wait for this to be officially approved. After all, it's shadow-spec for a couple years at this point ;) I do however think that improvements that enable better sharing features in this or a timely followup MSC would be important to enable shipping a complete feature.
| #### `m.image_pack.rooms` account data event | ||
|
|
||
| The `m.image_pack.rooms` account data event consists of the following: | ||
|
|
||
| - `rooms` **Required, Map[String, Map[String, Object]]**. A map of room ID to | ||
| another map: from `state_key` to an empty object. | ||
|
|
||
| This data structure allows specifying a single room image pack given the pack's | ||
| room ID and `state_key`. |
There was a problem hiding this comment.
I wonder, is there precedence for subtyping events like this? I wonder if it is wise to do. That would be an argument in favor of combining.
I would assume this was originally done so m.image_pack is the same as state and account data event; easier to write parsers and spec. This would be an argument against combining.
Given how widely adopted this MSC is, I wonder how fundamentally we should still change it, or at least consider the impact of these changes to the migrations necessary to implement. I this case the migration should be fairly easy (if .rooms is found in account data, move and delete it).
| Other URI schemes, such as `https`, `mailto` etc. are not allowed. Clients MUST | ||
| NOT attempt to render images accessible through other URI schemes, as this may |
There was a problem hiding this comment.
I'm not sure if this is something an MSC would usually point out, but
Clients must also be careful about input validation - same as with inline images, but if we're being honest I think this MSC is the driver behind inline images implementations.
There was a problem hiding this comment.
Clients should validate all events, not just those containing inline emotes.
I believe (read: hope) the spec says this somewhere, but I don't think that's a problem specific to this MSC.
There was a problem hiding this comment.
I agree, and I'm fairly certain the spec does. It felt worth mentioning because it's fine that the MSC points out that the URI should be validated for being an mxc, yet if the client then goes and fetches and displays an unsanitised svg that is obviously bad.
Feel free to resolve this if there isn't anything to be added at this point. I think it's a bit spicier if we get to reactions as they are a new place for images to be displayed.
| The `info` object of the `m.sticker` event SHOULD be set to the `info` object of | ||
| the image, or if absent, an empty object. | ||
|
|
||
| ## Security Considerations |
There was a problem hiding this comment.
The MSC isn't very clear on this, but it is somewhat implied that to be able to use a certain image pack, one has to join the room that defines it. (I'm not sure where we are in terms of peeking, if we could?)
In the case of sharing packs via rooms that have only this purpose, this is obviously leaky in terms of privacy, since all pack users can see the full list of who is using a pack.
Some solutions I can imagine:
- public image packs SHOULD be peekable. depends on peeking.
- clients could offer UI to clone image packs to your own room/account. this is only a partial solution and you lose the implied feature of "subscription" to automatic pack updates
- introduce a new room type via another MSC, where members can't see each other. this would also be useful for "announcement" type rooms.
There was a problem hiding this comment.
The MSC isn't very clear on this, but it is somewhat implied that to be able to use a certain image pack, one has to join the room that defines it. (I'm not sure where we are in terms of peeking, if we could?)
We don't have federated peeking yet, no.
clients could offer UI to clone image packs to your own room/account
A new room type is interesting, I believe there's other MSCs for rooms where you can't see other user room membership. In either case, definitely something for a future MSC.
Clients could allow users to clone a pack and then offer to "check for updates", though that definitely feels like a workaround (and something to be explored in implementation, rather than this MSC).
| can be added to a `m.image_pack.rooms` account data event. Note that this is | ||
| separate from the `m.image_pack` account data event defined above. | ||
|
|
||
| #### `m.image_pack.rooms` account data event |
There was a problem hiding this comment.
I wonder why this feature is limited to account data (personal packs). Wouldn't it make sense for room admins ("community managers") to suggest 3rd party packs for use in this community?
I imagine that image pack UX in such a room would either automatically use a referenced pack if the user can already access it, or offer/suggest to start using it (= try to join in the background) if not.
I found that you already discussed something similar long ago #2545 (comment) but given the question of merging m.image_pack and m.image_pack.rooms, having the same functionality would even resolve one of the arguments against.
There was a problem hiding this comment.
As you've said, we have multiple methods to share packs outside of a room today; a sharable space leading to pack rooms, or direct links (assuming UX for sharing links to image packs is improved in clients).
I'm not sure if we need a third mechanism, and I don't see any other messaging services offering such a feature. In Discord, users join a "server" in the foreground if they want to use the packs within. On Telegram, you can send a friend a link to a pack and their client will offer to add it upon clicking the link.
Do we additionally need room metadata for such references?
There was a problem hiding this comment.
Hm, I think I have 2 arguments here:
- We get via this MSC "room packs", i.e. the proposed UX is roughly that in a given regular chat room used primarily for chatting, the moderators can upload images to a pack which is stored in the same room, and then any member of the room will have their sticker/emoji picker suggest the images from that pack while viewing that specific room. I don't see why we would limit this such that in my Matrix Workation Thailand 2025 space, which will never canonically have
#blobhaj:the-apothecary.clubas a parent, I can't default that (my) community to be able to use the blobhaj pack. Wouldn't it be neat? Especially as the feature is basically already designed. - We already have the technical side modeled and included elsewhere (personal packs) and it would actually simplify this MSC to use it in both places
Again, not a blocker imo, maybe I am misjudging users/the use case.
There was a problem hiding this comment.
Sharing packs via links can feel like a detour, requiring users to venture out and manually add them to their accounts. In contrast, integrating room-specific packs directly into the interface makes them effortlessly accessible, fostering a sense of community and collaboration.
Links often represent solo creations, lacking the shared spirit of community-driven packs. By centralizing pack management within rooms or spaces, moderators can curate content without external tools, simplifying tasks and empowering communities to thrive.
Imagine a professional Matrix space with sleek emoji packs and a casual room bursting with fun emojis —each tailored to its unique vibe. This localized approach not only enhances usability but also personalizes the experience, making it more enjoyable and engaging for everyone involved.
| @@ -0,0 +1,495 @@ | |||
| # MSC2545: Image Packs (Emoticons & Stickers) | |||
There was a problem hiding this comment.
Besides a room pack being shared with the whole room, further potential mechanisms for sharing image packs are not described (#2545 (comment)), though image pack "stores" seem integral to sticker and "emoji" features of other platforms. Clearly it would be possible to create 3rd party platforms that serve as indices for sticker pack rooms, similar to how https://servers.joinmatrix.org and https://matrixrooms.info exist. Sharing images packs is slightly more complicated, because to reference one, you need to reference a room AND an event, which however is well possible using matrix.to and matrix: URIs. The current approach in practise seems to be using spaces as an index.
Client developers aiming to implement a rich e.g. sticker pack UX might come up with the idea to offer a "share" button in the client's image pack management settings that would generate a matrix.to link to a pack's origin room and state event. It comes with some potential problems for the receiver as they might have to join the room, wait for join, maybe not being able to join an invite-only room, being confused why there is a new room in their room list, etc. The sharing user's client might check for some of these requirements, such as invite-only rooms, and even offer to alleviate them (semi-)automatically, e.g. by sending an invite (on the other hand potentially causing more confusion).
Many clients implement "pills" as a GUI shard that indicates a certain functionality, i.e. linking to users/rooms/events. However recipients have no way of indicating more info, e.g. whether the linked event is a state event, let alone an image pack. Nice rich UI for sharing "links" to image packs therefore remains open at this time.
Another related thought is that as this feature becomes available, a lot of people unfamiliar with matrix moderation might start creating public rooms to author and distribute their packs. Introducing an image pack room type was discussed prior at #2545 (comment). Yet even without it, clients may wish to create UX specific for creating new pack-only-rooms with reasonable power level setups similar to what is currently used as announcement rooms to limit the abuse potential. It is a nice side-product feature of this MSC that discussion of image packs in otherwise pack-only-rooms is possible, but I think that is not usually available on other platforms.
There was a problem hiding this comment.
I appreciate the ideas, but I'm not sure what should change in this MSC to reflect them.
Perhaps they're best put in a new matrix-spec issue so they can be tracked across MSCs?
| The `info` object of the `m.sticker` event SHOULD be set to the `info` object of | ||
| the image, or if absent, an empty object. | ||
|
|
||
| ## Security Considerations |
There was a problem hiding this comment.
There are currently 3 levels of "sharing" image packs proposed:
- the user is entirely in control of the packs. This is when the pack is defined in profile data, or in a room they are the sole admin of.
- the user is trusting a community. This is when the pack is defined in a room or space by that community's admins, and the pack is within the rooms itself the discussion is happening in.
- the user is trusting the pack author. this is when a user enables global use of a pack by referencing it in their profile data. This is very similar to the above, but prone to a higher risk imo, assuming that it will often be some lone random pack author without further association to a community besides the users of that pack.
In any case the user is not in alone control over the pack, they are vulnerable to an attack where those who can update the pack can add or entirely replace the previous content with abusive content. If this were to happen, said user would be upon opening their sticker picker etc the next time be presented with thumbnails of abusive content.
A possible way to address this, could be "pinning" pack versions, by referencing the event ID at the time of "subscribing" to the pack (this was mentioned in a previous review). It would then be prudent for the client UX to also offer some kind of update notice (or a way to navigate and switch versions in general? if state supports that?) to the user. Updating of course then presents the problem again.
I'm not sure, but I would expect due to the nature of state events, having ignored certain users is no solution for this either, as one would still receive their state updates by necessity of keeping the room intact.
Over all, the impact of this issue seems like it would not be too severe; most pack owners are known in their communities etc. This might however change as image packs become a "mainstream" matrix feature, especially if Element decides to adopt it for its widespread clients.
There was a problem hiding this comment.
Being able to walk back and forward along a pack's timeline is a cool feature, and one that matrix's history capabilities give us. I could imagine a client that allows you to view the "history" of a sticker pack, and "pin" a certain version. In addition, or perhaps instead, it could allow one to "copy" a pack at a certain revision and thus you'd have an immutable copy - you could then even leave the room and take the image pack with you.
Interesting ideas, but something that could be added in a backwards-compatible way. It's also something that doesn't exist in other messaging platforms, and thus I don't know how much demand there actually is from users for such a feature.
Therefore I think, while a valuable idea, it should be left to a future MSC.
There was a problem hiding this comment.
What about the security safety considerations around the topic?
Co-authored-by: Kim Brose <2803622+HarHarLinks@users.noreply.github.com>
| The `info` object of the `m.sticker` event SHOULD be set to the `info` object of | ||
| the image, or if absent, an empty object. | ||
|
|
||
| ## Security Considerations |
There was a problem hiding this comment.
Being able to walk back and forward along a pack's timeline is a cool feature, and one that matrix's history capabilities give us. I could imagine a client that allows you to view the "history" of a sticker pack, and "pin" a certain version. In addition, or perhaps instead, it could allow one to "copy" a pack at a certain revision and thus you'd have an immutable copy - you could then even leave the room and take the image pack with you.
Interesting ideas, but something that could be added in a backwards-compatible way. It's also something that doesn't exist in other messaging platforms, and thus I don't know how much demand there actually is from users for such a feature.
Therefore I think, while a valuable idea, it should be left to a future MSC.
| @@ -0,0 +1,495 @@ | |||
| # MSC2545: Image Packs (Emoticons & Stickers) | |||
There was a problem hiding this comment.
I appreciate the ideas, but I'm not sure what should change in this MSC to reflect them.
Perhaps they're best put in a new matrix-spec issue so they can be tracked across MSCs?
| can be added to a `m.image_pack.rooms` account data event. Note that this is | ||
| separate from the `m.image_pack` account data event defined above. | ||
|
|
||
| #### `m.image_pack.rooms` account data event |
There was a problem hiding this comment.
As you've said, we have multiple methods to share packs outside of a room today; a sharable space leading to pack rooms, or direct links (assuming UX for sharing links to image packs is improved in clients).
I'm not sure if we need a third mechanism, and I don't see any other messaging services offering such a feature. In Discord, users join a "server" in the foreground if they want to use the packs within. On Telegram, you can send a friend a link to a pack and their client will offer to add it upon clicking the link.
Do we additionally need room metadata for such references?
| #### `m.image_pack.rooms` account data event | ||
|
|
||
| The `m.image_pack.rooms` account data event consists of the following: | ||
|
|
||
| - `rooms` **Required, Map[String, Map[String, Object]]**. A map of room ID to | ||
| another map: from `state_key` to an empty object. | ||
|
|
||
| This data structure allows specifying a single room image pack given the pack's | ||
| room ID and `state_key`. |
There was a problem hiding this comment.
Users can define global packs for their account to be used in rooms or users could specify set of emojis only to be used in specific rooms?
The former.
Would admin/moderator allow and upload what they think its best suiting for room if its community driven
I'm not sure I understand the question.
Can we limit that specific rooms dont allow emojis or just allow emojis defined by room from question 2
If you're asking whether a room admin can prevent custom emojis from packs that aren't defined in that room, then no. Just as a room admin can't prevent only certain images from being sent in a room today.
They could do it via a bot that analyses messages, but not through the auth rules defined by the spec (at least in today's room versions).
I wonder, is there precedence for subtyping events like this? I wonder if it is wise to do. That would be an argument in favor of combining.
Good question. Looks like there is some precedence similar to the naming convention:
- SSSS:
m.secret_storage.key.<key_id>,m.cross_signing.master,m.cross_signing.user_signing - MSC3890:
org.matrix.msc3890.local_notification_settings.<device_id>
Though I think rather than trying to split up a large event into smaller chunks, this naming is simply a matter of namespacing (i.e. everything really to cross signing should be called m.cross_signing.*.
So perhaps that's what this proposal was originally aiming to do.
I would assume this was originally done so
m.image_packis the same as state and account data event; easier to write parsers and spec. This would be an argument against combining.
Personally I would advise against this, for if m.image_pack the state event or account data event ever diverge in the spec, such combined implementation will have to be separated again.
I actually don't really see a reason to combine these objects. Plus splitting them up does mean that a client can query them separately if desired. Given it would be more churn for existing implementations of this MSC to switch, I'm minded to keep things how they are.
| <img data-mx-emoticon src="mxc://example.org/emote" alt="A cat holding a paper heart" title="cat_luvs_u" height="32" /> | ||
| ``` | ||
|
|
||
| A client should treat an `<img>` tag as a custom emote if the custom |
There was a problem hiding this comment.
What does it mean to treat something as a custom emote?
By that, I meant clients should recognise an inline image as an emote if it has the data-mx-emote attribute. Clients can treat these differently than regular inline images, such as rendering it larger if the message only contains those. Or popping up pack details if those are attached, as you've suggested.
Wouldn't it therefore make sense that sending clients SHOULD include the sticker pack source room and state key (or event ID for versioning?)?
I think it definitely does! And I like your suggestion of using the data-mx-emote attribute to do it. I do think we should put it in a separate MSC though, for a few reasons:
- There's no backwards-compatibility concern with accepting MSC2545 and including image pack data in custom emotes in event bodies.
data-mx-emoticonis currently present in many events in the wild, and the field value is currently ignored by all clients. - I'm trying to avoid changing this MSC too much so existing implementations can easily switch over to the stable identifiers.
- I don't agree that
data-mx-emoticon="matrix:roomid/my-sticker-room/?image_pack=my-sticker-pack"is all we need. What if you aren't in the referenced room? Unfortunately we don't have federated peeking yet. Clients have been making use of MSC3266 for similar functionality, but pulling arbitrary state isn't available via that API.
| Other URI schemes, such as `https`, `mailto` etc. are not allowed. Clients MUST | ||
| NOT attempt to render images accessible through other URI schemes, as this may |
There was a problem hiding this comment.
Clients should validate all events, not just those containing inline emotes.
I believe (read: hope) the spec says this somewhere, but I don't think that's a problem specific to this MSC.
| The `info` object of the `m.sticker` event SHOULD be set to the `info` object of | ||
| the image, or if absent, an empty object. | ||
|
|
||
| ## Security Considerations |
There was a problem hiding this comment.
The MSC isn't very clear on this, but it is somewhat implied that to be able to use a certain image pack, one has to join the room that defines it. (I'm not sure where we are in terms of peeking, if we could?)
We don't have federated peeking yet, no.
clients could offer UI to clone image packs to your own room/account
A new room type is interesting, I believe there's other MSCs for rooms where you can't see other user room membership. In either case, definitely something for a future MSC.
Clients could allow users to clone a pack and then offer to "check for updates", though that definitely feels like a workaround (and something to be explored in implementation, rather than this MSC).
| The `height` attribute MUST be present. This maintains backwards-compatibility | ||
| with clients that do not support custom emotes. |
There was a problem hiding this comment.
Ah I see, it's for clients that don't support custom emojis. 32px sound good then.
I've updated the justification in bccfa91.
proposals/2545-emotes.md
Outdated
| Any other character is explicitly allowed. This allows shortcodes | ||
| containing non-Latin characters for communities of those languages. |
There was a problem hiding this comment.
Spaces have been disallowed in 2f14ae1.
|
@witaliy12 ?? Looks like spam... |
Rendered
Signed-off-by: Sorunome mail@sorunome.de
Author: @Sorunome
Shepherd: @anoadragon453
Future MSCs
Current implementations
Emote rendering (rendering of the
<img>tag)data-mx-emoticon)data-mx-emoticon)Sending, using the mentioned events here
Bridges
data-mx-emoticononly)Implementation PRs
FluffyChat
Data model: https://gitlab.com/famedly/company/frontend/libraries/matrix_api_lite/-/merge_requests/26
SDK: https://gitlab.com/famedly/company/frontend/famedlysdk/-/merge_requests/726
Emoticons: https://gitlab.com/famedly/fluffychat/-/merge_requests/433
Stickers: https://gitlab.com/famedly/fluffychat/-/merge_requests/452
Nheko
Stickers: Nheko-Reborn/nheko#648
Sticker editor: Nheko-Reborn/nheko#669
Choosing emoticons: Nheko-Reborn/nheko@ea6b19b
Cinny
Emoticons and Stickers: cinnyapp/cinny#686
kazv
Creating and sending stickers: https://lily-is.land/kazv/kazv/-/merge_requests/71