ircdocs
Relax ISUPPORT key syntax to allow vendor prefixes
This would allow for e.g. draft/FOO and soju.im/BAR.
Motivation: right now ISUPPORT is first-come first-served, ie. as soon as a server starts introducing its own server-specific ISUPPORT token without asking anyone else the token cannot ever be re-used if it's not general enough.
For instance, if soju starts advertising FILEHOST as an HTTP POST endpoint and HTTP authentication based on IRC credentials, and the standardization process ends with a different consensus, then the final token will need to be FILEHOST2 or something, or else existing clients will break. As another example, maybe soju starts shipping ICON, and the standardization process ends up with a consensus that a size template is desirable, then existing clients will misbehave because they won't handle the templating.
Additionally, the unprefixed token doesn't make it clear where the token is coming from (is it a vendor extension, a draft, or a standard thing?).
In general, having ISUPPORT tokens as first-come first-served doesn't foster discussion among IRC developers. Everybody just does their own thing and ends up having to go along with whatever the first person designed, or come up with their own mostly similar but slightly different ISUPPORT token.
IRCv3 capabilities have prefixes exactly for this reason. Why should we have prefixes for caps but not for ISUPPORT, since without prefixes both can result in client breakage?
soju and Ergo already send vendor-prefixed ISUPPORT tokens, and no client breakage has been reported.
Just a friendly bump, I would also like this to be a thing (and actually also implement in an upcoming client ObsidianIRC because of the reasons outlined by @emersion in this post). Good to know there have been no reports of client breakages so far, and I suppose any good client would skip any ISUPPORT tokens it considers invalid instead of exploding, which if true means there should be virtually no impact to existing clients. I think it might be a good idea to trial as many clients as possible (maybe awesome-irc is a nice source?) against this though, as it would be a bit of a reckless assumption to make without at least researching first, and in the case anything did explode, an attempt to reach out to the developer can be made to resolve it. I'd be happy to help with trialing clients and reaching out if needed. Thanks.
For the reasons already discussed, I'm in favor of this change assuming no major client issues arise from testing. It's kind of a no-brainer to allow for experimentation in vendor-prefixed feature tokens.
Should be no issue with this from Sopel's perspective; it just splits each 005 parameter on = and then checks if any of the tokens it cares about were advertised. Plugins can check their own feature requirements (including prefixed keys, if they start to see usage) independently.
One of the two ways ISupport tokens can be accessed won't work with a slash (as a Python attribute, e.g. bot.isupport.TOKENNAME), but that shouldn't be a problem in practice (since bot.isupport['TOKENNAME'] is also available).
modern-irc only documents the existing state, it does not propose new extensions. This potentially breaks clients, so I expect guarantees that no major client will be affected by this (or at least not in a major way). This can take two forms:
- a major server/network or two, who are known to be compatible with all major clients, has had this implemented/deployed for a while. See https://github.com/ircdocs/modern-irc/pull/220 or https://github.com/ircdocs/modern-irc/pull/234 as examples. Or,
- an exhaustive review of all major clients. This means at least all gratis clients listed on https://ircv3.net/software/clients.html + https://ircv3.net/software/bridges (excluding matrix2051 and bitlbee as they are servers) + https://ircv3.net/software/libraries though I'd need to check there isn't any major client missing from that list.
soju and Ergo already send vendor-prefixed ISUPPORT tokens, and no client breakage has been reported.
ah, I missed this (I assume you're referring to draft/CHATHISTORY and the former draft/UTF8ONLY on Ergo). That's good enough for me.
an attempt to reach out to the developer can be made to resolve it
As of now only soju and Ergo seem to have an implementation that doesn't align with the spec so this could probably be solved easily.
To repeat what i said earlier on irc: this should really be discussed in #ircv3 or on the ircv3 github.
modern-irc only documents the existing state, it does not propose new extensions.
It's more fitting because: "The ircv3 working group is chartered to prototype, develop, test and specify further extensions to the IRC client protocol [..] through backwards-compatible specifications."
This makes sense I reckon, znc.in/self-message, ergo.chat/nope are other examples of ISUPPORT keys used today and understood by most clients, but currently not allowed by the syntax in the modern doc.
znc.in/self-message,ergo.chat/nopeare other examples of ISUPPORT keys
Searching the code for both programs, I can find only references to those as capability names, not ISUPPORT tokens. Am I missing something obvious?
… I conflated cap and isupport for some reason, please ignore me 😅
On Wed, 28 May 2025 at 6:39 am, dgw @.***> wrote:
dgw left a comment (ircdocs/modern-irc#250) https://github.com/ircdocs/modern-irc/issues/250#issuecomment-2913980459
znc.in/self-message, ergo.chat/nope are other examples of ISUPPORT keys
Searching the code for both programs, I can find only references to those as capability names, not ISUPPORT tokens. Am I missing something obvious?
— Reply to this email directly, view it on GitHub https://github.com/ircdocs/modern-irc/issues/250#issuecomment-2913980459, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB5LEIFR27UUMLUBW5JKVD3ATERZAVCNFSM6AAAAAB5ZE5E7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMJTHE4DANBVHE . You are receiving this because you commented.Message ID: @.***>