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

MSC2545: Image Packs (Emoticons & Stickers) #2545

Open
wants to merge 36 commits into
base: old_master
Choose a base branch
from
Open
Changes from 1 commit
Commits
Show all changes
36 commits
Select commit Hold shift + click to select a range
bc55ff6
add emotes proposal
Sorunome May 15, 2020
0f4bd5e
add more stuffs
Sorunome May 15, 2020
2d191f6
fix naming thingy
Sorunome May 15, 2020
fa3a8be
fix typo
Sorunome May 15, 2020
96f2864
outline room emote packs and emote rooms
Sorunome May 20, 2020
81ccecb
remove comma
Sorunome May 20, 2020
dc43e79
address things
Sorunome May 20, 2020
4435d75
update emotes msc
Sorunome Jun 20, 2020
79aae8a
update
Sorunome Jun 20, 2020
4fea69b
Fix typos and grammar mistakes
Sorunome Jun 24, 2020
0e382e0
m.emote --> m.emoticon, update dedupe and pack priority
Sorunome Sep 1, 2020
72b2174
update stuff
Sorunome Sep 24, 2020
2e2987b
add a paragraph over emojis and stuff
Sorunome Sep 30, 2020
e8c2e34
Re-word proposal to sound more firm, address lots of suggestions
Sorunome Oct 25, 2020
b41c091
specify that emotes can be animated
Sorunome Oct 25, 2020
4f6d147
update msc to also include stickers and thelike
Sorunome Mar 25, 2021
5351cb3
update a few things
Sorunome Mar 25, 2021
12c8fa8
add a few more words on slugs
Sorunome Mar 25, 2021
e8d910f
Update proposals/2545-emotes.md
Sorunome Mar 26, 2021
a879bcd
license --> attribution
Sorunome Jul 4, 2021
580a836
Update proposals/2545-emotes.md
Sorunome Jul 18, 2021
43f20ad
Merge branch 'soru/emotes' of github.com:Sorunome/matrix-doc into sor…
Sorunome Jul 18, 2021
739b4c0
Update with "looking further" section and slightly update comparison
Sorunome Jul 18, 2021
51bcec2
add a sentance to suggest image packs from spaces
Sorunome Jul 24, 2021
71a3c55
soru bamboozled herself!
Sorunome Jul 24, 2021
a7a4a36
Fix small wording and ensure that emotes from canonical spaces are to…
Sorunome Sep 16, 2021
be7d0df
Update spelling mistakes and wording, only suggest deduplication meth…
Sorunome Oct 28, 2022
b5ca351
fix some typos
anoadragon453 Sep 19, 2023
3517a16
Make reference to spec/client naming disparity timeless
anoadragon453 Aug 15, 2024
5d62d52
Require `alt` and `title` attributes for emotes
anoadragon453 Aug 15, 2024
e5b9c2c
Link `m.sticker` spec; small wording changes
anoadragon453 Aug 15, 2024
44c5ed3
Prevent clients from rendering emotes behind non-MXC uri schemes
anoadragon453 Aug 15, 2024
ea50cc7
Clarify client requirements around emote resolution
anoadragon453 Aug 15, 2024
3c2e29c
Add a new proposal intro
anoadragon453 Aug 15, 2024
c429552
Recommend default of 32px for emote height
anoadragon453 Aug 28, 2024
d4e9cd2
Specify image formats are equivalent to m.image
anoadragon453 Aug 29, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Fix typos and grammar mistakes
Sorunome committed Jun 24, 2020
commit 4fea69b80103195904061d6a2a66ad4f104565bb
16 changes: 8 additions & 8 deletions proposals/2545-emotes.md
Original file line number Diff line number Diff line change
@@ -137,33 +137,33 @@ pack name and has a blank state key, then "room" is used.
When sending an `<img>` tag in an end-to-end encrypted room, the client will make a request to fetch
said image, in this case an emote. As there is no way to encrypt content behind `<img>` tags yet,
this could potentially leak part of the conversation. This is **not** a new security consideration,
it already exists. This, however, isn't much different of posting someone a link in an e2ee chat and
it already exists. This, however, isn't much different from posting someone a link in an e2ee chat and
the recipient opens the link. Additionally, images, and thus emotes, are often cached by the client,
not even necessarily leading to an http query.

# Alternatives
One can easily think of near infinite ways to implement emotes. The aspect of sending an `<img>` tag
and marking it as an emote with `data-mx-emote` seems to be pretty universal, though, so the question
and marking it as an emote with `data-mx-emote` seems to be pretty universal though, so the question
is mainly on different emote sources. For that, a separate MSC, [MSC1951](https://github.com/matrix-org/matrix-doc/pull/1951)
already exists, so it is reasonable to compare this one with that one:

## Comparison with MSC1951
MSC1951 defines as only emote source a dedicated room. This MSC, however, also allows you to bind emotes
MSC1951 defines a dedicated room as the only emote source. This MSC, however, also allows you to bind emotes
to your own account, offering greater flexibility. In MSC1951 there can also only be a single emote
pack in a room. This could be problematic in e.g. bridged rooms: You set some emotes from the matrix
side and a discord bridge would plop all the discord emotes in another pack in the same room.

MSC1951 defines a way to recommend using a pack of a different room - this MSC does not have an equivalent
of that. Instead, this MSC allows multiple emote packs for a room, and allows you to enable an emote
pack to be globally available for yourself accross all rooms you are in.
to that. Instead, this MSC allows multiple emote packs for a room, and allows you to enable an emote
pack to be globally available for yourself across all rooms you are in.

The core difference is how MSC1951 and this MSC define the emotes themselves: In MSC1951 you have to
set one state event *per emote*. While this might seem like a nice idea on the surface, it doesn't
scale well. There are people who easily use and want hundreds or even thousands of emotes accessible.
A simple dict of shortcode to mxc URI seems more appropriate for this.

Additionally, this MSC is already used in the wild since about two years by some clients, while MSC1951
only exists in MSC form, so far.
Additionally, this MSC has already been used in the wild for roughly two years by some clients, while MSC1951
only exists in MSC form.

In general, MSC1951 feels like a heavier approach to emote sourcs, while this MSC is more lightweight
and thus should allow significantly larger packs.
and thus should allow for significantly larger packs.