[ticker-dev] Bots, Presence, Personal Channels, Transient Subscriptions and 'T hread-Id'

[Wanicki, Martin]

Firslty I dont want to "force" bots to bhave in this way, but I think it
would be nice if bots
afforded the user the option of keeping a query and its reply personal, and
sure, I understand
that bots tend to respond on the channel on which they are invoked, so thats
fine, however..

there may be cases where one would NOT want a prarticular bot ever respond
on a public channel, and the adoption of 
a standard way to behave for such bots might be a good idea.

Within this organisation I have already been asked to make bot traffic
invisible to public channels, this is partially 
because we have users here relatively new to the whole tickertape concept
who are still saying that lots of messages they arent interested in, is too
distracting.
and secondly this is a privacy and security concious establishment and these
issues are more the rule than the exception.

Also it seems that the sharing of a bots response encroaches on an
ettiquette issue.
For instance I dont see that I actually have the *right* to shove stuff on a
multitude of screens just cause I wanna share a bot response with one or a
few people.

It affords me some level of comfort to *know* that a bot wont respond on a
public channel, even if I accidentally post a bot query to a public channel.

Regarding the security issue, sure use keys, if they are available in the
API you're currently using :-)
The addition of security to the COM api will go sifficiently towards solving
the problems, but key distribution still represents a problem.

I do understand the desire for "open-ness" in the protocol, but the
corporate world is still firmly tied to the apron strings of yesteryear :-)
and as such 
tend to consider such open-ness to be something that can be explioted or
abused by personnel for any number of reasons, be they innocent, personal or
malicious.
*some* companies consider 'personal use' to be 'abuse'  and tend to frown on
anything that is too open to personal use :-(

Cheers

Martin
> ----------
> From: 	Anna Gerber[SMTP:agerber at dstc.edu.au]
> Sent: 	Monday, November 26, 2001 10:59 AM
> To: 	Wanicki, Martin
> Cc: 	ticker-dev at dstc.edu.au
> Subject: 	Re: [ticker-dev] Bots, Presence, Personal Channels,
> Transient Subscriptions and 'T hread-Id'
> 
> 
> > If we ratify these as standards, particularly the 'user at domain' format
> of
> > usernames and personal channels based on this name,
> > bots while listening to all channels can safely reply to only that
> channel,
> > therby removing unwanted bot traffic from other more populated
> > channels.
> > Further, if clients we set up to only emit bot queries on personal
> channels,
> > bots could subscribe to all queries with a simple
> > ( contains( TICKERTAPE, '@' )  && contains( fold-case(TICKERTEXT)
> > ,'my_bot_keyword/name','?' )
> 
> I don't understand why the above is necessary or desirable. Currently,
> most bots reply on the channel where they were asked, so if you don't
> want to clutter up public channels, you invoke the bot on a personal
> channel, however if you want to share the bot's response, you can invoke
> it on a shared channel.  This model of interaction with bots is easy to
> understand and seems to work well.
> 
> I don't like the idea of forcing bots to only listen/respond to channels
> of the form 'user at domain' because it no longer allows the sharing of bot
> responses on shared channels that don't have a name of this form.  (Aside
> from issues I already have with standardising user at domain as a personal
> channel name because I like to use the same personal channels regardless
> of whether I am currently agerber at dstc or anna at home and also because I
> like to have a number of different personal channels for different
> purposes)
> 
> If your concern is with reducing bot clutter on public channels, then I
> would prefer a key based solution (where users establish keys to be used
> with each bot, so that they only see their own requests/responses)
> because this is scalable to groups of people (who all use the same shared
> key) and works for arbitrary channel names.
> 
> Anna
>