It's not a bad idea, and would curtail or discourage certain abuses, but it's also not a trivial proposition. For IRC servers to make decisions based on channel access as recorded by agents like ChanServ, they have to know more than they currently know. It requires either services annotate the channel state, i.e. indicate "why it ops" someone, what level they have, and all servers pass it along, which requires good synchronization. Or a Request-Approve-Act cycle occur whenever someone attempts to kick/deop someone (Query services or an agent synchronized with services [such as a slave database server] for approval, execute the request only after approval) The latter solution presents scalability issues, and system degradation -- do you want to wait 60 extra seconds for services to confirm your deop/kick before you can de-op/ban a channel hijacker? I think not. For it to be effective, there would have to be servers to provide authoritative answers at low latency to every single IRC server. The former solution presents a lot of problems like -- what happens when access level changes. Maybe ChanServ didn't op the SOP originally... i.e. someone else opped them, and they identified with NickServ after the fact. Then extra traffic is required to attempt to push an 'update' to the channel state, indicating the change of identified level. These are all mainly services development matters. The feasibility of implementation depends on the design of services. The cost depends on the protocol methods chosen. And I doubt there are many services developers available to implement something like this. Or at least in the past there haven't been.... On Sun, Apr 12, 2009 at 9:02 AM, BILaL Bhatty <expl0iter@live.com> wrote:
Hello I wonder If your Team can code so SOps can't get BANNED & OR KICKED from the channel that will help alot. What do you say?
-- -J