New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A way to perform feature degradation on unsupported individual client tag #97
Comments
what backward compatibility? |
Assuming some client code written for drafts, they will be done on a specific version of client tags. 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!). |
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 |
Is there any docs/pointer on C2S tags and "capability negotiation" of those? Thanks! |
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? |
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. ? |
nope |
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
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACMZRGS7NTQGBGYMGRXB43VU4SBRANCNFSM54AM7IQQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
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. |
I agree, and I think it is a good thing for some tags.
It does not mean we have to give up entirely. We can keep C2C tags for unimportant stuff (like |
Two schoolsIt 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.). ExamplesFor example, the 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. ConclusionIt looks like to me that giving up on the core premise is not necessary for all tags, like @progval says. 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. |
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 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 |
Yes, |
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 saydraft/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.
The text was updated successfully, but these errors were encountered: