Nicole

> my concern is how we get the IRCd and services to work together to translate account names and IDs back-and-forth. > > if we have e.g. an extban for...

> One character won't make or break their gecos. one *byte*, fwiw, might end up cutting off part of a multibyte character – granted, this can already happen if clients...

It's probably easier to just connect with the certificate and run `/msg NickServ CERT ADD`, which defaults to the certificate fingerprint currently used, fwiw. That also ensures the certificate is...

The ircd doesn't know about verified/unverified; instead, services do not propagate logins for unverified accounts to the ircd. However, you can still log in, including via SASL. (The `SVSLOGIN` message...

We check whether the user has an account name set, which indicates they've authenticated to a verified account; at the point we check that, this is only possible via SASL,...

Also, per , > There appears to be an integer underflow with large negative numbers (n-2^32). > Example: `@1.2.3.4/-4294967296` (n=0) matches all IPv4 on testnet.

We're definitely interested in implementing this, however it depends on implementing message tags in general per issue #170 first.

This isn't too hard to do, but quite hard to do *properly*. There are various points to consider – confusables, casefolding, normalization, what characters to allow – hence I suspect...

This depends on us implementing support for message tags, as tracked in #170.

Looks like `protocol/nefarious` doesn't provide an `unkline_sts` implementation, so services don't actually know how to remove akills on nefarious. At a glance, Nefarious documentation appears to indicate it has "global...