View Issue Details

IDProjectCategoryView StatusLast Update
0005818unrealircdpublic2021-05-25 18:05
Reporterwestor Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Product Version5.0.8 
Summary0005818: [Feature Request]: Bypass +H chanmode on BOTS (+B) (configurable)
DescriptionHaving a bot that reading the channel text messages is hard to stop +H on join especially if bot using a lot of join catching events, i think a configurable option for this to solve it would be nice.

Also bots can use /HISTORY command anytime if they want to view the channel history.

Configurable Example:

set {
        history {
                channel {
                        /* How many lines to playback on join? */
                        playback-on-join {
                                disable-on-bots yes; // <--------------------
                                lines 15;
                                time 1d;
                        }
                        /* How much history to keep. These are the
                         * upper maximums for channel mode +H lines:time
                         */
                        max-storage-per-channel {
                                lines 200;
                                time 1w;
                        }
                }
        }
}
TagsNo tags attached.
3rd party modules

Activities

PeGaSuS

2021-02-16 21:07

reporter   ~0021894

Instead `disable-on-bots` probably something simpler such as `ignore-bots <yes|no>;` or `ignore-umode B;`.

I do like this idea though.

Cheers

Lord255

2021-02-23 00:17

reporter   ~0021895

++ ! :)

syzop

2021-05-24 16:58

administrator   ~0021975

We could do that, but.. how big is this issue?
This affects bots that implement "server-time" but can't cope with the history on join somehow. Or am I missing something?
Surely it should be really easy for such a bot to fix it, to simply ignore everything inside the chathistory batch?
I mean: we are talking about bots that implement "server-time" but are either missing support for "batch" or for specific logic to ignore the chathistory batch. And these bots are also unmaintained or unwilling to make changes?
Are we talking about specific large (bot) projects? If so, which? :)

Also, as Gottem mentioned in another thread, the question is how much this would solve, as lots of bots don't set special user modes like +B.

PeGaSuS

2021-05-24 17:18

reporter   ~0021976

I've noticed that issue with Limnoria (https://github.com/ProgVal/Limnoria) which is actively maintained.
The issue with it, is that if you type something like "!cycle" (as a custom command to make the bot part and rejoin), it will keep doing it indefinitely until the command disappears from the chathistory.

syzop

2021-05-24 17:27

administrator   ~0021977

Right. Perhaps you could take it up with Limnoria then? ProgVal is actively involved with IRCv3 stuff, right? So they know about all these standards and how easy it would be to ignore chathistory for script triggers.

Lord255

2021-05-24 19:25

reporter   ~0021978

i didnt test egg, but +H causes wrong stats for sure.
(i know pisg is and old project, however one of my bot still having it. :) that generates the stats from the logs. if the bot rejoin a channel and gets back 100 lines (just an example), that can add extra words/lines/whatever to someone's stats. idk if eggdrop handles this or not. just sayin. this is why i said its a good idea ("++")).

Valware

2021-05-25 15:33

reporter   ~0021980

as someone who writes bot stuff, I feel like it would be my duty as the maintainer of the bot to implement a way to differentiate between replayed messages and new messages. I also think having an option to just "disable" for bots is counter-intuitive as well, as by the same logic, I could want ONLY my bot to see the replayed messages.
but then, I believe whole history playback thang is going to have some different/extra implementation.

either way, if you are a bot, perhaps just simply ignore messages atfer you've joined a channel whose timestamp is from before you joined the channel

syzop

2021-05-25 17:58

administrator   ~0021981

Eggdrop does not support "server-time" so is unaffected. That's why I ask for concrete examples, to learn more about the actual problem instead of only theory.

I agree with Valware. I think this should be handled in bots. It's easy for them.

syzop

2021-05-25 18:05

administrator   ~0021982

I'm closing this one. This problem limits itself to software that supports "server-time" but does not ignore "chat-history" batches.
I suggest anyone experiencing that problem to take it up with the bot software developer(s). If those devs feel this is a problem too, then they should not fire scripts on history or fire events in a different way, whatever they like.. up to them.
If the bot developer does not see this as a problem, then why should we?

I also agree with both Gottem (in the PR) and Valware (in this issue) that it would be weird and possibly unwanted not to send it to bots, as some (bot) people may actually want history. And as, said, many bots don't request +B so the usefulness of all this is limited anyway.

Last but not least, if bots don't want to receive history then they can soon CAP REQ draft/chathistory or CAP REQ chathistory (whichever is available), see https://ircv3.net/specs/extensions/chathistory. If you CAP REQ that as a client then you won't receive history on join. And the bot software already supports capabilities since they apparently CAP REQ'd server-time, so it should be no issue for them :)

Issue History

Date Modified Username Field Change
2021-02-16 20:55 westor New Issue
2021-02-16 21:07 PeGaSuS Note Added: 0021894
2021-02-23 00:17 Lord255 Note Added: 0021895
2021-05-24 16:58 syzop Note Added: 0021975
2021-05-24 16:58 syzop Status new => feedback
2021-05-24 17:18 PeGaSuS Note Added: 0021976
2021-05-24 17:27 syzop Note Added: 0021977
2021-05-24 19:25 Lord255 Note Added: 0021978
2021-05-25 15:33 Valware Note Added: 0021980
2021-05-25 17:58 syzop Note Added: 0021981
2021-05-25 18:05 syzop Assigned To => syzop
2021-05-25 18:05 syzop Status feedback => closed
2021-05-25 18:05 syzop Resolution open => no change required
2021-05-25 18:05 syzop Note Added: 0021982