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

[Anna Gerber]

> 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