URL encoding doesn't play nicely with emotes

[Your-New-SJW-Waifu]

It doesn't seem to like < and >. In the filename.
e.g. >.<.png

I suspect that has to do with url encoding and the server not properly interpreting a request for https://host.tld/emotes/%3e.%3c.png as a request for >.<.png

[zorglube]

What does the http url RFC says about > & < characters ?
Because as fac as I know, those ones <> aren't alloewd into urls.

[Your-New-SJW-Waifu]

Yeah, you'd have to use URL encoding like this:
https://bae.st/emoji/custom/puniko_%3E.%3C.png

Thar file is saved as 'puniko_>.<.png' on the disk but it is translated correctly to and from URL encoding.

The same doesn't work on MovieNight

[zorglube]

I'm not definitely sure, but I have a strong thought that using special characters to interact with the filesystem will result in issue and missmatch.

[Your-New-SJW-Waifu]

If you sanitize it should be fine.
Another option could be to have something like an optional emotes.json file in there structured like:

{
  "files": {
    "baka": "baka.png",
    ">.<": "excited.png",
    "<3": "heart.png"
  }
}

If the json file is present then it is used instead of the filenames. That way you could still use those characters for emotes but map them to filenames that wouldn't cause issues. In theory you could even map to remote address like if you wanted to serve your emotes from an S3 bucket or image hosting site or something (assuming CORS permitted) and even mix and match. e.g.:

{
  "files": {
    "baka": "https://host.tld/MovieNight/emotes/baka.png",
    ">.<": "https://host.tld/MovieNight/emotes/excited.png",
    "<3": "heart.png",
    "hug": "https://i.imgur.com/K5eApV1.png"
  }
}

[zorchenhimer]

I like the json file idea. That would also allow aliasing without having to play around with symlinks or some nonsense on the OS level.

[Your-New-SJW-Waifu]

Yep I thought of that too but I forgot to say that.
To keep things even simpler you could only use the json file and just put a check at startup where if the file doesn't exist it'll create one based on the filenames.
That way people can be seamlessly migrated to the new emote format.
Another idea is "packs." Basically just subdirectories in the emotes directory e.g. faces/, reactions/, etc. and then have an emotes.json or pack.json file in there to make managing emotes easier.

Could have the emotes.json file be used to load the packs (or files if you want just a big pack) or you could just look in each subdirectory of the emotes directory for the json files.

With the packs approach you could have fields in the file like:

{
 "files": {
   "sneak": "spy/sneak.png",
   "shaken_not_stirred": "spy/shaken_not_stirred.png",
   "martini": "spy/martini.png"
 },
 "pack": {
   "description": "spy emotes",
   "author": "James Bond",
   "share-src": "https://www.spy-for-hire.biz/files/spy-emotes.zip",
   "homepage": "https://www.spy-for-hire.biz",
   "license": "CC-BY-4.0",
   "share-files": true
 },
 "files_count": 3

Another use case for packs is if you run multiple instances you could just load packs from remote address that way for your 10 or even 50+ MovieNight instances you could simply manage your emotes in a single place and all off your MovieNight instances will just pull the latest data wherever they spin up.