degesch: use MONITOR for PM user tracking #3

Open
opened 2 years ago by p · 0 comments
p commented 2 years ago
Owner

See https://ircv3.net/specs/core/monitor-3.2, notably implemented by Freenode.

Use this to track users we have an open PM buffer for but don't share a channel with. Use a str_map indexed by their nickname, limit the amount of entries by the MONITOR value--first come, first served. Right after connecting, this becomes all PM buffers. Unsubscribe once we start sharing a channel, subscribe once we stop or a new PM buffer is opened and we don't share a channel at the moment.

See comment in irc_handle_quit() for more considerations: when a PM buffer is open, set an "offline" flag in the user when he QUITs and upon ERR_NOSUCHNICK. Then try to add them to the MONITOR list. Once they reappear on a common channel for the first time (we may later come to share multiple channels), look for PM buffers where the flag is on and write an "is back online" message. The same holds for RPL_MONONLINE. Strongly consider not printing the message when the user isn't on our MONITOR list (which, by the way, may contain entries not yet accepted by the server), as the timing might be wrong--or use, e.g., "has appeared on #channel". Think further of possible race conditions.

On RPL_MONOFFLINE, write an "is offline" message. Both of the new messages will be BUFFER_LINE_UNIMPORTANT, which is slightly questionable because you might be waiting for the event.

Consider what to do about the shitty Dark Science InspIRCd-3 that ignores degesch's autojoin (and maybe even USERHOST) but apparently not ZyklonB's, strangely enough. This would affect reliability. RPL_WELCOME should just work. Check the highly unlikely eventuality that hooks eat it along the way. Also note that the "command_delay" option, which can be used to circumvent this issue, has a misleading name.

See https://ircv3.net/specs/core/monitor-3.2, notably implemented by Freenode. Use this to track users we have an open PM buffer for but don't share a channel with. Use a `str_map` indexed by their nickname, limit the amount of entries by the MONITOR value--first come, first served. Right after connecting, this becomes all PM buffers. Unsubscribe once we start sharing a channel, subscribe once we stop or a new PM buffer is opened and we don't share a channel at the moment. See comment in `irc_handle_quit()` for more considerations: when a PM buffer is open, set an "offline" flag in the user when he QUITs and upon ERR_NOSUCHNICK. Then try to add them to the MONITOR list. Once they reappear on a common channel for the first time (we may later come to share multiple channels), look for PM buffers where the flag is on and write an "is back online" message. The same holds for RPL_MONONLINE. Strongly consider not printing the message when the user isn't on our MONITOR list (which, by the way, may contain entries not yet accepted by the server), as the timing might be wrong--or use, e.g., "has appeared on #channel". Think further of possible race conditions. On RPL_MONOFFLINE, write an "is offline" message. Both of the new messages will be `BUFFER_LINE_UNIMPORTANT`, which is slightly questionable because you might be waiting for the event. Consider what to do about the shitty Dark Science InspIRCd-3 that ignores degesch's autojoin (and maybe even USERHOST) but apparently not ZyklonB's, strangely enough. This would affect reliability. RPL_WELCOME should just work. Check the highly unlikely eventuality that hooks eat it along the way. Also note that the "command_delay" option, which can be used to circumvent this issue, has a misleading name.
p self-assigned this 2 years ago
p removed their assignment 2 years ago
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.