Stats responses are incredibly non-standard and no clients render
them correctly. This makes using /STATS a massive pain in the ass
for users.
However, now we have message tags we have a way to fix this. We can
send a <trailing> with the message details and for clients (probably
bots) that need to parse the response we can include the specific
details in message tags enabled by the new inspircd.org/stats-tags
capability.
The average user will get this:
:<server> 210 <nick> <stats-char> :<stats-message>
If however they enable the newcapability they will get this instead:
@inspircd.org/stats-foo=bar;inspircd.org/stats-baz=bax :<server> 210 <nick> <stats-char> :<stats-message>
The numerics we used previously were not being used according to
the RFC and every implementation has their own behaviour here which
makes it hard for clients to do anything reasonable. Instead of this
using the generic stats numeric makes a lot more sense.
- Allow overriding privileges from the <class> blocks in the <type>
and <oper> blocks.
- Separate oper types from oper accounts in the code. This enables
moving some core stuff out of the config tag later.
- Merge the config tags together to make a synthetic tag that can
have getXXX called on it instead of using getConfig and then
converting it.
- Move the details of Have*Permission into the oper type class.
- Improve oper events to allow modules to easily hook into the oper
system.
A Cap::Reference can not be cast to a Cap::Capability& because it may
not be available and that would create a null reference. In v4 we can
change the API to take a Cap::Capability* but for now this is the best
we can do.
We previously referred to both session registration and user registration
as "registration" which is confusing for users who aren't familiar with
how IRC works.
This isn't used much currently but in the future will allow doing
a lot of behaviour which is currently implemented in services in
the IRCd instead e.g. killing ghost clients, nickname enforcement.
