BoarAvoir

joined 2 years ago
[–] BoarAvoir@hexbear.net 6 points 2 years ago (1 children)

Working on this very site. So nothing cool, no

[–] BoarAvoir@hexbear.net 15 points 2 years ago* (last edited 2 years ago)

I really hope we can restore the old Active algorithm, it's still on the table afaik, but I'm told the way that lemmy's database schema works has changed enough that it isn't trivial to switch back to.

[–] BoarAvoir@hexbear.net 3 points 2 years ago

Also dosent all modern operating systems have extracting files Just build in regardless of the format?

data-laughing No.

[–] BoarAvoir@hexbear.net 10 points 2 years ago* (last edited 2 years ago)

HOW AM I JUST FINDING OUT WE OWN HEXBEAR.COM???? WHICH ONE OF YOUZE

[–] BoarAvoir@hexbear.net 6 points 2 years ago (1 children)

Yes, you are on the right track.

What actually happened is, for the migration back to upstream lemmy, our devs developed and contributed the custom emoji feature, so that we could keep them, but since we were uploading them through the UI not baking them into the app when it was built as static assets, they had to go into pictrs (the image backend), which doesn't support SVGs yet. So as part of our migration we converted all SVG emotes back to PNG (apparently at a pretty substantial resolution).

They render correctly on our side because the UI recognizes that they are a local custom emoji and applies different CSS than we do for other embedded images, but as currently written, there is no simple way to differentiate a federated emoji from any other embedded image, so when federated, our emoji get rendered as just any image, at whatever size the file is. We will likely contribute a fix for this upstream, though resizing all of our emotes to a consistent size would also do the trick, and may be undertaken as a stopgap in the mean time.

[–] BoarAvoir@hexbear.net 14 points 2 years ago* (last edited 2 years ago)

yes! Movie night going on now at live.hexbear.net