ircv3-specifications

ircv3-specifications copied to clipboard

This is based on the solanum implementation. The solanum spec can be found here.

It would be nice to elaborate on the use-case of this spec. WHO flags (in particular the * flag) already provides a way to check whether someone is an operator.

What is the value-add of this spec?

@emersion It's a blessing as a bot author. Instead of maintaining WHO state, and sending one-off WHO requests, we can check for this tag synchronously when processing commands.

It's a blessing as a bot author. Instead of maintaining WHO state, and sending one-off WHO requests, we can check for this tag synchronously when processing commands.

Okay, so ease-of-use is the main motivation for this, just like account-tag and bot. Maybe it would be worth including the motivation in the spec description, to make it clear what problem the spec is trying to solve?

One value-add from this spec is when a client needs to figure out on JOIN whether a user is an operator or not. Right now the only way is to WHO all users who JOIN, which doesn't work in practice because of rate limits. If an oper tag is attached to JOIN messages clients would be able to properly keep their state up-to-date on JOIN.

I really liked the sound of this so I PR'd a sort-of implementation to UnrealIRCd (https://github.com/unrealircd/unrealircd/pull/226), I hope this gets more reach.

FWIW: I think this could include some additional oper information, like a potential operclass.

draft/oper=bobsmith,netadmin

or something similar. I'm not entirely sure how global operclasses are in the IRC world, but it's probably common enough to include catering for it :smiley:

Is there any more interest in this? I'd like to add support for this to InspIRCd.

FWIW: I think this could include some additional oper information, like a potential operclass.

I support this but I'd like to bikeshed oper-role as a more generic tag name for this as operclass may have a different meaning depending on your IRCd (e.g. in InspIRCd an oper class is a set of privileges and the equivalent of an Unreal oper class is an oper type).

I've implemented this with the addition of my oper-role proposal: https://github.com/inspircd/inspircd/compare/master...SadieCat:inspircd:master+ircv3-oper-tag

Are we still keen to standardise this? Looks like decent amount of support from server devs. Sensible solutions to any open bikesheds welcome.

how often are oper "classes" used in IRC servers? if it's a majority, I'd like to see an oper-class tag too

i think the concept of "oper classes" is so implementation-specific that it shouldn't be part of a protocol-wide standard

(i understand why it would be helpful, by the way, and maybe having another spec for it would make me feel better)

The only thing I don't like is the use of 'oper' as a capability name - it's too vague and doesn't describe what's actually being enabled by it.

would you be fine with oper-tag, congruent with account-tag?

Yes, that's what I'd call it.

@examknow are you still around enough to make changes to this PR? if not i can take it on

i think the concept of "oper classes" is so implementation-specific that it shouldn't be part of a protocol-wide standard

I would like to see the oper-role proposal I made included but if there's nobody else who is interested I'm fine with including it under a vendor tag.

i think the concept of "oper classes" is so implementation-specific that it shouldn't be part of a protocol-wide standard

I would like to see the oper-role proposal I made included but if there's nobody else who is interested I'm fine with including it under a vendor tag.

could we do it on another spec, so that implementing this spec doesn't require implementing oper-role? i'm not saying a hard no here, but i have a slight preference to doing it this way. more than happy to be outvoted

oper-role can probably be incorporated with no real negative impact - something like "the server MAY also attach a draft/oper-role tag containing information about the user's role in network operations, such as a privilege class" puts no obligation on anyone to do anything except not crash when they see that tag but standardises the tag name for anyone who does care.

What upside is there to have a standard tag with implementation-defined contents? What would clients do with this information?

It doesn't have to have a fixed meaning across ircds to be useful - a bot framework might offer it as a variable that can be matched against when defining custom access controls, for example.