Make the messages from buffextras RFC conform #876

New Issue

2026-10-05T04:49:55+02:00

adam commented

2026-10-05 04:49:55 +02:00

Hi folks,
I'm using WeeChat as local client with the buffextras module. I wanted to display the messages from buffextras as regular messages inside WeeChat and wrote a simple script for it. I noticed the messages from buffextras after the PRIVMSG are slightly modified. I guess this is made so the messages are more human readable in a client.

Parsing those messages RFC conform isn't a problem, but I think it would be nice if those can be (maybe optionally with a setting?) fully RFC conform. The PART messages are a good example, buffextras makes something like parted and parted with message: [bla]. If those were unmodified it would be easier for other clients to make them appear like a regular message.

Right now I had to disable the parsing for MODE as buffextras returns mode:, I checked the RFC and the colon isn't used for MODE which produced wrong mode messages and lead to a crash of WeeChat. Sure, I could simply replace that colon before parsing, but I think this change would be a plus for ZNC.

What do you think about this?

Hi folks, I'm using WeeChat as local client with the buffextras module. I wanted to display the messages from buffextras as regular messages inside WeeChat and wrote a simple script for it. I noticed the messages from buffextras after the `PRIVMSG` are slightly modified. I guess this is made so the messages are more human readable in a client. Parsing those messages RFC conform isn't a problem, but I think it would be nice if those can be (maybe optionally with a setting?) fully RFC conform. The `PART` messages are a good example, buffextras makes something like `parted` and `parted with message: [bla]`. If those were unmodified it would be easier for other clients to make them appear like a regular message. Right now I had to disable the parsing for `MODE` as buffextras returns `mode:`, I checked the RFC and the colon isn't used for `MODE` which produced wrong mode messages and lead to a crash of WeeChat. Sure, I could simply replace that colon before parsing, but I think this change would be a plus for ZNC. What do you think about this?

adam commented

2026-10-05 04:49:56 +02:00

and lead to a crash of WeeChat

Sounds like you found a security issue in WeeChat and should report it as such.

> and lead to a crash of WeeChat Sounds like you found a security issue in WeeChat and should report it as such.

adam commented

2026-10-05 04:49:57 +02:00

and lead to a crash of WeeChat

Sounds like you found a security issue in WeeChat and should report it as such.

Nope, the author warned about crashes caused by malformed messages when manipulating raw messages.

> > and lead to a crash of WeeChat > > Sounds like you found a security issue in WeeChat and should report it as such. Nope, the author warned about crashes caused by malformed messages when manipulating raw messages.

adam commented

2026-10-05 04:49:58 +02:00

The proper way to do it is having the client to enable a capability "I understand that not all messages change the state", and buffextras to make use of such capability. For such clients it would send @example.com/display-only MODE +whatever; then client sees this tag and do the right thing.

See also: https://github.com/ircv3/ircv3-specifications/issues/293

This is similar to what you said, but the setting is per client, and the messages wouldn't be prefixed with PRIVMSG.

The proper way to do it is having the client to enable a capability "I understand that not all messages change the state", and buffextras to make use of such capability. For such clients it would send `@example.com/display-only MODE +whatever`; then client sees this tag and do the right thing. See also: https://github.com/ircv3/ircv3-specifications/issues/293 This is similar to what you said, but the setting is per client, and the messages wouldn't be prefixed with PRIVMSG.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#876