A way to perform feature degradation on unsupported individual client tag

[RaitoBezarius]

Hi there,

I wanted to understand how to envision a way to perform feature degradation for certain client tags if a client implements message-tags but not, let's say draft/replies, so that clients can receive comprehensive degradation messages.

From what I gathered from some people on #solanum@libera.chat and #ircv3@libera.chat, CAPS could constitute a solution, but it would break backward compatibility.

I wanted to open this to create discussion as I am interested into a solution.

[progval]

but it would break backward compatibility.

what backward compatibility? +typing is the only ratified client tag, and it would not need a fallback. Other client tags are drafts and can have breaking changes.

[RaitoBezarius]

but it would break backward compatibility.

what backward compatibility? +typing is the only ratified client tag, and it would not need a fallback. Other client tags are drafts and can have breaking changes.

Assuming some client code written for drafts, they will be done on a specific version of client tags. So client code will work if server is able to use this specific client tag, but if they use another, it would be great to still receive fallback for these and degrade gracefully, e.g. plaintext messages when it makes sense.

I assume this is going to be more or less standard because client/server are evolving at different speeds and end user upgrades at yet another different speed.

Therefore, graceful degradation appears to me to be very important, even if breaking changes are allowed (or I would say: even more the reason to!).

[progval]

So client code will work if server is able to use this specific client tag, but if they use another, it would be great to still receive fallback for these and degrade gracefully, e.g. plaintext messages when it makes sense.

Yeah at this point, I think C2C should not be used for anything that requires a fallback.

If something needs a fallback (eg. replies, maybe reacts too), then they should be a normal C2S tag, that is only enabled on servers that explicitly implemented it.

C2C tags are still fine for +typing and +draft/channel-context, though.

[RaitoBezarius]

So client code will work if server is able to use this specific client tag, but if they use another, it would be great to still receive fallback for these and degrade gracefully, e.g. plaintext messages when it makes sense.

Yeah at this point, I think C2C should not be used for anything that requires a fallback.

If something needs a fallback (eg. replies, maybe reacts too), then they should be a normal C2S tag, that is only enabled on servers that explicitly implemented it.

C2C tags are still fine for +typing and +draft/channel-context, though.

Is there any docs/pointer on C2S tags and "capability negotiation" of those? Thanks!

[progval]

there isn't any; that's a new idea I'm trying to push :)

[RaitoBezarius]

there isn't any; that's a new idea I'm trying to push :)

So moving forward to foster discussion.

Would it be a good idea to have these C2S tag support as proper client and server CAP? Or is it better to have a generic CAP about requesting about these C2S individual tags capabilities through something else?

[progval]

requesting about these C2S individual tags capabilities through something else?

that sounds redundant with capabilities themselves; so I prefer the former unless there is a good reason not to

[RaitoBezarius]

requesting about these C2S individual tags capabilities through something else?

that sounds redundant with capabilities themselves; so I prefer the former unless there is a good reason not to

Is there a technical limit (or concern for a limit) on the amount of CAP to announce, etc. ?

[progval]

nope

[RaitoBezarius]

So here's my thoughts at the moment.

Client only tags specification could be extended to specify they should be used when they do not require feature degradation for non compatible clients. "Requiring feature degradation" needs to be defined and it appears to me that client tags that creates new contexts and would make non compatible client miss subtle cues in discussions are ones which requires feature degradation and therefore must not be made client only tags.

Client-server tags can be defined ad-hoc in client tags specification or in a new specification, I have no real opinion on this.

Finally, what to do with current client only tags drafts requiring feature degradation?

Upgrading them to client-server tags and adding new cap for each of them, plus a section on feature degradation considerations in all contexts (mobile client, web client, terminal client) seems important to move forward with this.

What do you think of this rough plan? Of course, those are only suggestions and I am very new to participating in this though I have been lurking for years.

Le mar. 19 juil. 2022 à 23:13, Val Lorentz @.***> a écrit :

nope

— Reply to this email directly, view it on GitHub https://github.com/ircv3/ircv3-ideas/issues/97#issuecomment-1189603526, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACMZRGS7NTQGBGYMGRXB43VU4SBRANCNFSM54AM7IQQ . You are receiving this because you authored the thread.Message ID: @.***>

[slingamn]

This doesn't seem like an "extension" of the client-only tags specification, it seems like giving up on the core premise: clients are supposed to be able to use them to create flexible protocol extensions that don't require server support.

[progval]

it seems like giving up on the core premise

I agree, and I think it is a good thing for some tags.

clients are supposed to be able to use them to create flexible protocol extensions that don't require server support.

It does not mean we have to give up entirely. We can keep C2C tags for unimportant stuff (like +typing, +draft/channel-context or to experiment (and then "upgrade" them to C2S tags if we feel we need a fallback)

[RaitoBezarius]

This doesn't seem like an "extension" of the client-only tags specification, it seems like giving up on the core premise: clients are supposed to be able to use them to create flexible protocol extensions that don't require server support.

Two schools

It seems like there are two schools with respect to client only tags. [1]

The first are aligned with the core premise which is to use them in an opaque way for server (server still needs to pass them, etc.). The second believes there should be a way to control these client tags, validate their values, enforce rate-limits, degrade their meaning to older primitives in the protocol for unsupported clients, offer moderation tooling for channels — thus, there is no "flexible protocol extension" that can happen without server support, there will always be server support for this otherwise I guess bots/special nicks are the best tool for that.

Examples

For example, the typing specification have some provision on delays before relaying the next typing update, should the client be responsible for enforcing this rate-limit? Of course, I do not think that a spammer sending too much typing notifications is going to crash a server, neither a rather modern client, but the semantics of server protecting everyone seems important to me.

Same thing with context-creating client-tags, server can ignore them, but it might create a bad experience for unsupported client, therefore, in the spirit of backward compatibility, it looks like dangerous to have context-creating messages which are ignored by unsupported clients, it does not break backward compatibility per se — though, it does prevent an older client to participate meaningfully in the conversation.

Conclusion

It looks like to me that giving up on the core premise is not necessary for all tags, like @progval says. I would go even further and say this might be a policy choice by implementations: to arbitrarly allow all client only tags, etc.

At the same time, it may be a policy choice to restrict the values and watch for unintended behaviors in conversations so that the experience is great for everyone.

Therefore, I would advocate to add some sections on feature degradation considerations and "How to prevent that these new features creates a conversation context which cannot be read by unsupported clients?" (some of this is already present in the specifications, but it seems like there is too few which is said about it IMHO.)

[1] : Of course, I do not mean to speak for everyone, I am just compiling what I understood from the different conversations I had here and there.

[slingamn]

The second believes there should be a way to control these client tags, validate their values, enforce rate-limits, degrade their meaning to older primitives in the protocol for unsupported clients, offer moderation tooling for channels

Rate limit enforcement is really a different conversation. My server implementation (like most server implementations) has an ad-hoc design for generic rate limit enforcement, because the issue affects core protocol commands like PRIVMSG and there is no formal specification for it.

So, ignoring that issue, I am firmly in the first camp (C2C tags should be fully opaque). But the second camp is accommodated, to a degree, by the current specification: this is why CLIENTTAGDENY was included. Is there a way to lean on CLIENTTAGDENY to get some of what you want?

[progval]

Yes,CLIENTTAGDENY in whitelist mode allows servers to block anything that they don't know how to handle (and can't downgrade if needed). That's only half of it though, we still need a mechanism to tell servers what clients need a fallback for