Copyright © 2014 Attila Molnar <firstname.lastname@example.org>
Copyright © 2014 J-P Nurmi <email@example.com>
Unlimited redistribution and modification of this document is allowed provided that the above copyright notice and this permission notice remains intact.
This client capability MUST be named
If enabled, servers MUST send
NOTICE messages back to
the client that sent them. If servers apply any modifications to these
messages, they MUST send the final version of the message back to the
For clients, receiving a message with themselves as the sender acts as
an acknowledgement that the message has been delivered to the server.
Clients that receive self-sent
NOTICE messages, MUST
treat them the same way as if the client itself would have sent the
message to the target. Clients may choose to disable local echoing
NOTICE messages altogether, or present them
in pending state.
The capability is useful for clients to get an acknowledgement that a message was delivered. It can be also used for measuring lag between client and server, that is, the time it takes from sending a message to receiving it back.
Furthermore, the capability is useful for users that have multiple clients attached to a bouncer. In this scenario, when users send messages from one client, the messages get automatically relayed to other attached clients. This allows all attached clients to display full conversation.
Servers MAY send a faked message back to the client instead, in cases where the final version is silently blocked, for example when filtering spam.
To prevent perceived input lag, clients may choose not to wait for an acknowledgment from the server before displaying sent messages to users. Clients may instead choose to display a temporary local message that is replaced once the
echo-message acknowledgment is received. However, correlating these is not straightforward, as the server may modify them before acknowledgment. There are also additional complications for self-targeted private messages.
labeled-response specification addresses this limitation.
In the following examples,
firstname.lastname@example.org presents a client
that has enabled the
--> PRIVMSG Attila :hi :email@example.com PRIVMSG Attila :hi
The client interprets the received message as if it had sent a
with contents “hi” to
Another example where a server modifies a message by filtering out text formatting and sends the final version back:
--> PRIVMSG #ircv3 :back from \02lunch\0F :firstname.lastname@example.org PRIVMSG #ircv3 :back from lunch
Previous versions of this specification didn’t include the Limitations section.
Previous versions of this specification didn’t allow for faked messages when filtering spam.