RE: [NeoStats-Devel] [Commits] r174 - branches/3.0

Justin Hammond wrote:
> > > 
> > > Maybe getting NeoStats to maintain the ban list and a new 
> module, to 
> > > handle management of bans? Then this could handle all bans, 
> > > regardless if NeoStats set it or not? My experience with other 
> > > service packages is that they don't really support bans 
> not set by 
> > > themselves, so this might come in usefull?
> > 
> > The only reason we store the bans provided from the IRCd was in 
> > response to a request by Trystan for statistical purposes. I do not 
> > think that providing a list for statistical reasons is a 
> good reason 
> > to also provide a management console for them. It also seems pretty 
> > pointless to provide such a system since it is already 
> provided at the 
> > IRCd level or through services if they manage the bans.
> > 
> 
> I can't speak for other IRCd's but at least Ultimate3 doesn't 
> let you manage anything except klines from the IRCd level. 
> Management of akill's etc can only be done via Ulined 
> servers. Anyway, since we have that code there already, why 
> not take advantage of it with a bot?
> And the services that I've seen for Ultimate only manage 
> their own *kill's and not everything. 

So you have just described what I said, the IRCd manages its bans, services
manages its bans.

Ultimate failing to provide any ban support other than kline is not IMO an
argument in favour of us trying to fix it. If a ulined server can issue
other ban types, they likely provide the management system for removing them
limited by some form of access list we cannot access. If anything, this
point is merely an argument for NeoStats to manage its own bans, not every
ban on the network.

> > > > Completed ban support would also be likely the best way to
> > > determine
> > > > the method used by NeoStats in determining ownership of a
> > > given ban. 
> > > > Given that every ircd provides a way to remove bans 
> placed by any 
> > > > operator, a remove command in NeoStats is just nice to have
> > > so there
> > > > is no need to provide one at all. As mentioned in the
> > TODO comment,
> > > > allowing the removal of any ban from NeoStats is likely
> > to provide
> > > > opers an ability to remove bans they may not usually be
> > > authorised to
> > > > remove so IMO, if we cannot restrict it to removing bans
> > we own, we
> > > > should not provide the functionality at all.
> > > 
> > > Configurable maybe? Service roots can remove any, where standard 
> > > opers can only remove a subset of bans?
> > 
> > Since services already handles appropriate access for their 
> bans and 
> > the IRCd handles removal of IRCd issues bans, this system already 
> > exists without us supporting it at all. I see no benefit in 
> NeoStats 
> > being able to remove bans it did not set. The only benefit in being 
> > able to remove bans it did set is if as with services packages it 
> > offered a view of only bans set by it.
> > 
> > Why reinvent the wheel?
> > 
> 
> Well, like you say, we need to correctly handle ban removals 
> for bans set by NeoStats, so considering your previous 
> comments about identifing which bot set the bans etc, I just 
> see that it wouldn't be much more work to handle all bans. 

Having arbitrary NeoStats levels to try and work around the loss of package
side protection is a pretty lame solution. As an example, my network limits
the addition and removal of glines/akills to certain levels and these differ
from the IRCd and Services. I would not mind NeoStats glines/akills being
removable based on NeoStats access levels and it is a pain they can't. But I
would rather have the current strict access to glines than allow NeoStats to
remove anything it likes since it would override current network
restrictions and there would be no way for NeoStats to handle the settings
in place for the IRCd and services.

My feeling is that NeoStats should provide a management for its own
akills/glines and I would not object to this being provided by the core. It
could be configured to follow the exclusion system in that the core provides
both a global and local management system but *only* for bans issued by
NeoStats and its modules. I also have no objection to NeoStats being able to
report all bans on the network whether it controles them or not. But when
NeoStats avoids the protection levels on bans placed, I have to draw a line
and say that it is not a useful direction.

Anything such as a comprehensive ban management system should be done as a
module to avoid the unecessary bloat and obvious avoidance of protection
levels set for original ban management, The basic event infrastructure is
already in place for a module to provide ban management. Having said that,
it is extremely low priority given it is not on the critical path.