My understanding is the old :emoji: format will become obsolete. The new method is to insert an image, which they have made convenient with the emoji picker. Images federate by default, since images are a built-in feature of Lemmy.
So the :emoji: format will continue to display an emoji while using the hexbear site thanks to a patch made by the hexbear admins, but I don't think that will federate. Other instances would see plain text.
edit: Actually that's kind of a downside for Lemmy mobile apps? Those wouldn't have the hexbear emoji picker.
So the :emoji: format will continue to display an emoji while using the hexbear site thanks to a patch made by the hexbear admins, but I don’t think that will federate. Other instances would see plain text.
On the test site it does appear that :this: format inserts the correct image as you described, and so I’d guess it would federate as it should.
In the database, each row on the comments table represents 1 comment. A row has a bunch of columns. One for the creator’s ID, one for the time the comment was created, one for the actual body of the comment, etc. But the comment body is just a bunch of text. The database doesn’t understand that its contents have markdown or emojis or images. It’s all just text. So the emoji logic happens almost entirely on the frontend. And everything that’s sent to the database just needs to be text.
On the client, you type “:emoji-“ and the autocomplete box pops up. You select the emoji you want and it autocompletes the whole name.
where the url is a path to the emoji’s image file.
In both cases, that autocompleted text is what gets sent to the database. The database will always spit back that text. The modified Hexbear frontend will be able to understand and display both the URL version and the legacy emoji picker version. Vanilla Lemmy frontends and apps will only display the URL version.
All this said, it will very quickly only be noticeable when viewing old posts and comments. And most of our valuable old posts and comments are still valuable with or without emojis. It will be annoying for a week tops imo
Thanks for the details. It sounds like there are two things the hexbear frontend does to support the old emoji format:
When entering a message, the emoji picker assists in autocorrecting to proper image markdown format.
When displaying a message (post/comment/etc), the hexbear web frontend replaces old-format emoji text with the <img> while generating the html.
For #1, this is really handy, though it has the limitation that mobile app users of hexbear can't enter proper emojis unless they remember the emoji url. And same for federated users if hexbear federates.
For #2, if we can identify emojis while displaying the html, could this same thing be done in the Lemmy API that provides the post/comment data to other instances or to mobile apps? By this I mean replace :emoji: stored in the database with  format on the fly when we retrieve the data. This would automatically support old posts, federated users, and mobile users in one shot.
I should just submit a PR but first I'd have to figure out how to get the dev environment working 😂
Anyway I recognize I'm just splitting hairs and it doesn't matter in the end!
(Edit: To be clear, I’m not a current dev on this project)
I believe point 1 is custom behavior and point 2 is just a matter of adding a markdown rule but I’m not 100% sure. I believe the emojis repo has a normalized copy of each emoji that could theoretically be downloaded and used like a sticker pack by mobile app users or just uploaded manually, even elsewhere. But an actual sticker pack feature on the app would be a neat and fun feature. As for the thing about showing the legacy emojis to other servers, I’d imagine that involve regex ing every single comment ever sent with a custom list of hard coded emojis and URLs, which is kinda messy, especially for server-to-server federation endpoints
Yeah, good point about it being messy, and I also wonder about performance. But if the hexbear frontend is already doing this text replacement when generating the html, then it must already be a solved problem? Would need to crack open the code to see how it was implemented
I read here that Lemmy isn't doing any kind of caching yet. Wouldn't be really good for performance for them to implement a cache as fast as possible if we'll be posting lots of the same images in many threads?
I asked about this here
My understanding is the old :emoji: format will become obsolete. The new method is to insert an image, which they have made convenient with the emoji picker. Images federate by default, since images are a built-in feature of Lemmy.
So the :emoji: format will continue to display an emoji while using the hexbear site thanks to a patch made by the hexbear admins, but I don't think that will federate. Other instances would see plain text.
edit: Actually that's kind of a downside for Lemmy mobile apps? Those wouldn't have the hexbear emoji picker.
On the test site it does appear that :this: format inserts the correct image as you described, and so I’d guess it would federate as it should.
Can't say I know for sure, maybe a dev can clarify
In the database, each row on the comments table represents 1 comment. A row has a bunch of columns. One for the creator’s ID, one for the time the comment was created, one for the actual body of the comment, etc. But the comment body is just a bunch of text. The database doesn’t understand that its contents have markdown or emojis or images. It’s all just text. So the emoji logic happens almost entirely on the frontend. And everything that’s sent to the database just needs to be text.
On the client, you type “:emoji-“ and the autocomplete box pops up. You select the emoji you want and it autocompletes the whole name.
With the old way, it will autocorrect to this:
With the new way, it will autocorrect to this:
where the url is a path to the emoji’s image file.
In both cases, that autocompleted text is what gets sent to the database. The database will always spit back that text. The modified Hexbear frontend will be able to understand and display both the URL version and the legacy emoji picker version. Vanilla Lemmy frontends and apps will only display the URL version.
All this said, it will very quickly only be noticeable when viewing old posts and comments. And most of our valuable old posts and comments are still valuable with or without emojis. It will be annoying for a week tops imo
Thanks for the details. It sounds like there are two things the hexbear frontend does to support the old emoji format:
<img>while generating the html.For #1, this is really handy, though it has the limitation that mobile app users of hexbear can't enter proper emojis unless they remember the emoji url. And same for federated users if hexbear federates.
For #2, if we can identify emojis while displaying the html, could this same thing be done in the Lemmy API that provides the post/comment data to other instances or to mobile apps? By this I mean replace :emoji: stored in the database with
format on the fly when we retrieve the data. This would automatically support old posts, federated users, and mobile users in one shot.I should just submit a PR but first I'd have to figure out how to get the dev environment working 😂
Anyway I recognize I'm just splitting hairs and it doesn't matter in the end!
(Edit: To be clear, I’m not a current dev on this project)
I believe point 1 is custom behavior and point 2 is just a matter of adding a markdown rule but I’m not 100% sure. I believe the emojis repo has a normalized copy of each emoji that could theoretically be downloaded and used like a sticker pack by mobile app users or just uploaded manually, even elsewhere. But an actual sticker pack feature on the app would be a neat and fun feature. As for the thing about showing the legacy emojis to other servers, I’d imagine that involve regex ing every single comment ever sent with a custom list of hard coded emojis and URLs, which is kinda messy, especially for server-to-server federation endpoints
Yeah, good point about it being messy, and I also wonder about performance. But if the hexbear frontend is already doing this text replacement when generating the html, then it must already be a solved problem? Would need to crack open the code to see how it was implemented
Should be part of the markdown renderer
I read here that Lemmy isn't doing any kind of caching yet. Wouldn't be really good for performance for them to implement a cache as fast as possible if we'll be posting lots of the same images in many threads?
caching of emojis? its just a regular <img> element in html, so it will be cached locally when you first view an emoji.
Wait yeah and all the server does is send the URL. I see now, it shouldn't be a problem.