Add empty tag-only message support and an increased size limit for tags #287

jwheare · 2016-12-20T18:13:13Z

Specs a TAGMSG tag-only event. Enables things like content-less reactions/faving, message deletion, message seen notifications (Allow clients to communicate read/seen status to each other ircv3-ideas#1)
Increases the size limit for tags to 4096
Cap name version bump to draft/message-tags-0.2

dequis · 2016-12-20T19:16:14Z

core/message-tags-3.3.md

+### Size limit
+
+The size limit for message tags is increased to 512 to 4096 bytes, including the leading
+`@` and trailing space characters, leaving 3094 bytes for tags themselves. The size limit


s/3094/4094/

…ey're using the tags

DarthGandalf · 2016-12-20T23:44:00Z

core/message-tags-3.3.md

@@ -96,6 +96,9 @@ no message body is provided. These events MUST NOT be delivered to clients who h
 negotiated the message tags capability. If neither client-only tags nor a message body
 are provided, servers MAY respond with a standard `ERR_NOTEXTTOSEND` error.

+Clients that receive empty events MUST not display empty messages as-is in the message history


DarthGandalf · 2016-12-20T23:44:00Z

core/message-tags-3.3.md

+An alternate form of an empty message sent by a client with the `+example-client-tag` client-only tag, where the last parameter is omitted
+
+```
+@+example-client-tag=example-value PRIVMSG #channel


This allows omitting the last parameter of PRIVMSG.
What other commands can omit it now?

Note that this change is pretty far away from tags themselves.

I don't think clients should be allowed to send empty messages at all, even if the actual message is not in last parameter anymore, but in the tag. That way old clients have some way to show the conversation. Clients which use such tag should duplicate the message in the text... which makes the new tag useless.

As mentioned above in the diff, the only other command is NOTICE.

even if the actual message is not in last parameter anymore, but in the tag

This isn't about moving the actual message to a tag. If it's a message that has to be displayed as such, it still belongs in the last parameter. This is about opening another channel of communication that is only visible to clients that support this spec and won't share the same behavior of public messages. See for example #289, about reactions. Another example is typing notifications.

@DarthGandalf other than the mentioned use cases for content-less messages, is your objection that this is allowing PRIVMSG #channel rather than PRIVMSG #channel :?

I could change it to require the last param but allow it to be empty. But since it's allowing that param to effectively be ignored, I'm not sure it's needed.

I see the reason for allowing this change is so that servers can keep the standard PRIVMSG/NOTICE routing for message delivery to channels/users, and use them for pure tag delivery. Another alternative is to define a new message type that just carries tags, but since empty messages aren't allowed/useful normally, it makes sense to use them.

Another alternative is to define a new message type that just carries tags,

I'll start the bikeshedding for the name: METAMSG

jwheare · 2017-01-01T17:08:41Z

Any more input on this?

SadieCat · 2017-01-02T04:10:52Z

core/message-tags-3.3.md

+
+---
+
+An alternate form of an empty message sent by a client with the `+example-client-tag` client-only tag, where the last parameter is omitted


IMO this should be the only form allowed. Theres no point adding alternative methods just for the sake of adding alternatives.

+1 for only allowing one form

attilamolnar · 2017-01-02T11:18:52Z

The version of the draft cap should be bumped so early implementations can discover if a server is capable of empty PRIVMSG support

DarthGandalf · 2017-01-07T21:17:13Z

core/message-tags-3.3.md

+
+### Size limit
+
+The size limit for message tags is increased from 512 to 4096 bytes, including the leading


I'm afraid that this creates an incentive for third parties to create custom extensions which move text of message to @example.com/text, to workaround the limit of 512

That would be in direct contravention of the recommendation in the spec.

There is no guarantee that other clients will support or display the client-only tags they receive, so these tags should only be used to enhance messages with non-critical information. Messages should still make sense to clients with no support for tags.

If clients do that with their own prefixed tags, then they should expect it not to be widely adopted. I don't see it as a very effective incentive.

DarthGandalf · 2017-01-07T21:17:13Z

core/message-tags-3.3.md

+error.
+
+Clients that receive events without a message text MUST NOT display empty messages as-is
+in the message history unless they are using the attached tags according to their own


I can't parse this, sorry. Who are "their own"? tags? clients? messages?

The tags. I can try rewriting it.

But... how else can they use those tags? According to specs of some other unrelated tags?

Does this make more sense? 8667e48

Yes, it does.

DarthGandalf · 2017-01-07T21:17:13Z

core/message-tags-3.3.md

@@ -80,6 +89,24 @@ Individual tag keys MUST only be used a maximum of once per message. Clients
 receiving messages with more than one occurrence of a tag key SHOULD discard all
 but the final occurrence.

+### Empty tagged messages
+
+Servers MUST accept `PRIVMSG` and `NOTICE` events sent with client-only tags even if


The difference between PRIVMSG and NOTICE is whether bots should reply to the message.
Should reactions be as PRIVMSG or NOTICE?

I prefer @SaberUK 's new METAMSG verb and not to change syntax of widely used PRIVMSG/NOTICE

Since there's a CAP to enable this behaviour, I think it's OK. Bots that enable it can make sure they don't reply (and there'll be no text to reply to anyway).

A key benefit of using PRIVMSG/NOTICE is that servers already route them appropriately. Adding another verb feels heavyweight to me, but happy to discuss further.

servers already route them appropriately

That's the exact problem. I think the majority of server implementations assume that there is a text for PRIVMSG. For example, https://github.com/znc/znc/blob/master/include/znc/Message.h#L297 has such assumption.
By adding a new verb, old code which handles PRIVMSG can continue assuming that there is always a text.

To be clear, I'm not suggesting servers won't have to update their code to allow this. Whether it's by making PRIVMSG/NOTICE accept empty messages or by adding a new verb to be routed in exactly the same way as those two messages is the question. I feel like the former would be simpler, but maybe not in your case.

I'm indifferent about this. Strictly speaking on the protocol level there is no reason to introduce a new verb. Servers have to apply nearly the same restriction checks for tag-only messages as for normal messages e.g. callerid, reg only speak, flood checks, mute on channels, etc. so code that interacts with tag-only messages will need to be reviewed to ensure it handles them correctly regardless of the actual protocol used.

Another thing to consider is echo-message being already defined for PRIVMSG but adding a new verb requires either changing the definition of echo-message to support it or define it with "built-in" echo. The latter will create a new corner case with self METAMSG in labeled responses that will need addressing. None of these are huge changes, though.

SRV→ZNC: @tags :n!u@h PRIVMSG #chan ZNC→CLI: @tags :n!u@h PRIVMSG #chan :

The requirement to not render the message for the client won't apply anymore.

OK. This was my original motivation for allowing both forms. So either I can restore that or we can make the empty but present last param the only allowed form (which will probably attract comments that it seems unnecessary)

+1 for "the empty but present last param the only allowed form"

How's this? 304a03c

+1 for "the empty but present last param the only allowed form"

How's this? 304a03c

I'm fine with this.

attilamolnar

LGTM

progval · 2017-01-10T18:55:17Z

Enables things like content-less reactions/faving, message deletion, message seen notifications

Why do you want to use tags instead of a verb for these?
They clearly are actions, as much as AWAY, MODE, TOPIC, etc.

attilamolnar · 2017-01-10T18:57:18Z

Why do you want to use tags instead of a verb for these?
They clearly are actions, as much as AWAY, MODE, TOPIC, etc.

So features like what you quoted won't depend on server updates once client to client tags are supported.

progval · 2017-01-10T19:11:16Z

Message deletion and seen notifications will have to be supported by the server, for #292, and maybe faving too.
It may make sense for reactions to always be attached to a PRIVMSG, since they are a message; but it would have to be discussed in a separate spec.

I'm worried about the two possibilities discussed here, because not having a command would break one the most basic conventions of IRC, and using a content-less PRIVMSG would strip PRIVMSG of its meaning (why PRIVMSG and not NOTICE or MODE?).

From a less philosophical point of view, I am worried that using an empty PRIVMSG would either break third-party plugins of my bot which do not handle that case (if the bot negotiates the capability) or prevent other plugins from using the empty PRIVMSG from usin the feature (if the bot does not negotiate it).
And not using a command would break any third-party plugin that assumes the parser outputs a command.

What would you think of adding new verb(s?) for the sole purpose of carrying tags, on a channel, user-to-user, or from a network admin to all the users?

jwheare · 2017-01-10T19:17:52Z

Can you explain why deletion/seen/faving would require server support? The chathistory can just store the empty messages and clients can replay them as normal.
What does this mean?

not having a command would break one the most basic conventions of IRC

If you're concerned, your bot plugin framework could require plugins to enable support for the CAP via some internal config, and then you can forward/filter them to individual plugins as necessary.
Reasons for not adding a new verb have been discussed a few times already in this thread (search in page for "METAMSG")

progval · 2017-01-10T19:36:39Z

1. Can you explain why deletion/seen/faving would require server support? The chathistory can just store the empty messages and clients can replay them as normal.

For deletion, I think users would assume the message is deleted from the server, and that clients connecting afterward will not display the message, even if it does not support message deletion. Nevermind for seen and faving.

2. What does this mean? > not having a command would break one the most basic conventions of IRC

Just that calling IRC a protocol where messages may have no command feels weird.

3. If you're concerned, your bot plugin framework could require plugins to enable support for the CAP via some internal config, and then you can forward/filter them to individual plugins as necessary.

I have thought about that when considering `echo-message`, but I'm afraid it will lead to growing boilerplate config being copied to new plugins to support IRC features as they come.

4. Reasons for not adding a new verb have been discussed a few times already in this thread (search in page for "METAMSG")

I missed that, sorry.

A key benefit of using PRIVMSG/NOTICE is that servers already route them appropriately. Adding another verb feels heavyweight to me, but happy to discuss further.

Don't servers already factor code for PRIVMSG and NOTICE? If yes, adding a third verb routed exactly like them shouldn't be a problem

attilamolnar · 2017-01-10T19:52:59Z

@progval I don't understand the issue. The bot can have two events, one for regular PRIVMSG the other one for tag only PRIVMSG. Pass regular PRIVMSGs to the first, tag only PRIVMSGs to the second. Exactly as you would do with a third verb. Did I miss something?

progval · 2017-01-10T19:58:07Z

Yes, I could do that. I am not sure how I would name them, because all callbacks have the name of the command, so I can't have two callbacks for the same command with this naming scheme. That's why I would prefer a new verb.

jwheare · 2017-01-19T13:31:50Z

Added some examples and links. If there are no further comments, I'll merge this on Monday.

jwheare · 2017-01-24T11:45:31Z

@attilamolnar happy to approve these changes?

attilamolnar · 2017-01-25T22:19:09Z

@jwheare Please add 2 more examples with TAGMSG interacting with labeled-response and echo-message ~~in the normal msg case and~~ in the self message case for complete clarity

Edit: there is already an example for echo-message, never mind that part of my comment.

attilamolnar · 2017-01-25T22:27:04Z

core/message-tags-3.3.md

+These events MUST NOT be delivered to clients that haven't negotiated the message tags
+capability and MAY be rejected if no tags are included.
+
+If this event is sent without any tags, servers SHOULD reject it with a standard


Not that important, but any reason this is not a MUST? i.e. if servers choose to disallow tagless TAGMSG then they must use the given numeric for that. As currently stands servers are allowed to do whatever they want with a tagless TAGMSG making this a useless requirement.

It's a SHOULD in case servers don't want to bother to check the tags on TAGMSG for simplicity, since clients receiving them would be a no-op anyway.

How about this:

If this event is sent without any tags, servers SHOULD reject it. If they do, the standard ERR_NEEDMOREPARAMS error numeric MUST be used.

Actually no, I hadn't re-read the previous paragraph, I'll find a better wording.

attilamolnar · 2017-01-25T22:33:28Z

core/message-tags-3.3.md

+capability and MAY be rejected if no tags are included.
+
+If this event is sent without any tags, servers SHOULD reject it with a standard
+`ERR_NEEDMOREPARAMS` error numeric.


Please expand the examples to demonstrate the correct server behavior or behaviors in this corner case.

attilamolnar · 2017-01-25T22:38:32Z

core/message-tags-3.3.md

+These events MUST NOT be delivered to clients that haven't negotiated the message tags
+capability and MAY be rejected if no tags are included.
+
+If this event is sent without any tags, servers SHOULD reject it with a standard


Yeah this is what I had in mind.

jwheare · 2017-01-25T22:52:08Z

Is a repetition of the label/echo/self messages examples really needed here? The labeled-response spec is not specific to PRIVMSG/NOTICE, but should apply to all messages. I don't think we need to document it on every new event we define.

jwheare · 2017-01-25T22:59:39Z

I added a @label tag to the echo-message example, but I don't think the obscure and hard to describe self-message corner case needs repeating here.

jwheare · 2017-01-28T04:43:25Z

TODO

Add error numeric for tag length limit exceeded.
Swap "event" for "command"

…RFCs

…t> parameter

… ERR_INPUTTOOLONG 417 is from ircu and derivatives. This avoids ambiguity around truncating in the middle of the tag space

jwheare · 2017-01-28T10:57:54Z

The word "command" and "message" are used somewhat interchangeably in the RFCs ("event" is not). The distinction seems to be that a "command" refers to the numeric/verb itself or the act of issuing or processing it, while a "message" refers to the complete message with prefix and parameters and the act of delivering it. Somewhat subtle but I tried to use them appropriately.
I changed the link to 2812 for PRIVMSG examples because it has a better definition of what a <msgtarget> is.
Added an explicit error numeric for tags that exceed the limit. ERR_INPUTTOOLONG 417 is used in ircu and derivatives for lines that exceed the traditional untagged 512 limit. I think it's much more robust to explicitly error on this case instead of having rules or undefined server behaviour around truncation, leading to arbitrary data loss.

dequis · 2017-01-28T18:06:24Z

Added an explicit error numeric for tags that exceed the limit. ERR_INPUTTOOLONG 417 is used in ircu and derivatives for lines that exceed the traditional untagged 512 limit. I think it's much more robust to explicitly error on this case instead of having rules or undefined server behaviour around truncation, leading to arbitrary data loss.

For a sec I thought this was #281, where requiring that numeric may or may not happen. But it seems uncontroversial in the context of the new message-tags, with all its new required behaviors, and particularly about exceeding the tag length limit. So yeah, sure.

I think @DanielOaks was interested in reviewing the usage of that numeric first.

jwheare · 2017-01-31T12:09:09Z

I've discovered a slightly edge casey issue while implementing the ERR_INPUTTOOLONG error. A client might send a message that comes in under the limit, but the server then adds tags that push it over the limit.

The server could respond with the numeric anyway, but there are a few problems:

The server needs to precalculate the length of any tags it might add. If limit checking happens at the raw input parsing stage, this adds complexity further down the process.
The server can't wait until it has generated the full response to detect this and convert to an error, because side effects like forwarding the message to other clients will have already happened.
But, there may theoretically be tags introduced in future that mean it's not always possible to know the length of all the tags until those messages have been delivered, or at least checked, creating more complexity. e.g. (off the top of my head) if we introduce a tag that indicates how many targets received the message, or if different recipients get different tag sets.

Because of this, we have a situation where tags might again need to be truncated unexpectedly.

One solution is to allow for truncation in the spec, perhaps adding a @truncated=<length> tag at output processing time to let clients know what happened. This would of course result in even more truncation. It also weakens the point of having an error numeric in the first place.

Another idea is that we separate the limits. So, for example the total limit could be 4608, with 512 reserved for server tags and 4096 for client tags. It allows input parsing to remain simpler, safe and at the edges for both client and server with no unexpected data loss due to truncation.

Any issues with that? Also, any thoughts on the numbers? Perhaps we still need more than 512 for server tags, but client tags are the main motivation for increasing the limit.

jwheare · 2017-02-11T21:21:25Z

Added the split limit details in dba7cd5

Add empty tag-only message support and an increased size limit for tags

35b2f58

jwheare added this to the Roadmap milestone Dec 20, 2016

dequis reviewed Dec 20, 2016

View changes

jwheare added 3 commits December 20, 2016 19:17

Fix typo

ac7a048

Add requirement for clients to ignore empty tagged messages unless th…

c7cb43b

…ey're using the tags

Add empty tagged message examples

49ead80

DarthGandalf requested changes Dec 20, 2016

View changes

Fix shouting

e51b828

SadieCat reviewed Jan 2, 2017

View changes

jwheare added 3 commits January 2, 2017 13:31

Only specify the omitted message parameter form for tag-only messages

3a249a7

Size limit typo/clarification

19f545e

Bump version

ab41d48

jwheare mentioned this pull request Jan 4, 2017

[message-ids] draft msg-id tag spec for server supplied message IDs. #285

Merged

jwheare requested a review from attilamolnar January 6, 2017 19:09

jwheare added tags client-tags Last call labels Jan 7, 2017

DarthGandalf reviewed Jan 7, 2017

View changes

jwheare added 2 commits January 7, 2017 21:36

Clarify tags that might specify empty message displays

8667e48

Empty last parameter instead of omitted

304a03c

attilamolnar approved these changes Jan 10, 2017

View changes

jwheare added 2 commits January 19, 2017 11:59

[message-tags] Link to RFC1459 PRIVMSG

0520f1f

[message-tags] Add STATUSMSG and echo-message exmaples

a597221

attilamolnar reviewed Jan 25, 2017

View changes

Better wording around rejecting tagless TAGMSG

c62ef7b

jwheare added 2 commits January 25, 2017 22:56

Add label behaviour to echo/msgid example

4ad87c4

Add ERR_NEEDMOREPARAMS example

cb8218e

jwheare added 3 commits January 26, 2017 10:57

Use indents for examples to improve web rendering

3d5d79a

Potentially fix rendering of code block after list?

cfe3148

Add a line between the list and code block to fix rendering bug

c53446d

jwheare added 4 commits January 28, 2017 10:47

Rewording. Follow naming and command definition conventions from the …

8cc4119

…RFCs

Link to RC2812 for PRIVMSG example as it better defines the <msgtarge…

5b92bd3

…t> parameter

Add a required error numeric for messages that exceed the size limit.…

b6b3f6f

… ERR_INPUTTOOLONG 417 is from ircu and derivatives. This avoids ambiguity around truncating in the middle of the tag space

command vs message

3e68130

attilamolnar approved these changes Jan 30, 2017

View changes

jwheare added 2 commits February 11, 2017 20:42

Split the byte limit between server and client initiated tags

96a17bc

Better description of split tag limits

dba7cd5

jwheare merged commit c7ab1c4 into ircv3:master Feb 16, 2017

jwheare deleted the message-tags-empty+size branch February 16, 2017 10:00


		---

		An alternate form of an empty message sent by a client with the `+example-client-tag` client-only tag, where the last parameter is omitted


		### Size limit

		The size limit for message tags is increased from 512 to 4096 bytes, including the leading

Add empty tag-only message support and an increased size limit for tags #287

Add empty tag-only message support and an increased size limit for tags #287

Conversation

jwheare commented Dec 20, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jwheare commented Jan 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

attilamolnar commented Jan 2, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

attilamolnar left a comment

Choose a reason for hiding this comment

progval commented Jan 10, 2017

attilamolnar commented Jan 10, 2017

progval commented Jan 10, 2017

jwheare commented Jan 10, 2017

progval commented Jan 10, 2017 via email • edited

attilamolnar commented Jan 10, 2017 • edited

progval commented Jan 10, 2017

jwheare commented Jan 19, 2017

jwheare commented Jan 24, 2017

attilamolnar commented Jan 25, 2017 • edited

attilamolnar Jan 25, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jwheare commented Jan 25, 2017

jwheare commented Jan 25, 2017 • edited

jwheare commented Jan 28, 2017 • edited

jwheare commented Jan 28, 2017 • edited

dequis commented Jan 28, 2017

jwheare commented Jan 31, 2017

jwheare commented Feb 11, 2017

jwheare commented Dec 20, 2016 •

edited

progval commented Jan 10, 2017 via email •

edited

attilamolnar commented Jan 10, 2017 •

edited

attilamolnar commented Jan 25, 2017 •

edited

attilamolnar Jan 25, 2017 •

edited

jwheare commented Jan 25, 2017 •

edited

jwheare commented Jan 28, 2017 •

edited

jwheare commented Jan 28, 2017 •

edited