Skip to content

admin: the Twemoji images keep their licence, and the footer credits them - #3346

Merged
colinmegill merged 1 commit into
edgefrom
admin-twemoji-local
Nov 6, 2026
Merged

colinmegill merged 1 commit into
edgefrom
admin-twemoji-local

Conversation

@colinmegill

Copy link
Copy Markdown
Member

What changes, as seen from outside

  • The admin console's footer (home, sign-in, terms, privacy) gains one line: "Emoji graphics from Twemoji, by Twitter, Inc and other contributors, licensed under CC-BY 4.0", linking to the Twemoji repository and the licence.
  • A licence file is published beside the emoji images at /twemoji/14.0.2/LICENSE.txt (text/plain, 19,036 bytes). It states what the images are, where they come from and who made them, followed by the CC-BY 4.0 text as published with Twemoji.
  • The emoji images themselves do not change. The same 15 files are served from the same origin at the same path, /twemoji/14.0.2/72x72/<codepoint>.png, with the same bytes. They already load on pol.is (see Evidence).
  • Size: the admin bundle (gzipped by the build) grows by 131 bytes (205,562 to 205,693). The build gains one text file (90 to 91 files).
  • Documentation only: file-server/nginx/ROUTING.md and a comment in nginx-ssl.site.default.conf still said static files go straight to the file-server. Since the static-asset hotfix (ba34e1620) they go through Node to STATIC_FILES_HOST. The wording now says so. Routing is unchanged.

No schema change. No server code change.

The vendored set

The admin console only renders emoji written literally in its own source (ConversationConfig.js, the knowledge-base links on the home page, the lander footer), never emoji from user text. The vendored set is therefore exactly what it renders: 15 PNGs, 11,949 bytes in all. The existing test "ships an image for every emoji the app renders" fails if someone adds an emoji without its file.

Each of the 15 files is byte-identical to twitter/twemoji@v14.0.2/assets/72x72/<name>, and also to jdecked/twemoji@v17.0.3/assets/72x72/<name> in the maintained community fork. The fork has not redrawn any emoji we use. For comparison, the full 72x72 set is 3,689 files (3.3 MB) at 14.0.2 and 4,009 files (4.2 MB) at 17.0.3. No npm package ships the 72x72 PNGs; they are only in the GitHub tag trees and release archives.

Cause

There was no 404 for any image the console requests. The images have been served from the console's own build since 8a6ed094b ("Clients load no code from third-party hosts at runtime"), at /twemoji/14.0.2/72x72/<codepoint>.png (client-admin/src/util/emoji.js). The 404s that prompted this were probes for 1f600.png and 1f44d.png, two emoji the console has never shipped.

What was missing was attribution. The CC-BY 4.0 notice lived only in a source comment, which minification removes, and nothing beside the images or in the console credited them.

Evidence

  • Read-only checks of pol.is for all 15 shipped paths: 15/15 200 image/png, each body SHA-256-identical to the file in this repository, served through Cloudflare from the static asset bucket. 1f600.png answers 404, as a file that was never shipped should.
  • New tests fail on edge and pass here:
    • the licence sits beside the only Twemoji version shipped;
    • the footer credits Twemoji and links CC-BY 4.0.
  • make check-client-admin: 35 suites, 345 tests passed. Prettier and ESLint are clean on the touched files.
  • Production builds of edge and of this branch: the branch emits twemoji/14.0.2/LICENSE.txt beside the 15 PNGs; the bundle size change is as above.
  • queue-rs/polis-api/conformance/nginx-routing.sh: 78 of 78 checks passed on this branch (prefix twemoji-routing), including "140 emitted static files reach Node"; the image it tested held twemoji/14.0.2/LICENSE.txt beside the 15 PNGs. Its edge-routing step fetches every file in the built file-server image, including each emoji image and the new licence file, through nginx, and requires each to reach Node.
  • Coverage that already existed and still holds:
    • the emoji URL builder points at our own origin (client-admin/src/selfContained.test.js);
    • the browser spec requires the footer emoji to load from /twemoji/ and decode (e2e/cypress/e2e/self-contained/third-party-hosts.cy.js).

Attribution

Twemoji graphics: Copyright 2019 Twitter, Inc and other contributors, licensed under CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/), from https://github.com/twitter/twemoji. The maintained fork is https://github.com/jdecked/twemoji (Jason Sofonia and Justine De Caires). Both projects' attribution sections accept "a mention in a project README or an 'About' section or footer on a website", so the footer line meets that request.

🤖 Generated with Claude Code

…them

The admin console's emoji images have been served from its own build since
the change that stopped clients loading from third-party hosts: fifteen
unmodified Twemoji 14.0.2 PNGs in client-admin/public/twemoji/14.0.2/72x72,
served at /twemoji/14.0.2/72x72/<codepoint>.png. Their CC-BY 4.0 notice
lived only in a source comment.

- client-admin/public/twemoji/14.0.2/LICENSE.txt says what the files are,
  where they come from and who made them, followed by the licence text as
  published with Twemoji. The build copies it beside the images, so it is
  published with them at /twemoji/14.0.2/LICENSE.txt.
- The lander footer (home, sign-in, terms, privacy) names Twemoji, its
  authors and the licence, with links.
- Tests: the licence sits beside the only Twemoji version shipped, and the
  footer carries the credit.
- ROUTING.md and the nginx site comment still said static files go
  straight to the file-server. Since the static-asset hotfix they go
  through Node to STATIC_FILES_HOST. Wording corrected; routing unchanged.

The images, their path and their bytes are unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@colinmegill
colinmegill merged commit 0281f23 into edge Nov 6, 2026
32 of 33 checks passed
@colinmegill
colinmegill deleted the admin-twemoji-local branch November 6, 2026 09:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant