Typing notifications for IRC
Elizabeth J. Myers
20 Jan 2011



1) Background

Many IM service provide a functionality where typing in the message box sends a
notification to the other client that you are typing a message. This feature
may be considered desirable to many users.

Various IM protocols do have problems with stale notifications or notifications
being unreliable. We aim to avoid these pitfalls in our implementation. The
goals for IRC typing notifications are as follows:

  1) Make it easy to integrate into clients via scripts.
  2) Make the notifications optional.
  3) Ensure notifications aren't too resource or bandwidth intensive.



2) Negotiating support

Support of typing notifications is negotiated via the CAP extension, using the
type-notify capability. See the CAP specification for more information
regarding the implementation of such. Typing notifications remain in effect for
the duration of the IRC session.

Some users may only want typing notifications for users. To support these users
and to avoid wasting resources, users must explicitly state which notifications
they wish to recieve via the TYPENOTIFY message as follows:

TYPENOTIFY [1|2|3]

TYPENOTIFY 1 specifies users-only. TYPENOTIFY 2 specifies channels-only (this
is not likely to be used, but is implemented for the sake of completeness).
TYPENOTIFY 3 specifies that the user wishes to recieve notifications for both
channels and users. Users shall not issue a TYPENOTIFY message after they have
already issued one. Additionally, no notifications shall be sent until the user
issues a well-formed TYPENOTIFY message.



3) Notifications

The actual notifications are pushed to the client via the ISTYPING, ENDTYPING,
and PAUSETYPING statements. The format is similar to PRIVMSG:

:user!ident@host ISTYPING [channel|user]
:user!ident@host PAUSETYPING [channel|user]
:user!ident@host ENDTYPING [channel|user]


ISTYPING

When a user is typing, they may issue an ISTYPING command to the directed
channel or user. ISTYPING messages which are issued within too rapid of
succession of each other should be silently ignored by the server (usually only
one message per three seconds, but this is left undefined; sane values are
recommended to avoid excessive bandwidth and resource consumption). ISTYPING
messages sent to a channel that already has the user marked as typing shall be
silently ignored.

Upon a channel join, if the user havs TYPENOTIFY 2 or 3, they shall be sent a
"burst" of all pending typing notifications.


PAUSETYPING

When the user has paused typing, they may send a PAUSETYPING message to the
channel or user. Note that this command shall have no effect on the internal
state of the typing status; is to be merely forwarded and possibly tracked.
Servers which do not have the client marked as currently typing shall silently
drop the message.

This command should be flood tracked in a similar manner to ISTYPING.


ENDTYPING

When a user has deleted all the content of their text input box, they may issue
an ENDTYPING message to signal they are not typing anymore. Note that an
ENDTYPING message shall be silently ignored if the user has not previously
issued an ISTYPING message to the given target.

After five minutes of an ISTYPING message being sent and no notification of the
end of typing (PRIVMSG, QUIT, PART, etc.), the user's ISTYPING stauts should be
cleared and an ENDTYPING notice is sent by the server to the target channel.
This is to avoid a client having a lot of stale ISTYPING notifications lying
around.



3) Clearing notifications

Servers and clients shall clear the typing status of a user when one of these
conditions are met:

  1) The user has issued a PRIVMSG to the target
  2) The user or target has QUIT
  3) The user has PART (applicable to channels only)
  4) An ENDTYPING message has been recieved from the user
  5) The user has been muted



4) Tracking typing status

Servers and clients shall track the status based on the recieving of ISTYPING
and ENDTYPING messages, provided they fulfil the conditions above. The typing
status of a user shall be tracked based on channel. Typing statuses between
users should not be tracked; there is little reason to, and it could be a
potential resource hog. ISTYPING notices may be tracked, however, for the
purposes of spam or flooding checking.

Servers shall only track notifications that are considered valid; invalid
notifications shall not be acted on.



5) Avoiding floods

Typing notifications should filtered the same way channel PRIVMSG's are with
regards to flood control and such. For the purposes of flood control, an
ISTYPING or PAUSETYPING  message should be considered the same as a PRIVMSG or
a NOTICE. However, ENDTYPING messages shall not be flood tracked; users cannot
send ENDTYPING messages to a channel without an ISTYPING message, and doing so
could cause clients to have a lot of stale typing statues lying around.