-
Notifications
You must be signed in to change notification settings - Fork 80
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
Ratify bot-mode #495
Ratify bot-mode #495
Conversation
Sopel implements both the mode (sopel-irc/sopel#2088) and tag (sopel-irc/sopel#2089). Yes, it accepts the unprefixed tag. Figured this spec would be ratified long before we made it to release, and it seems I'm about to be proven correct. |
I can push my support for this the moment its ratified. 👍🏻 |
Is there any objections to ratifying this? I'd like it if I could get our implementation into InspIRCd v3.13.0 which is due to be released next Friday. |
There was an objection raised in IRC from solanum/libera staff. As I understand it, they felt that IRCv3 shouldn't be pursuing specs that feel like a stop gap for a true metadata implementation. This spec doesn't define a mechanism for keeping up to date with a change in a user's bot status other than periodic WHOIS or WHO polling. True metadata notifications on status changes would allow clients to keep member lists in sync. In reality, a real bot is unlikely to ever change status, so I feel like running an initial WHO check on channel join and checking for the tag on new user JOINs should be sufficient for the vast majority of use cases. There are outstanding issues with PMs when no shared channel exists, but those issues extend to many other things, and a future METADATA spec won't necessarily cater to that situation either. I acknowledge and agree that effort should be spent on reviving a true metadata spec, so that we can focus in that direction for future cosmetic user status things, . But I think for this specific spec, where there is prior art for non-standard mode/whois numerics indicating bot status, and we have a broad consensus of implementation, we should ratify this. It might be worth mentioning the prior art in the spec, similar to the Motivation section in the SETNAME spec: https://ircv3.net/specs/extensions/setname.html#motivation See initial discussion here: ircv3/ircv3-ideas#43 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How's this?
Co-authored-by: James Wheare <james@wheare.org>
Thanks for feedback and implementations all. |
Bot Mode spec has been ratified (ircv3/ircv3-specifications#495). Since we haven't published a release with support for this message tag yet, it's a very easy decision to take *right now* that we'll only support the finalized spec and not the WIP version.
https://ircv3.net/specs/extensions/bot-mode was ratified a few months ago (ircv3/ircv3-specifications#495) This commit keeps the draft mtag, for now.
https://ircv3.net/specs/extensions/bot-mode was ratified a few months ago (ircv3/ircv3-specifications#495) This commit keeps the draft mtag in addition to the stable one, for now.
https://ircv3.net/specs/extensions/bot-mode was ratified a few months ago (ircv3/ircv3-specifications#495) This commit keeps the draft mtag in addition to the stable one, for now.
Known implementations
Unchecked means incomplete or an intent to implement has been expressed. The numbers indicate minimum requirements. Any others?
Server (3/2)
Client (2/1)
Bouncer
Bots
Networks