Event playback (JOIN/PART/QUIT/NICK/etc as part of chathistory)

[dequis]

The chathistory batch is currently limited to PRIVMSG and NOTICE and has no way to some events because they may be processed by the client in a way that affects the present channel state.

• JOIN
• PART
• QUIT
• NICK
• KICK
• MODE
• TOPIC

And I'm probably missing something. Other pieces of information that may be missing in a replay are:

• user prefixes (@ before nicks)
• away state (may matter if any clients color nicks differently)
• real name (sometimes the real name is displayed right next to the nick)
• hostmask (right click to ban?)

Not sure about the importance of these last few.

From #156, describing the issue:

Could this also handle joins/parts/quits/nicks? These are currently problematic due to being global (a replayed NICK would affect global state).

JOINs are problematic too, even though they are not global. In order to send them, server needs to send outdated list of users in channel in state how it was at beginning of the playback. It's possible to implement of course, but still harder than just applying batch tag to PRIVMSGs.
That's why ZNC's buffextras sends JOINs, QUITs, etc. as PRIVMSGs too, originating from *buffextras, and client-side script can render them as "proper" join instead.

See also current discussion at #292

Some ideas:

• A new capability and a message tag marking the event as playback. The events would be sent the same way, but clients are expected to avoid modifying the state and only display the message.

• Same as above, but rely on the chathistory batch to mark the event as playback.

• A new capability to allow sending a new verb that wraps the original event. For example: :source EVENT JOIN #channel.

  Might make it easier for client developers to make it a purely visual thing. This is my favorite idea so far.

• No new capabilities, but send buffextras-style PRIVMSGs with message tags describing the event in a machine-readable way (if the message tags cap is enabled).

  Would be compatible with current implementations of chathistory that display a few messages before the user joined. Allows clients to be very lazy. But there's no real need to think in terms of legacy compatibility this time.

• Complementing any of the above, send extra user metadata like prefix as message tags applying to replayed privmsgs.

[DanielOaks]

If I could put forth a rough suggestion, perhaps something along these lines would work?

event-playback extension

If the event-playback capability is enabled, the chathistory batch can contain messages other than PRIVMSG and NOTICE. This allows servers and bouncers to play back channel joins, parts, and similar messages for clients to display.

By enabling this capability, the client acknowledges that it can correctly display (but not process as real incoming messages) events within chathistory batches.

[grawity]

Is the batch guaranteed to be limited to a single channel? (Some events, like QUIT or NICK, have a channel parameter.)

[dequis]

@grawity in the case of chathistory, yeah, there's a target parameter.

@DanielOaks That would be the second suggestion from my first post. I'm slightly concerned about the possible implementation bugs that lead to the event getting accidentally processed. Not sure if other clients share this concern. Not even sure if it's a real concern.

Also: We really should enumerate and limit the allowed verbs.

[ghost]

A new capability and a message tag marking the event as playback. The events would be sent the same way, but clients are expected to avoid modifying the state and only display the message.

As @DanielOaks said, this seems like the best way to go about it. The additional events would only be sent to the client if the capability is supported and it would be the sole responsibility of the client to properly display the results.

I'm slightly concerned about the possible implementation bugs that lead to the event getting accidentally processed.

Would there be any issues with using a custom event type and specifying what it represents in a message-tag? @event-type=JOIN :foo!bar@example.com EVENT :#channel

This could potentially eliminate clients from processing the events unless it can handle an EVENT with a specified event-type

Edit: Disregard this comment. Misunderstanding cleared up below.

[grawity]

Would there be any issues with using a custom event type and specifying what it represents in a message-tag? @event-type=JOIN :foo!bar@example.com EVENT :#channel

That seems a bit forced... The event type is already a core, required parameter to EVENT – there is no reason to make it a tag rather than a regular param.

This could potentially eliminate clients from processing the events unless it can handle an EVENT with a specified event-type

No it wouldn't. The clients would still be checking the event type the same way (throwing it at a case..in or if..elif or a dispatch table) no matter where they obtain the parameter from.

[dequis]

(this is probably going to sound nitpicky, just want to be clear any confusion)

As @DanielOaks said, this seems like the best way to go about it

Note that the bullet you quoted (1) is slightly different from what dan suggested (2). That's the one with a message tag, not the one that relies on the batch.

Would there be any issues with using a custom event type and specifying what it represents in a message-tag? @event-type=JOIN :foo!bar@example.com EVENT :#channel

This could potentially eliminate clients from processing the events unless it can handle an EVENT with a specified event-type

I think there may be a misunderstanding here, what I said about accidentally processing the event applies to bullets 1 and 2 and dan's version of 2 of regular verbs wrapped in a batch (@batch=foo :source JOIN :#channel), but it's not an issue when using a new wrapping verb like EVENT. Functionally, your suggestion is the same as :source EVENT JOIN #channel, just moving one parameter to a more awkward place (what grawity said)

[ghost]

@dequis Misunderstanding cleared up - disregard my original comment.

A new capability and a message tag marking the event as playback. The events would be sent the same way, but clients are expected to avoid modifying the state and only display the message.

Seconded. If possible, the original message should be left "as-is" and additional tags added if needed. The chathistory batch type already follows this standard with messages untouched. If the client supports the event-playback cap, extra events are sent as part of the chathistory batch. Otherwise, only PRIVMSG and NOTICE are sent.

What tags would be needed for this? If the client supports the capability, the use of a chathistory batch type with only supported events should suffice.

[delthas]

Merged in #393, this can be closed.