On Oct 23, 2009, at 6:10 AM, James Hess wrote:
On Fri, Oct 23, 2009 at 3:04 AM, Trevor Talbot <quension@mac.com> wrote: It's interesting this reference to "modern stateful clients". What 'modern stateful clients'?
Basically, any client that follows the spirit of IRC by translating, automating and otherwise turning the low-level interactions with the server into something as user-friendly as possible. Most mainstream clients maintained today keep significant amounts of state: modes, clients in a channel, current topic, channel types, mode types, ban lists, maximum length of available identifiers, online status of other users, etc. Much of 005 is dedicated to helping clients maintain state information about both their own sessions and those of other clients.
As far as I know, modern clients do not make assumptions that hostnames are static in a way that leads to any lasting issues with masking, can you show what the exceptions would be, what one or two specific major IRC clients?
One example is commonly implemented forms of flood detection. Eggdrop's sentinel.tcl, among others, uses a host-based hashtable to detect and respond to certain types of clones. If a client's host can silently change, that mechanism breaks.
Let's forget about modern stateful clients for a moment, and go back to basics: /ignore. You're suggesting a situation that will result in a user /ignoring someone in a channel, then having unwanted content from them suddenly show up with no indication as to the reason.
This is true even if they can only opt out of masking by reconnecting on a different port (or logging off, then back on).
You missed the qualifier, "with no indication". If a client quits, parts, or otherwise changes its presence in the channel and vanishes from view, the user is notified that something has changed and it might not be ignored anymore when it returns. If any client can change its host without notification, the user sees an unreliable and broken feature instead.
Based on what I've seen, hostmasking is considered an almost universally desired feature and is rarely *unused* on networks that offer it as an option. Why do you think it will only be used by a minority? Why do you imply that minority will have no effect on others in the same channels?
I don't think 'almost universally' is true... hostmasking is very commonly desired, however, and widely implemented.
I believe 'toggling' or use of a user-mode to toggle it on, is among the most common methods of user control of masking, most implementations don't make it mandatory. What then makes you suppose pre-masking assumptions are significant?
I agree it is the most common method of user control, but I am challenging the implicit assumption that it is even a *good* method of providing masking, let alone the best compromise currently available for most uses. I'm not certain of your question. If you're asking why I think assumptions made before hostmasking existed are relevant, then my answer would be that various disadvantages exposed by implementations of masking that violate those assumptions continue to affect users today, despite having many years to work out solutions. Several networks that implement realtime mask toggling have found it necessary to also provide quit/reconnect simulation, which is a strong indicator that the assumption of a hostname not silently changing is significant. The problem of optional hostmasking making it more difficult to maintain client-side access controls (like /ignore or bot lists), and in some cases server-side access controls as well, continues to hassle users without any similar workaround. Again, evidence that an assumption that there are not parallel artificial host namespaces is still relevant today. If you're asking why I think predictions about how masking would be used on DALnet are relevant, then my answer would be similar in that there is sufficient evidence available from other networks to make an educated guess.
People who don't use +i currently make up less than 0.3% of DALnet's userbase.
Yes, but did they when +i was first being implemented?
Spambots weren't an issue when +i was first implemented; it was solely a privacy feature. I do take your point that there was a gradual shift in use at that time, since people were used to not having it. I believe that shift is both greatly accelerated and has a head start for hostmasking, as it now exists on more networks than not, and like +i it has more than just a sense of privacy driving its adoption today.
Also, it's worth noting that +i (invisibility) wasn't made and hasn't been made mandatory, ever...
No, but it has been made default. I suspect that on networks with default anonymous hostmasking the percentage of people who choose not to mask is similarly low. Without a practical reason for avoiding it, that personal preference has all the substance of "I want pink ponies", and should be weighted accordingly in comparison to other issues. -- Quension