Proposal: an optional activity label in typing indicators (kind 20002)

Inizia con useChannelTyping e TypingIndicatorRow per tracciare come gli eventi di digitazione raggiungono la riga di digitazione desktop, quindi esamina il bridge simulato e la copertura E2E esistente. Esamina kind.rs e NOSTR.md per la definizione dell’evento di digitazione e le aspettative relative alla documentazione. Il lavoro è completato quando il contenuto non vuoto viene limitato e mostrato per un solo utente che sta digitando, il contenuto vuoto rimane invariato, pub/sub lo trasmette in entrambe le direzioni e la copertura elencata ha esito positivo.

Summary

Typing indicators (kind 20002) tell members that someone is active, but never what they are doing. For agent members (buzz-acp harnesses, custom bots), a short activity label in the typing row — Twaky is typing — reading the Journal… — would make agents noticeably more transparent without any new UI surface.

Motivation / use case

We run a personal agent (Twaky) inside Buzz communities. While a turn runs (15 s to several minutes) the channel only shows "Twaky is typing…". We currently publish a per-tool status as a NIP-38 user status (kind 30315); it works with zero upstream change, but renders subtly (emoji + tooltip next to the agent's name) — away from where users actually look during a turn: the typing row.

An optional activity label on the typing event itself solves this exactly where users look, for any agent harness, with no new surface.

Closest existing work I found: #2646 (live agent activity in status pills — a different, richer surface; this proposal is deliberately much dumber). No duplicate found in open issues/PRs.

Proposal

Convention: a typing event whose content is non-empty carries a short activity label (publishers SHOULD keep it under ~80 characters). Clients rendering the typing row append it when exactly one member is typing:

• Alice is typing — reviewing the quarterly report…
• Empty content (what every publisher sends today): unchanged Alice is typing….

Why content rather than a new tag:

• NIP-38 precedent: user-status text already rides in content (kind 30315).
• No structural change anywhere: the relay already fans ephemeral events out verbatim (the PR adds a conformance assertion that typing content round-trips through pub/sub).
• Mobile can adopt later with a one-line read.

What this is NOT:

• Not a change to buzz-acp: it cannot know its agent's current activity, and harnesses that publish their own labeled typing can already own the indicator via --no-typing. A static configured label could be a follow-up if you want one.
• Not ACP-derived activity: that overlaps with the agent-activity work already in flight (#2646); this works for any publisher, including non-ACP bots.

Scope of the PR I intend to send

• Desktop: parse + bound the label in useChannelTyping, thread it to TypingIndicatorRow (rendered in the single-typer case only), mock-bridge support, E2E coverage.
• Conformance: assert a typing event's content round-trips through pub/sub.
• Docs: NOSTR.md and the kind.rs comment for KIND_TYPING_INDICATOR.
• Mobile: unchanged (ignores content exactly as today); happy to include the parity one-liner in the same PR if you prefer.

Backward compatibility is total: every existing publisher sends empty content, every current client ignores it, and old clients keep rendering today's label.

Happy to adjust the convention (tag vs content, length cap, multi-typer behavior) before I finalize.