ratify CHATHISTORY #437
Comments
FWIW, soju does exactly this. It's a bouncer though. |
|
@kylef notes an incompatibility with the chathistory batch spec, which seemingly forbids the use of the
So if possible, we should amend that spec? |
|
A couple of questions that remain unanswered from the initial draft PR discussion (#393 (comment))
|
|
I had some skepticism about this rationale:
How is it explicit in the design of TAGMSG that they are lossy? For example, naive implementations of As for the name --- what would be the rationale for changing it? To clarify that it's a sub-capability of |
|
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. |
|
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. |
|
I don't have very strong feelings about this either way. I might wait for other people to opine? |
|
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. |
|
re. amending the chathistory batch type, I forgot our actual "solution" to this: for the |
|
From discussion, it should be OK for the draft name to remain |
|
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. |
|
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 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 |
|
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 |
|
|
|
gamja already uses |
|
Ah, but if you JOIN a channel then switch to its tab, gamja will try to request history for it to populate the scrollback. |
|
Personally, if I was a client coder, I would just try to fetch history of every channel that I join, and deal gracefully with any error conditions. I see |
Right. But I wonder what "deal gracefully" means with the existing spec. |
This should be covered by |
|
That's my understanding as well;
|
|
About retrying, i see one case: the user joined a channel when history was not enabled, left, then someone enabled the history. The user should receive it after re-joining. |
|
Something else that came up again is: how should clients figure out that they've reached the end of the chat history (ie, there are no more messages to fetch)? Some servers might want to filter out messages if the user doesn't have the permission to see them. gamja currently assumes that if the server returns less messages than the limit, there are no more messages. It would be possible to change this logic to something like zero messages returned means no more history, but in pathological cases (the full page is filtered out by the server) this still breaks. msgid and timestamp based heuristics are error-prone. References: |
|
There was a small discussion on this in the draft PR: Starts here #393 (comment)
|
|
There are two slightly different issues here: (a) If the client receives fewer messages than the requested limit, can the client assume that there are no more messages available? I'm leaning towards yes on (a) and no on (b). If other people feel similarly, I'll amend the spec to make (a) explicit. |
|
Sorry, I think I neglected two open issues on this thread. The first is the resource cost of
It seems to me that The other is the incompatibility between gamja and unrealircd. Is this still an issue? What can be done to resolve it? |
|
To clarify, the intent of TARGETS was that it would typically list only the channels that the user is currently joined to, which should make it significantly cheaper than LIST. |
The thing is that, for each channel that the user is in, it needs to do quite a bit of processing (per channel!) due to the two arguments that TARGETS supports (start and end timestamp) and the need to return something based on that. Due to the timestamps I basically have to travel line by line through the chat history of a channel (can stop on the first match though). And the thing is with TARGETS we need to do that processing * xx channels. |
I kinda lost track of this one. What do you want me to send when history is not enabled for a channel (or any target)? Let me know and if this is different than what we send now I will be happy to update UnrealIRCd. |
gamja used to completely stop fetching history when a single CHATHISTORY query failed. This was a gamja bug but it's now fixed. gamja will still print an error message to the user if the server sends |
The intent of the specification was that the selectors would only match the time of the latest message sent in the channel:
This probably needs to be clarified explicitly in the spec, but this is the intended meaning and the behavior implemented in Ergo --- the selection parameters in |
|
Yeah, you should be able to just store one timestamp per channel for a naive impl. |
|
From chats on OFTC, there's some agreement that history would be helpful, in particular for support channels, but it really needs to be opt-in per channel. At the moment the spec doesn't speak to that, but I think it would help to encourage networks to adopt the feature if e.g. a channel mode could be specced. |
|
I don't think we'd be able to agree on a mode letter, but also, this seems like the kind of question (opt-in versus opt-out) that is more naturally left implementation-defined or operator-configurable? I think this could be a good fit for an addition to the "implementation considerations" or "security considerations" section, something along the lines of: "Implementations should give server and channel operators flexible and transparent mechanisms to enable or disable history, according to the needs of individual communities on their networks." |
|
It could be left to implementations to define, but fragmentation would be inevitable. A standard mode would let clients represent in the UI when a channel has history enabled, and give a clear compatibility target for devs. Currently Unreal and Insp implement channel history, controlled with mode +H n:t, where n is the number of messages to keep, and t is the time period to keep them for. Resetting the mode will clear the history buffer. Could there be consensus on standardising +H? I think it would be a great addition. |
|
I think the whole +H stuff and notes on configuration would be a bit out of scope. Some reasons have been mentioned, but also because: 1) There will be servers that always have chat history enabled that don't set any channel mode (no opt-in nor opt-out), i don't think it is for us to judge on that. 2) Chat history could also be very well implemented in a bouncer, providing it to clients, even when servers don't support it (and hence won't support +H either). 3) Finally, chat history can also apply to non-channels (PM's), which is actually much more privacy sensitive, and in such a case no MODE applies. I think this spec is in the final stages, just needs some polishing / clearing up and then it is done. Or am I too optimistic? :D Also, perhaps the opening post can be updated a little to include UnrealIRCd under servers, with a checkmark, as it is implemented since 5.2.0 which was released on 14 Jun 2021 and is loaded by default. Makes it clear that the draft implementation is available a lot more than how it looks now if a random new person looks at this PR for the first time. (And of course, if you know of more implementations add them too) |
So... should gamja be changed in some way, or must we change something on the UnrealIRCd-side? Just want to know what needs to be done and by who :) I have no particular opinion on the matter.. we send FAIL INVALID_TARGET now which may be totally fine, or we can send an empty batch instead, or we can send a new error for this particular case. Whatever needs to be done. |
|
I'd slightly prefer it if the server sent an empty batch, but I don't feel strongly about it. @slingamn said he feels the same on IRC. |
|
Ok, done, sending an empty batch now. Should be in next UnrealIRCd release (5.2.3 / 6.0.1). |
|
@slingamn I think you can add Goguma to the list of clients |
|
senpai also supports CHATHISTORY FWIW |
|
One thing I'd like to get more feedback on before ratification is |
|
I feel it only makes sense when linking specific messages, but no one implements IRC URLs either :/ |
|
It also makes sense in the context of text search. #496 says:
|
|
Current implementations:
Servers:
Clients:
Bouncers (as server):
*target; open issue)Networks:
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.
The text was updated successfully, but these errors were encountered: