User-defined ephemeral room events (MSC2477): what scope would you accept?

[rubinsh]

I run a private Tuwunel instance for a multi-agent setup, where bots do long-running work in rooms. When a bot is busy there's no way to show what it's doing — thinking, running a tool, waiting for approval — the way a typing indicator does, but carrying metadata.

Nothing existing fits. m.typing has no metadata. Presence is global, string-only, not room-scoped. To-device requires device enumeration and isn't a room broadcast. Appservice ephemeral support handles known typing/receipt EDUs, not arbitrary client-originated room EDUs.

Your compliance table lists MSC2477 as unsupported, and its motivation names this case directly: "regular status updates to a user-requested long-lived task, which a bot might have started for a received event." The proposal text hasn't changed since 2022, though the PR is still open.

I have a working local patch — a client endpoint for user-defined ephemeral room events delivered via /sync — that I'd rather upstream than carry. It's a proof, not submission-ready: it bypasses the standard auth path, has no transaction dedup, and its retention is unbounded. I'd fix all of that.

Before I clean it up and open a PR, what scope would you consider merging?

1. A refreshed full MSC2477, including federation and its room-version/power-level model.
2. A clearly named local-only unstable subset that doesn't claim MSC compliance.
3. Something narrower, purpose-built for bot/agent status.
4. Not interested — I'll keep carrying it locally, no hard feelings.

Happy to implement the agreed shape properly: standard authenticated request path, transaction deduplication, strictly bounded retention, expiry, rate limits, and real route and integration tests.

I asked in #tuwunel:grin.hu first, per CONTRIBUTING, but it scrolled past.