FR: persistent or "special" system namespaces for emoji aggregator sites
jpgleg opened this issue · comments
When basic functionality is live, could we consider a genericish web layer that supports a persistent or special non-Slack/Discord layer to map websites into?
Probably too much HTML parsing to be generally applicable, but would be very handy to have a /emojis/slackmojis.com/ or /emojis/cultofthepartyparrot.com/ layer to facilitate more rapid emoji bootstrapping. If either site offers bulk downloads, we could also potentially just have a cronjob pull down the batches periodically.
After some investigation, the best way to add party parrot support is via Github's API:
curl 'https://api.github.com/repos/jmhobbs/cultofthepartyparrot.com/contents/parrots?ref=master' \
| jq . --color-output | less -RAs a nice contrast to Slack and Discord's emoji metadata APIs, this one includes emoji bytes length with the metadata fetch
(Other options I looked at: total HTML scraping; minimal HTML scraping with in-memory zipfile handling; git-upload-pack support. All are much more horrible.)
There's some other emoji collections on github that the same implementation would also work with: https://github.com/SeanPrashad/slackmoji
On top of that, we might also want to build a parser for https://github.com/lambtron/emojipacks/tree/master/packs
It does look like that fetching from https://slackmojis.com/ requires HTML scraping.
However, fortunately https://emoji.gg/ has an API.
There's another issue to be considered here, which is: what do we call this part of the namespace?
/emoji/aggregators? /emoji/well-known? I think that /emoji/packs rolls off the tongue the best, but that's kind of a misnomer for big sites which are just grab-bags; to me, at least, "packs" implies something of a theme.