View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005818 | unreal | ircd | public | 2021-02-16 20:55 | 2022-05-27 08:51 |
| Reporter | westor | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 5.0.8 | ||||
| Summary | 0005818: [Feature Request]: Bypass +H chanmode on BOTS (+B) (configurable) | ||||
| Description | Having 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; } } } } | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Instead `disable-on-bots` probably something simpler such as `ignore-bots <yes|no>;` or `ignore-umode B;`. I do like this idea though. Cheers |
|
|
++ ! :) |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 ("++")). |
|
|
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 |
|
|
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. |
|
|
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 :) |
| 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 | |
| 2022-05-27 08:51 | syzop | Relationship added | has duplicate 0006116 |
