The best reason to use a user mode, is that it is a well-understood interface, that IRC users know about. It is the conventional way, that most IRC servers use to control options such as address masking, invisibility, etc. There is a motivation to have consistency, and certainly it is easier for the user to control if a disconnect/reconnect cycle is not required to change host options. On Wed, Oct 21, 2009 at 12:07 AM, Trevor Talbot <quension@mac.com> wrote:
example, consider those old-school scripts that automatically remove bans placed against yourself.
I'm not sure it's a good example. The user of that script has the option to forego masking in favor of continuing to use that particular script. The scripts would need to be made aware of masking to succeed properly. In such a scenario, the ones that couldn't would be obsolete. Just like such an old-school script designed for an IRC environment with no channel services would be unable to detect and delete a ChanServ AKICK. The script would fail if any ban for the unmasked version of a masked user's host would still be enforced (even while they are masked), in any event (as it should be).
ages. The assumption that a host does not change was embedded in IRC behavior when hosts were added. It's visible in the way server-side things like channel bans are handled, how stateful clients gather and apply
I don't believe anything major breaks too badly when masking is implemented in violation of those assumptions that doesn't also break when those assumptions are preserved. IRC clients in general do not keep long term record of channel member list information. Some cache it to varying extents. Some do keep the information. Someone's assumptions will be violated, no question. Most of them constantly update any cached userlist information, especially when a new message is received from a user, with a different hostname in the message prefix. A masked user failing to match an old bot's access list is a consideration, but with a usermode, the effected user may temporarily resume their real hostname, for a long enough duration to update their access list to grant a suitable masked version access. I don't think the ill effects of violation of the assumptions are worth imposing unusual or excessively inconvenient kludges, such as a requirement to pre-authenticate for masking, or to reconnect to change address masking status. Other IRCD implementations have implemented masking without preserving those arbitrarily assumptions: if there were major issues in their experience, that would be one thing. So far the justification for preserving these assumptions at the cost of some increased complexity seems pretty questionable... A user negatively impacting themself by enabling masking is basically a non-issue, as long as it is an explained caveat, that is understood before masking begins to be used... What should be avoided is a user's choice to enable masking negatively impacting _other_ users. -- -J