FR: persistent or "special" system namespaces for emoji aggregator sites

[jpgleg]

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.

[cdanis]

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 -R

As a nice contrast to Slack and Discord's emoji metadata APIs, this one includes emoji bytes length with the metadata fetch :smile:

(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.

[cdanis]

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.