IRCv3.2 batch Extension

Copyright © 2012 William Pitcock <>

Copyright © 2014 Kythyria Tieran <>

Copyright © 2014 Alexey Sokolov <>

Unlimited redistribution and modification of this document is allowed provided that the above copyright notice and this permission notice remains intact.

The batch client capability

This extension describes a capability which causes a new verb to be sent to clients when the IRC server wishes to designate that a series of events are related to each other.

Use-cases include visual suppression of netsplits and netjoins.

This client capability MUST be named batch.

The BATCH verb

The IRC server will send a BATCH verb when it wants the client to begin batching events together, and send another BATCH verb when the transaction is concluded.

The following syntax MUST be used when starting a batch:

BATCH +reference-tag type [<parameter 1> [<parameter 2> ... [<parameter n>]]]

The following syntax MUST be used when ending a batch:

BATCH -reference-tag

The reference tag MUST be treated as an opaque identifier. Reference tag MUST contain only ASCII letters, numbers, and/or hyphen, and MUST be case-sensitive.

The type parameter indicates how messages are associated. The meaning of the additional parameters (if any) depend on the type.

The batched events MUST use batch message tag referring to the batch’s reference tag. Messages before start and after end of a batch (including start and end messages of that batch) MUST NOT refer to that batch.

For every started batch, server MUST end that batch. Client MAY delay processing the batched events until they have received and/or processed the end of the batch.

An empty batch is allowed, and SHOULD be treated as a no-op, unless demanded otherwise by the specification for that batch type.

Start and end messages of one batch MAY refer to another batch. If they do, they both MUST have batch tag, and they MUST refer to the same batch. This means that one batch is nested to another. Client MAY delay processing messages of inner batches to the end of outermost batch.

Specifications for batch types

Batch types are specified by IRCv3 extensions, vendor-specific types MUST be prefixed the same way as how vendor-specific capabilities are prefixed. See capability negotiation for the exact details.

The full batch type name MUST be treated as an opaque identifier.

While batch types are similar to capabilities in this aspect, unlike capabilities, batch types are not advertised by servers nor explicitly requested by clients.

Client MAY use the type to change how the messages are presented to the user, e.g. by collapsing them into one message. Client MAY ignore the type and process messages one by one. For example, that happens if the type is unknown to the client.

To submit a new batch type please follow the extension submission procedure found here.


A simple batch BATCH +yXNAbvnRHTRBv netsplit irc.hub
@batch=yXNAbvnRHTRBv :aji!a@a QUIT :irc.hub
@batch=yXNAbvnRHTRBv :nenolod!a@a QUIT :irc.hub
:nick!user@host PRIVMSG #channel :This is not in batch, so processed immediately
@batch=yXNAbvnRHTRBv :jilles!a@a QUIT :irc.hub BATCH -yXNAbvnRHTRBv

Interleaving batches BATCH +1
@batch=1 :nick!user@host PRIVMSG #channel :Message 1 BATCH +2
@batch=1 :nick!user@host PRIVMSG #channel :Message 2
@batch=2 :nick!user@host PRIVMSG #channel :Message 4
@batch=1 :nick!user@host PRIVMSG #channel :Message 3 BATCH -1
@batch=2 :nick!user@host PRIVMSG #channel :Message 5 BATCH -2

Client may show the messages on the channel in order 1,2,3,4,5, or in order 1,4,2,3,5, among others.

Nested batch BATCH +outer
@batch=outer BATCH +inner
@batch=inner :nick!user@host PRIVMSG #channel :Hi
@batch=outer BATCH -inner BATCH -outer

Notice that PRIVMSG line will be processed when batch outer ends, because end of batch inner is tagged by batch outer. The order in which these two batches start doesn’t matter.


Previous versions of this spec did not specify that the full batch type name MUST be parsed as an opaque identifier. This was added to improve client resiliency.