Add the delivered client-tag specification

[ghost]

Rendered view available here.

Split out from #319

[DarthGandalf]

This makes existing clients non-conformant, because they don't send the delivered tag which they MUST send. Replace with SHOULD?

[jesopo]

#python on freenode almost always has 1700+ people in it; does that mean I'm to expect 1700+ delivered TAGMSGs to every message I send? Same goes for #347

[dgw]

s/Theis/This/

s/when and by whom a message has been delivered to/when and to whom a message has been delivered/

[dgw]

"delivery receipt" is synonymous

[dgw]

What are the arguments against allowing read to be sent without first sending delivered? The client must necessarily have received a message in order to have read it, after all. Sending read implies delivered.

[dgw]

@jesopo In all likelihood, this tag would never be activated on huge public channels. The draft itself says it's intended for situations where all users know each other, not large channels of unknown users.

So yes, you would expect a huge flood of delivered messages, if enabled on a large channel like #python, but the spec isn't intended for use in those cases.

[jesopo]

@jesopo In all likelihood, this tag would never be activated on huge public channels. The draft itself says it's intended for situations where all users know each other, not large channels of unknown users.

So yes, you would expect a huge flood of delivered messages, if enabled on a large channel like #python, but the spec isn't intended for use in those cases.

So how are we going to communicate to clients that they should/shouldn't send delivered on a per-channel basis?

[jwheare]

One option would be to require clients to have a configurable limit on the size of a channel in which these notifications are sent. This would allow for different community norms to dictate what’s a “sensible” limit while forcing clients to not just always send these blindly but actually consider how the impact scales up.

Another option is to let servers process and filter these tags out, either automatically on a global config basis and/or with a channel mode. This strays a bit away from the benefit of c2c tags, but that might not be an issue.

These options aren’t necessarily mutually exclusive.

Even with no server filtering, chan/server ops can use standard moderation tools to deal with abusive, rude, or broken clients.

[jesopo]

If we leave it up to the server to just ignore them in certain circumstances, servers are still going to be hit with a LOT of data in big channels that it will just dispose of. If we don't let the server decide when a channel is too big, we'll have channels where only half the channel replies when the other half doesn't.

I'd much more prefer a way for the server to tell clients when they join and when the threshold is hit whether or not the channel should have delivered TAGMSGs send to it - this would limit the amount of bunk data sent to the server and synchronise all the clients in the channel.

[jesopo]

can I send delivered and read (#347) in the same TAGMSG? only thing that really makes sense for a bot.

[jwheare]

Sure, but I’m still not sure it’s a great idea to send on channels.

[jesopo]

I agree.

Added a nice small implementation of this in bitbot-irc/bitbot@6a67c37d that does both +draft/delivered & +draft/read in one TAGMSG on private PRIVMSG and NOTICE

[jesopo]

I still think that we can only support this in-channel if the server tells clients when they should stop sending delivered and read - not sure this is worth the fuss when this only seems useful (to me) when it's a one-to-one conversation.

[edk0]

I believe the amounts of data involved would be manageable for even relatively large channels if the proposal were modified to enable server-side aggregation of delivery messages

[jesopo]

server aggregation gets a 👍 from me but I think that will need a slightly larger conversation than is in-scope for this PR - as I understand it servers mostly ignore the content of +client tags and pass them through.

[Herringway]

Having to reply to every individual message makes this difficult to recommend for channel usage, being able to specify ranges instead would make this easier. read messages in channels would be much more reasonable with that ability, though delivered messages would still likely generate a lot of traffic... perhaps sending only read messages to channels should be allowed? I can see that possibly being useful for an extension to CHATHISTORY in the future.

[emersion]

Note: a server could auto-send a delivered tag after a PONG if a client doesn't support sending those. Would need a CAP to allow this.

-> @msgid=42 PRIVMSG #ch :hi
-> PING 42
<- PONG 42
# Broadcast to other clients:
-> @+draft/delivered=42 :nick!ident@host TAGMSG #ch

[slingamn]

It's not clear to me from the spec how this is supposed to work with channels. For a channel message, does the delivery-receipt TAGMSG target the channel, or the sender of the original message only? If the first, that's an O(n^2) blowup in messages (1 initial PRIVMSG, n delivery receipts from the channel participants, each of which has to be relayed to n recipients). Server-side aggregation could mitigate this, but I don't like the idea of forcing servers to implement business logic for a specific client-only tag on pain of severe performance problems.

It also seems to me that an important part of the rationale for this is made moot by CHATHISTORY:

The ability to send delivery receipts can also prove useful when connections are unstable and some messages may be dropped prior to reaching their intended target.

[NoSuck]

Imagine that the comment you now read never actually reached GitHub servers and was therefore never posted. Now imagine that my web browser alone displayed the comment as if it had been posted. That is the current state of affairs with IRC. If v3 is to fix anything, I hope it will be this gaping, fundamental hole—not only for small channels but for all.

[emersion]

The "delivered" tag won't fix this. Instead, the existing echo-message and labeled-response extensions can.

[jwheare]

There was strong concensus in the 24 Feb 2021 meeting that this should definitely be restricted to PMs only, and removed from the roadmap pending further implementation interest.