updates to metadata spec #566
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
Conversation
|
Re:
I don't understand what this means and how it relates to the change. Can you provide more detail? |
If I understand the question correctly: the point of having a separate server cap value here is to inform clients that the server may be storing persistent metadata that they shouldn't preemptively overwrite. Making this a client setting would probably require the end user to be aware of this, which seems undesirable. (I'm also open to making this a value of re. the CAP REQ behavior, the original language is:
As per discussion on #543 I prefer that requesting a CAP should not have side effects. This is amended to:
The concrete changes in behavior being:
|
|
What would happen if a client did try to overwrite the metadata? They may want to e.g. set a key that indicates where they're logging in from. I don't follow how the CAP REQ change prevents side effects, it still says "clients receive their current metadata" |
They don't receive it in response to the
I think for implementations with persistent presence and metadata support, and which are designed to accept short-lived connections, rejecting pre-connect updates is probably a good tradeoff since they are likely to be spammy as well as out-of-date. But the tradeoff is real, and not just for keys like the one you're describing, because non-persistent clients will have to connect without being able to pre-set any metadata. |
|
Ah, in response to CAP END vs CAP REQ makes sense, that wasn't really clear from the wording.
I feel like that tradeoff is exactly why it should be a client setting, should be in the user's control. |
Open to changing the wording! I feel like the actual spec amendment is fairly clear though, and the problem is more that my PR description and comments about it were confusing :-)
This is a more expansive conversation but I think historically IRC has erred in making client configuration too burdensome. The most successful IRC clients now are extremely low-configuration (think Kiwi, Gamja, and Goguma). Having the user figure out the state of server-side persistence and check or uncheck a box in response seems like a pretty bad outcome (although in terms of making this automatically discoverable, #503 is relevant). A rough implementation compromise that occurs to me:
|
This reverts commit e5dbbd1.
|
Withdrawing the proposal of |
|
Currently, key names are "restricted to the ranges A-Z, a-z, 0-9, and _./- and are case-insensitive." Case-insensitivity creates a number of potential correctness issues (for both clients and servers), seemingly to no real benefit. Could we just require that key names are lowercase instead, i.e. remove A-Z from the allowed characters? |
This includes the proposed change of behavior where the existing metadata is sent as part of the reg burst, instead of in response to CAP REQ.
cde84d7 to
ffb8c40
Compare
* Disallow colon entirely as in ircv3#567 * Disallow A-Z * Remove requirement of case-insensitive handling
Co-authored-by: Val Lorentz <progval+github@progval.net>
Co-authored-by: Val Lorentz <progval+github@progval.net>
* RPL_METADATASUBS is batched with the metadata-subs batch type * Clarify when the metadata batch type is used
These came out of my review of the initial metadata implementation in Ergo, contributed by @thatcher-gaming. They're more starting points for discussion than polished amendments. A brief summary:
before-connectallows clients to modify both their metadata and their subscriptions during connection registration. For conventional IRC stacks without persistent clients, this makes perfect sense. For bouncers and implementations like Ergo with persistent clients, it makes sense to be able to modify subscriptions, but clients probably shouldn't be unilaterally pushing metadata updates on every reconnection, since they may overwrite more up-to-date metadata that was set from another client. This adds a new cap value key,sub-before-connect, that indicates that subscriptions are accepted during connection registration, butSETetc. are not.Something not addressed here is that
772 RPL_METADATASUBSis effectively unusable withoutlabeled-response, since there is no indication of where it ends. An initial proposal: a772line with no parameters after the client's nick could be taken as the end of the subscriptions? We could also add a newRPL_ENDOFMETADATASUBS.