Allow extra characters about girc HOT 3 CLOSED

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).

from girc.

Closing this given my last comments, though can re-open if you have further questions/concerns.

from girc.

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.

from girc.