[LarsenClose]

What changed and why

Picking a keycap emoji such as 1️⃣ as a Tiny reaction said "That reaction isn't allowed here.", and a keycap someone else had put on a message was dropped. unicode_emoji refused any reaction with an ASCII letter or digit in it, and a keycap starts with one (1, U+FE0F, U+20E3). tinyserver takes keycaps: one_emoji("1️⃣") is in its tests.

unicode_emoji now lets a digit through when the keycap mark U+20E3 follows it, with or without U+FE0F between. A bare digit, a word, a shortcode and a path are still refused.

Type

• feature
• fix
• perf
• refactor
• chore
• docs

Platforms

• windows
• macos
• linux
• android
• ios

Proof

Scenario: e2e/scenarios/keycap-reaction.

TINYCLIENT_PROVE=keycap-reaction runs the filter the Tiny adapter applies to reactions it sends and receives. It exits 0 only when 1️⃣, 0⃣ and #️⃣ pass and 1, 10️⃣, 1 with U+FE0F, and :one: do not. A build without the fix ignores the variable and keeps serving, so the driver fails there.

• a_keycap_is_a_reaction_and_a_bare_digit_is_not

Local runs, Linux:

• The test fails on main at its first assertion, unicode_emoji("1\u{FE0F}\u{20E3}"), and passes here.
• The driver against a debug chatd from this branch printed prove-exit:0 and passed in 0.1 s. Against one from main it kept serving and failed at the 45 s timeout.
• cargo test -p chatd --lib: 502 passed, 10 ignored, 1 failed. The failure is plain_http_off_the_persons_network_is_asked_about_before_anything_is_sent, which fails the same way on main on that machine: its outbound proxy answers for the address the test expects to be unreachable. I did not run cargo test --workspace; the change is only in chatd.

Lab run: none.

Compatibility

No protocol change. An older client still refuses keycaps; the server already takes them.

Risk and rollback

Low. Only a digit directly before U+20E3 is let through. Revert the PR to refuse keycaps again.

Release note

Keycap emoji such as 1️⃣ work as Tiny reactions.