Batch: Group related IRC events.

Open, attach, and close a batch #

S: :irc.example BATCH +lot1 netsplit irc-a.example irc-b.example
S: @batch=lot1 :Bob!u@cloak.example QUIT :Connexion interrompue
S: @batch=lot1 :Chloe!u@cloak.example QUIT :Connexion interrompue
S: :irc.example BATCH -lot1

The server opens the batch with + followed by an opaque identifier, then a type. Associated messages carry the corresponding batch tag. The batch ends with - followed by the same identifier. The identifier is case-sensitive; do not assign it business meaning.

Batch negotiation and type #

The client requests batch capability and awaits ACK. It must understand the tag format. Batch types are not a list negotiated via CAP: each extension describes the meaning of its type. An unknown type does not permit removal of its content.

An empty batch is possible. Multiple batches can interleave, and batches can be nested. A single global buffer or an assumption 'all subsequent messages belong to the batch' would misinterpret valid exchanges.

History and current state #

The chathistory type groups past events. Do not kick out a currently present member simply because an old QUIT appears in a historical batch: visual restitution and current state mutations do not have the same function.

As of the verification date, the chathistory request capability remains draft/chathistory, while the chathistory batch type is finalized. The draft/multiline extension still describes another use. Batch support does not promise these features.

Bound and terminate processing #

• Maintain a batch table by identifier, not a single variable.
• Maintain connection with a potential parent batch.
• Limit batch size and number, then manage transport interruptions.
• Do not display a replay as a new user action nor automatically respond to historical events.

• Read the batch tag. →
• Preserve the original timestamp. →