The behaviour is the same as /msg except that where
/msg would send RPL_UMODEGMSG to the user, the /invite
is instead let through. This counts as a notification
for caller_id_wait like RPL_UMODEGMSG.
Checks are on the target user's server, which means an
error message will appear after RPL_INVITING.
This must be because the accept list is not globally
known.
Similar to /msg, inviting a user that is not in a channel
you have op or voice in requires a free target; opers always
have a free target.
Being invited adds the source as a reply target.
When a user receives a private message, notice or RPL_UMODEGMSG,
add the source to a special set of 5 target slots.
These slots are checked in the normal way when sending messages,
allowing a reply without using up a free target.
This feature will not be very useful if a user is being messaged
by many different users; to help this, messages blocked entirely
by +g or +R do not affect the targets. CTCP replies also remain
free in terms of targets.
The server protocol for this is
:<uid> ENCAP * CERTFP :<40 hex chars>
both in new user introductions and in burst.
As in oftc-hybrid, only the user themselves and opers can see the certfp.
Displaying the certfp on connect seems unnecessary to me,
the user can whois themselves if needed.
Any kline (or various other things) containing * or ? is
a mask kline and not an IP kline. Ideally, rb_inet_pton_sock()
would return failure for those, but in practice this is not
always the case for IPv6.
Such a kline that is erroneously treated as an IP line
likely matches way fewer IPs than expected.
This lets a user connect with a client certificate, and
passes the certificate's fingerprint to ircd, which
currently just notices it to the user.
A new ssld->ircd message 'F' is used to pass on the
fingerprint.
This is only for OpenSSL for now, not GNUTLS.
B.Greenham
Jilles Tjoelker
William Pitcock
JD Horelick