[IRCServices Coding] Mass memos

[M]

Trevor Talbot wrote:
> Services issues the messages itself.  The only sense in which it uses 
> the ircd is the same as for any other entity on the network: the ircd 
> is a relay point.  Services' issuance of messages is not tied to any 
> part of the ircd's login process, nor is it affected by any delays 
> present there.

Merely issuing logonnews messages later in the process would be unlikely
to make any difference to visibility.  The delay picked will likely
still conflict with other incoming messages and likely relies on the
user returning to the status window after whatever they fill the gap
with prior to the message. Neither the IRCd nor services can accurately
predict a point at which logon news would not be placed amid other
messages so merely issuing it later will not solve the issue. It will
merely put it into a different place during the process that users who
do read it will not expect. 

I originally assumed that the proposal was to force users to see it by
pausing at that point (time delay or press any key style AKA telnet
login notices) which would be an IRCd issue to support such a delay, not
a services one. I would not support this system either since users
generally want to get onto the network and chatting ASAP. 

> Many people
> deal with large amounts of information, and so may notice the memo
> notification while unconsciously ignoring the login news (much like 
> motds are ignored).  This is just speculation, of course.

I see what you are saying but disagree with the conclusion. It is not
supported by the number of users who incorrectly identify for a nickname
then are most surprised when they are "guested". If they miss the
failure notice, they are equally likely to miss the memoserv notice. 

We only use logon news to announce important events so it is immediately
obvious to people when it changes since there is normally nothing
displayed at that point and the logon process looks different when it is
displayed. Conversely, I have found a number of users (particularly
newcomers) tend not to notice any message from memoserv since the
message occurs at every logon and the pattern is so familiar to them
they tend not to read the notice closely. 

One thought does occur with the mention of MOTD, a client can issue this
command to retrieve the message whenever they desire but they cannot do
this with logon news (IRCops aside). Maybe the solution is not messing
around with delays, but thinking of a new way to propagate this
information. The quick way would of course be to allow /os logonnews
list to all users. However, I favour keeping OperServ solely accessible
to opers so would suggest "NewsServ" or similar as a way to allow end
users to access current news on demand. 

> Memo visibility is logically heightened by notification in other
> circumstances: nick changes, identification, etc.

IME, a great number of clients do not change nickname that often (if at
all) and once identified tend to remain that way. IIRC, the new linked
nick system, means that those that do tend to use multiple nicks do not
have to identify for the change should it be so linked. Increasingly
users use clients or additional scripts to automatically identify to
services. The lack of user input into the process further decreases the
notice a user will take of notices in response to identification etc. 

> The best solution for this issue in general would be to have clients 
> become "information managers", where they could do things such as 
> deciding if the motd or logonnews has changed since last connect, 
> providing alerts if necessary, and so on.  The ircd and services would
> need to provide standard formats for this information.  Unfortunately 
> we're nowhere near the point where this would be useful, especially 
> considering the motd format has been standard for a very long 
> time, and 
> clients haven't done much with it.

ISTR at least a couple clients that tried to do something with it such
as routing it to a separate window. There are ways to improve the
process but as you suggest, they really require changes to both the IRCd
(or at least adding some field(s) to the MOTD file) along with client
changes. 

/os global tends to suffer from visibility for similar reasons to logon
news and other notices. However, IME sufficient users are aware of them
and paste within channels so that those others see them. Similar occurs
with logon news with it being discussed in channels in front of those
users that do not bother to read it. 

Much of the visibility is down to clients and the way that a user uses
IRC. These things are beyond our control. However, approaching the
writers of the more common clients/scripts may be the way to get the
clients to perform better in this regard. Trapping the MOTD is
relatively trivial for a client. For IRCServices at least, trapping
logon news should be similarly trivial (given the format of the notice).


Some IRCd packages are now implementing a dual MOTD system. At logon,
the user is presented only with a "short MOTD" which can act as a
"headline" that the user can further read by requesting the full MOTD.
This helps reduce the redundant information passed to a user on connect
and clean up the connection process as well as saving some bandwidth. 

> In the meantime, things such as mass memos are useful for a variety of
> reasons.

I disagree. A mailing list would be a much better system to employ. It
is opt in, creates no additional load on services and is more likely to
be read than a memo by all users who subscribe. Couple this with web
based information and you cover users who choose not to have the
additional emails and do not read logon news. 

A user unable to receive memos from friends because their memo box is
full of messages about stuff on the network that they may have no
interest in reading is not IMO a useful feature. As another poster
mentioned, those users who visit infrequently are the most likely to
suffer in this scenario. Filling the memo box via mass memos will for
all practical purposes destroy the memoserv facility for a number of
users.

Since a mass memo system should really be opt in, it is a simple matter
for those interested to register their name in some manner with whoever
wants to send mass memos, then the sender use a simple script to message
only those users. This can be done without any required change to
services and would not be subject to the problems in the OP's original
script wrt linked nicknames. Such a script merely needs to parse the
response from memoserv to automatically delete expired nicknames
registered with the system. 

M.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003