ratify CHATHISTORY

[slingamn]

Current implementations:

Servers:

• Oragono
• UnrealIRCd

Clients:

• Kiwi (modulo support CHATHISTORY TARGETS kiwiirc/kiwiirc#1616 and conformance with current draft of the chathistory spec kiwiirc/kiwiirc#1397)
• Gamja
• Goguma
• Senpai

Bouncers (as server):

• Soju (does not implement the * target; open issue)
• Kiwibnc (probably with some bugs / incompatibilities)

Networks:

1. https://testnet.oragono.io

Where to: I'd love to see this in a desktop and a mobile client. It would also be useful to have this supported by a server implementation that currently buffers history for autoreplay on channel join: requesting the chathistory cap would suppress the auto-playback, and then CHATHISTORY queries could be answered from the buffer.

[emersion]

It would also be useful to have this supported by a server implementation that currently buffers history for autoreplay on channel join: requesting the chathistory cap would suppress the auto-playback, and then CHATHISTORY queries could be answered from the buffer.

FWIW, soju does exactly this. It's a bouncer though.

[slingamn]

@kylef notes an incompatibility with the chathistory batch spec, which seemingly forbids the use of the * target:

This parameter contains the target of messages within the batch. The target MUST either be the nick of the remote client for private messages or the name of a channel which the local client is in for public messages.

So if possible, we should amend that spec?

[jwheare]

A couple of questions that remain unanswered from the initial draft PR discussion (#393 (comment))

• Is there a reason TAGMSG is only included with event-playback?
• Would e.g. chathistory-events be a better name than event-playback?

[slingamn]

I had some skepticism about this rationale:

There's no risk of TAGMSG causing a state related desync, they are by design lossy, so can't communicate important consistent state.

How is it explicit in the design of TAGMSG that they are lossy? For example, naive implementations of +draft/react would cause a local state change.

As for the name --- what would be the rationale for changing it? To clarify that it's a sub-capability of chathistory?

[jwheare]

They’re lossy because only some clients see them. And they carry no more state than a privmsg. It’s not like a quit or join that affects the channel member list.

[jwheare]

The rationale for changing the events is that the original one doesn’t match the base name. It’s not chat-playback. draft stage means we can change stuff to be better before it becomes permanent.

[slingamn]

I don't have very strong feelings about this either way. I might wait for other people to opine?

[emersion]

IMHO it makes sense to add the prefix, it makes it clearer that the cap belongs to chathistory. Maybe we'll have another spec in the future where "event playback" could mean something else.

[slingamn]

re. amending the chathistory batch type, I forgot our actual "solution" to this: for the * target, we send the user's own nickname as the batch parameter. I can still see a case for amending the other spec to allow * there.

[slingamn]

From discussion, it should be OK for the draft name to remain draft/event-playback, and then for the ratified name to be chathistory-events.

[slingamn]

This is additionally blocked on #450. I plan to take that PR out of draft in a few days, once Oragono 2.6.0 is published.

[syzop]

I have implemented CHATHISTORY in UnrealIRCd according to the current draft specification, it will be in UnrealIRCd 5.2.0. As for the CAPs: it implements draft/chathistory but not draft/event-playback.
I could live with pretty much every aspect of the specification so nice work on that! 👍
I think I hit 1 or 2 small issues, maybe I should dig up my notes on that but.. they may not even be worth mentioning.

irc2.unrealircd.org is online with the current implementation (running UnrealIRCd from git) and can be used by clients for testing. Things are undertested atm as I still need to add CHATHISTORY to our test framework. There's 1 small "known issue" with CHATHISTORY TARGETS not returning a sorted list yet, but that will be fixed before release.

[k4bek4be]

I've ran into an issue with unrealircd and gamja cooperation. The server has a setting to enable history on certain channels, not storing any for the rest of them. Gamja requests CHATHISTORY for any joined channel (i have not read the raw log), and if it happens to be the one with history not enabled, unrealircd sends FAIL INVALID_TARGET. In response, the client displays error messages (in two places) and gives up on any further requests (for different channels). I think this case should be defined in documentation, and my suggestion is to make the IRCd act as there's no history stored, without the hard FAIL error.
INVALID_TARGET is defined by the current spec as either no permissions for the target, or a non-existing target. None of these is true here.