"Personal" tag deny/allow list

[progval]

I remember seeing some concerns about the bandwidth usage of some tags, especially +typing; as clients have no way to opt out without opting out of message-tags entirely.

What if client could tell servers what tags they (don't) want to get, so servers can filter them out for them?

[SadieCat]

Has there actually been proven performance issues caused by message tags or is it just grumblings from the greybeard crowd? I'm not strongly opposed to this idea but even with the added tag space IRC messages are still tiny and even a GPRS connection shouldn't have issues with it.

[progval]

I made some calculations after posting this:

18:40 <@jwheare> I’d question whether that’s a legitimate grievance in reality or a theoretical exaggerated concern 18:42 <@jwheare> I guess I’d like to see data to backup the issue if there is any.

18:52 < val> assuming account-tag + server-time + msgid (with UUIDs), that's about 120 bytes per message. Add 60 bytes for TCP/IP overhead (assuming one packet per IRC message), that's a total of 180 bytes per person typing, every 3 seconds. So ~200KB/hour times the average number of people typing 19:00 < val> hmm, I forgot to account for TLS overhead, that's an extra ~50 bytes per packet (assuming AES_128_CBC_SHA + TLS >= 1.1, source: https://tools.ietf.org/id/draft-mattsson-uta-tls-overhead-01.xml#n-traffic-overhead ); so a total of ~280KB/hour/person 19:00 < val> I guess it's not that bad

19:03 < Noisytoot> my connection to libera.chat is using TLS_AES_256_GCM_SHA384 19:03 < val> Noisytoot: then add 28 bytes per packet

19:06 < val> now in practice, servers would probably group these messages (especially if there are many of them), so there's less TCP overhead. Not sure about TLS overhead though

[nillkitty]

I don't think that volume warrants a concern but I do agree that the client should have a way of opting out of specific tags.

For example, if we wanted to inline an image into a chat without it displaying as base64 gobbledegook to a legacy client; we'd probably encode that data in a tag and send a TAGMSG, but if a client is capable of tags but not capable of (or more likely, aware of but not yet currently supporting) inline images, it will get that data needlessly. A style of tag that must be opted into in order to receive would be beneficial, but also a way to silence tags you don't need.

Or the client could just ignore it shrug.

[jesopo]

good luck fitting an image in to 4095 bytes i guess

[nillkitty]

Ok, even if we assume IRC's max message size will never increase and that we'll be confined to text indefinitely, think about:

Current song playing updates (e.g. Google Talk) Current game playing updates (e.g. Discord) Real time telemetry (pulse rate, game scores, speedrun splits) Anything else you'd encode in a tag that not everyone might need

The benefit of tags is that it's an extensible medium, and that a client need not know about every tag in order for other clients to include tagged data so it can be made useful in the event some client supports it. If every client has to see every tag used, even if they know they will ignore it, this diminishes the overall scalability of tags to ones with light or infrequent payloads.

[jesopo]

tag space itself is limited to 8192 bytes including @ and space. if we'd like something else in-band that can carry amounts of data that might concern slow connections, I'm sure we can handle it when it happens?

i feel like further complicating message tags as a spec by negotiating c2c tag filters with the server is not worth it if the max possible throughput isn't going to dent uplinks in the mid kb/s. who are we trying to cater to?

[nillkitty]

I don't see how this capability would need to be a change to the message-tags spec. Nothing in the message-tags spec requires the server to send every single tag a client asks it to relay. This could even be a simple extension to SILENCE.

[jesopo]

SILENCE isn't standardised and imo shouldn't be. clients could opt to not engage with the c2c tag filtering system but servers dont get much of a choice. you've presented no real world issue this idea would resolve

[nillkitty]

I didn't know the reduction of bandwidth, processing power, and thus energy in general was outside the scope of the technical goals of the protocol. I'm somewhat antiquated in that I think it's wasteful to expend resources sending messages to clients that not only do nothing with them, but have the capability of informing the server that they will do nothing with them.

The OP's "typing" scenario I think is an excellent example; If hypothetically that tag were to be in full use each time someone began, stopped, or continued typing, as envisioned, that would be many many more times as many messages as a standard IRC conversation would require without that feature. Even if the client just ignores those tags and the associated TAGMSG messages, that's still an exponentially large amount of excess transfer that the client incurs simply because it's opted into the message-tags capability.

The realistic expectation is that clients will support message tags before they support specific tags such as typing, so it's fully realistic for a client to know that it doesn't support that tag (or the user has disabled the display of typing progress).

This feature would decouple the impact of how tags get used from clients' (dis)incentive to enable the message-tags capability. Just because tags are currently not being used in high traffic scenarios, that doesn't mean we don't need to put a client-side valve on the potential floodgate. The last thing you'd want is for clients to opt out of supporting tags altogether simply due to how one or more specific tags are being used, such as typing.

[SadieCat]

I didn't know the reduction of bandwidth, processing power, and thus energy in general was outside the scope of the technical goals of the protocol.

Excessively optimising things that aren't a performance concern to please the desires of a tiny minority of micro-optimisation fetishists is not a goal of this working group.