On 7/19/13, Holbrook Bunting <holbrook@dal.net> wrote:
On 19 July 2013 04:35, Jimmy Hess <mysidia@gmail.com> wrote:
I like your idea of an invisible banlist entry. Perhaps some sort of linked ban which the hidden +b only gets sent from server<->server and not server<->client(s). May put unnecessary burden on server, but worth looking into.
What an implementation of an implied ban could look like is a canary, e.g. suppose you have userchosen.HASHCODE.masked.dal.net when you do a channel ban add, you could have - When a user comes online, and bcomes masked, they get somechosentext.HEXCODE.masked.dal.net - The Hex CODE is a key into a database or cache. - The cache should contain two things: the current real hostname. And "variability history" for that users' logins via that second level domain For example: if one day they logged in with port42.city.state.example.com And on the next day they logged in with port43.city.state.example.com Then the variable portion is the first dot, based on the user's login history. *.city.state.example.com would be the login history-adjusted version of the banmask. If that user later logged into services with port16.city.otherstate.example.com Then the variability-adjusted mask is now *.example.com The expectation is services would "Announce" the HEX KEY data and the "variability history" data, at the time that the user logs in. When a ban is set: it might look like *!*@someuserchosentext.HEXCODE.masked.dal.net [ 1] Add a 32-bit field to the banlist structure to denote a 'tag' [1] Test if the ban entry being added ends with ".masked.dal.net" [2] If it does, look for a dot followed by some text. [3] If HEXCODE has a valid hexcode, then, populate banlistentry->tag with that code. [4] When a ban is checked; for the host portion, also check the "Variability adjusted" Host database entry, that corresponds to the Banlist Entry's "TAG" field -- -JH