Allow extra characters
qaisjp opened this issue · comments
Somewhat related to https://github.com/lrstanley/girc/projects/1#card-6997933
Functions like IsValidNick
and IsValidUser
exist:
Lines 214 to 241 in 51b8e09
Lines 243 to 286 in 51b8e09
It would be useful if we could abstract this into an interface NickValidator
.
My particular use-case is that we have a customised IRC server that allows certain users to use the tilde (~
) character — discord puppets have a ~d
suffix. See qaisjp/go-discord-irc.
Would you be willing to accept a pull request that implements this?
(This would prevent the need to fork your repo.)
My first question would be.. why? Why choose a character that isn't standard (if it is, excuse all of this, its been while since I've looked at the spec)? Why not compromise and use a different, already supported character? Why choose a character that is unlikely to be supported by some clients/bots/libraries/etc?
Yes, I had thought about moving these things into a separate package, but the goal is not to make it pluggable in the sense of "replacing" components with their own -- as, the only reason someone would want to deviate from what I have, is if what I am checking for is wrong (then, a PR to allow other characters makes sense), or if they're not following standards. I don't really support deviating from the standard as this is already a huge issue with the IRC community and protocol.
The goal was to let users only use formatting and/or validation without importing all of the other cruft, for things other than the client library (e.g. maybe someone stores logs in a db and they want to validate input into that db, etc).
Closing this given my last comments, though can re-open if you have further questions/concerns.
Why should the client validate what the server is going to anyway? Don't second guess yourself, if the server doesn't want it then the server will complain. The RFCs are not the gospel, IRC has long since evolved past the RFCs and there are dozens of implementations with varying levels of conformance for which girc would be useful if not for the fact that it second-guesses itself.
This is the most reasonable "authoritative" reference on what's valid:
https://modern.ircdocs.horse/#user-message
It says nothing about permissible characters for USER et al. The only reasonable thing to enforce is that there are no spaces, because otherwise it wouldn't fit into the IRC message grammar.