[IRCServices] IRC Services 5.1 Features

[BrightSide]

> Noted.  (No promises, though... maaaybe if you get enough people
> to  pester me ;) )

pester, pester, pester! :)

But on a more serious note: if it will be any help, I'll be more
than happy to share my hacked Bahamut protocol module which I'm
currently using for Ultimate3. (Running on irc.quasinet.org for
anyone who got some idle time and wanting to see it in action)

> I admit handling of the channel admin/owner mode was only added
> in  as a "might as well use it" sort of thing.  I'm not sure I
> like the  idea of adding yet another ChanServ option, though.  As
> far as I  understand it (correct me if I'm wrong), channel owner
> mode is just  like protected (+a) except that it can't be unset
> by other +a  users; if that's the case, I'm not sure there's much
> reason to use  it at all--after all, ChanServ will always let the
> founder unban,  rejoin, and get +a back as needed.  (And
> internally, channel owner  mode support is a pain because
> different ircds use different mode  letters for it.)
>
> What would people think of just doing away with channel owner
> mode  support entirely?

I don't have any experience with other ircd's so I can't answer for
them, but on Ultimate the +a is used in much the same way as halfop
except that it is one step above chan-op instead of one step below.
Channel-Admins can give and remove mode +a for other users, chanops
can not. Chanops are also not able to kick admins out of the
channel, in the same way that halfops are not allowed to kick
chanops. When a new channel is created, the first user is given
chanops status and for this reason it's necessary for services to
be able to set this mode. There is no way normal users can set this
themselves without requiring assistance from an ircoper.

The reason I want this to be specifiable is because some users want
to use this as a "founder only" mode, and some want to use it as a
mode given to the founder and all co-founders (a.k.a SOPs). I have
also seen some clients break because the mode is outside the
RFC1459 spesifications, so I believe that some users might find it
more annoying than helpful so they want to disable it completely,
in other words make chanserv not set the mode at all. But these
needs varies from channel to channel.

> Channel memos is one thing I've been meaning to revisit for a  
> while; thanks for reminding me.  The channel memo system is a
> major  hack as is, with no notification or anything else that can
> be done  for nicknames.  So let me pose a question:  What would
> you (anyone  feel free to reply) want to use channel memos for?  
> In what cases  would you want to send a memo to a channel, and
> who would you want  to read the memo?  I've got a few redesign
> possibilities in mind,  but to avoid leading questions, I won't
> mention them right now;  just assume channel memos could do
> anything you want, and tell me  what you'd want them to do.
>

I see channel memos as a simple way of informing all operators of a
channel about channel events without requiring them to be online.
This could be messages informing them of new operators, channel
guildelines etc. etc. It's an easy way to reach everyone at the
same time so you can be sure they got the message, and there's no
need for channel-users to create their own mailinglist or a forum
board. From my own experience, I have found this very handy in
channels with users from all over the world, as it's impossible to
reach everyone at the same time because of timezones :)I see
channel memos as a simple way of informing all operators of a
channel about channel events without requiring them to be online.
This could be messages informing them of new operators, channel
guildelines etc. etc. It's an easy way to reach everyone at the
same time so you can be sure they got the message, and there's no
need for channel-users to create their own mailinglist or a forum
board. From my own experience, I have found this very useful in
channels with users from all over the world, as it's impossible to
reach everyone at the same time because of timezones :)

Also, a final wish:

3) I've noticed there are a callback for "receive message" to
capture all messages sent from a server to services but I have not
yet found any way to capture all messages sent from services to a
server. It would be useful to support server-to-server compression
and encryption.

-BrightSide-