You can skip the "typing ended". You're gonna need a shortish timeout anyway, may as well just let the "typing is happening" messages all terminate by timeout.

That really depends on the UX you want.

What do you have in mind? I can't think of a case where you'd want "X is typing" to persist more than a second or maybe two past the last-received message that affirmed X is, in fact, still typing. I can think of cases in which a short timeout might break down in bad ways (making the notice really jittery on high-latency connections, say) but I think those are probably just situations in which any "... is typing" message is simply gonna be bad in one way or another.

You don't want to clear it after only a second. It should persist much longer since people pause and think between words.

It's common that someone starts typing but immediately change their mind and clears the input after only a couple of characters. So if the timeout is longer you need an "ended" event.

(the "ended" event is the message being sent.)

Except for the scenario the parent is talking about:

> It's common that someone starts typing but immediately change their mind and clears the input after only a couple of characters.

I'm guessing that since it's not a full-duplex connection you have to send those messages out-of-band, ie, with a separate POST request API

But messages themselves are already sent out-of-band as a POST request, if I understand correctly. Don't see why that couldn't be extended to include typing indicators.