PutIRC(CMessage) #645

New Issue

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

adam commented

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

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

## <bountysource-plugin> Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/28584144-putirc-cmessage?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam closed this issue

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

adam commented

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

The main problem here: need to consider how tags interact with disabled capabilities.

The main problem here: need to consider how tags interact with disabled capabilities.

adam commented

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

The good news is that the message tag spec says:

Client and server MAY parse the tags even without any capabilities enabled. They SHOULD ignore tags of capabilities which are not enabled.

The bad news is that that says "SHOULD", not "MUST", so in theory a system could do anything. As a result, I'm not quite sure what we should do.

The good news is that [the message tag spec says][message-tag]: >Client and server MAY parse the tags even without any capabilities enabled. They SHOULD ignore tags of capabilities which are not enabled. The bad news is that that says "SHOULD", not "MUST", so in theory a system could do anything. As a result, I'm not quite sure what we should do. [message-tag]: http://ircv3.net/specs/core/message-tags-3.2.html

adam commented

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

MAY doesn't mean "able to".
As I understand it, ZNC should send a tag if that tag is enabled or if draft/message-tags-0.2 is enabled. It's not ambiguous.
I was referring more to API inside ZNC - should PutIRC(msg) send the message as is, or strip unsupported tags. For consistency with CClient::PutClient(const CMessage& Message), as it's implemented now, probably it should strip unsupported tags.

MAY doesn't mean "able to". As I understand it, ZNC should send a tag if that tag is enabled or if [`draft/message-tags-0.2`](http://ircv3.net/specs/core/message-tags-3.3.html) is enabled. It's not ambiguous. I was referring more to API inside ZNC - should PutIRC(msg) send the message as is, or strip unsupported tags. For consistency with CClient::PutClient(const CMessage& Message), as it's implemented now, probably it should strip unsupported tags.

adam commented

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

As I understand it, ZNC should send a tag if that tag is enabled or if draft/message-tags-0.2 is enabled.

It looks like client-only tags, as specified by that spec, are tags beginning with +. As such, ZNC should send the tag if the corresponding tag is enabled or if draft/message-tags-0.2 is enabled and the tag begins with +. I can make a pull request adding that functionality.

For consistency with CClient::PutClient(const CMessage& Message), as it's implemented now, probably it should strip unsupported tags.

Makes sense to me.

>As I understand it, ZNC should send a tag if that tag is enabled or if [`draft/message-tags-0.2`][client-only-tags] is enabled. It looks like client-only tags, as specified by that spec, are tags beginning with `+`. As such, ZNC should send the tag if the corresponding tag is enabled or if `draft/message-tags-0.2` is enabled and the tag begins with `+`. I can make a pull request adding that functionality. >For consistency with CClient::PutClient(const CMessage& Message), as it's implemented now, probably it should strip unsupported tags. Makes sense to me. [client-only-tags]: http://ircv3.net/specs/core/message-tags-3.3.html

adam commented

2026-10-05 04:35:59 +02:00

Actually, rereading the spec, you were right. The difference is that client-only tags should not be touched by the server.

Actually, rereading the spec, you were right. The difference is that client-only tags should not be touched by the server.

adam commented

2026-10-05 04:35:59 +02:00

Hmm, a pull request adding support for draft/message-tags-0.2 would actually be more complicated than I thought, as it would need to also add support for TAGMSG and messages with up to 4607 bytes of tags. The former is easy, but the latter entails performing checks on the size of both server- and client-initiated tag sets, refraining from adding server-initiated tag sets that would exceed 510 bytes, and responding with 417 ERR_INPUTTOOLONG to messages from clients with tag data that exceeds 4094 bytes.

One could argue that, aside from increasing the message buffer size to fit the new tag data, ZNC doesn't need to perform any of these checks because the remote server should handle it all, but if the partyline module is enabled then there isn't necessarily any remote server.

The other question is whether or not we should consider draft/message-tags-0.2 a capability that requires remote server support, or whether we should allow clients to request it from ZNC regardless.

Hmm, a pull request adding support for `draft/message-tags-0.2` would actually be more complicated than I thought, as it would need to also add support for [`TAGMSG`][TAGMSG] and [messages with up to 4607 bytes of tags][size-limit]. The former is easy, but the latter entails performing checks on the size of both server- and client-initiated tag sets, refraining from adding server-initiated tag sets that would exceed 510 bytes, and responding with 417 `ERR_INPUTTOOLONG` to messages from clients with tag data that exceeds 4094 bytes. One could argue that, aside from increasing the message buffer size to fit the new tag data, ZNC doesn't need to perform any of these checks because the remote server should handle it all, but if the partyline module is enabled then there isn't necessarily any remote server. The other question is whether or not we should consider `draft/message-tags-0.2` a capability that requires remote server support, or whether we should allow clients to request it from ZNC regardless. [TAGMSG]: http://ircv3.net/specs/core/message-tags-3.3.html#the-tagmsg-tag-only-message [size-limit]: http://ircv3.net/specs/core/message-tags-3.3.html#size-limit

adam commented

2026-10-05 04:36:00 +02:00

TAGMSG, draft/message-tags-0.2 and client tags can be left for a future version. For 1.7.0, simple case will be enough.

For a module to send a message with arbitrary tags, which are not stripped, probably it should send the message, then attach the tags to it in OnSendToIRCMessage()

TAGMSG, draft/message-tags-0.2 and client tags can be left for a future version. For 1.7.0, simple case will be enough. For a module to send a message with arbitrary tags, which are not stripped, probably it should send the message, then attach the tags to it in OnSendToIRCMessage()

adam commented

2026-10-05 04:36:01 +02:00

Makes sense to me. I'll see about getting a pull request up soonish.

Makes sense to me. I'll see about getting a pull request up soonish.

adam commented

2026-10-05 04:36:01 +02:00

@elyscape any progress? :)

@elyscape any progress? :)

adam commented

2026-10-05 04:36:02 +02:00

Oop! This completely slipped my radar. I'll see if I can make this happen over the weekend.

Oop! This completely slipped my radar. I'll see if I can make this happen over the weekend.

adam commented

2026-10-05 04:36:02 +02:00

@DarthGandalf Ack, sorry I didn't get this this before you did.

@DarthGandalf Ack, sorry I didn't get this this before you did.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#645