[ticker-dev] Re: Elvin presence spec draft - request for comments

[Matthew Phillips]

Another consolidated reply to David, Martin and Klaus.

David:
> i had a late-night, in-bed, semi-conscious read of the draft last
> night, and this was the point that struck me most.

Good, because I wrote it early morning, semi-conscious, so we're nicely
balanced ;)

> the use of foo at location naming evolved (again, i think Rik Taylor
> started it, or at least popularised it?) to add an extra dimension to
> the awareness generated via ticker.  you could now, almost implicitly,
> determine where someone was.

> i like this a *lot*, but it has always clashed with my desire to
> enable scalability of ticker to a larger audience, something that
> simple names don't, and for a while, the use of foo at location competed
> with foo at some.unique.domain as we attempted to encourage people to
> adopt a globally useful naming scheme.
>
> my guess is that the popularity of foo at location at DSTC is a result of
> our multi-site groups, frequent use of ticker while travelling and the
> popularity of working from home.

The problem of course is that we are overloading someone's identify (static)
with location (variable).

In fact, this whole debate is tricky, because we want a way of uniquely
identifying people using some text that is based on their attributes rather
than a random string.   And there isn't one.  The usual workaround is to say
the combination of my name plus my organisation/group/collective/borg is
fairly unique, so I'll use that.  But most of us wear at least 2 hats: work
and personal, so we have two identities.  Which isn't necessarily a bad
thing - maybe we don't want everyone to be aware that they are the same
person.  So, upshot is: a username/logical domain combo actually seems to
work.

>   Matthew> As Bill suggests, other information, such as where you are,
>   Matthew> can go into the presence info.
>
> yes.  and, no.
>
> putting location info into a/the presence protocol is good, and right.
>
> but i don't think a result where you need to have a presence client to
> determine this is necessarily good.  i *like* the fact that tickertape
> is currently able to give me location information as a side-benefit.
>
> perhaps this comes back to the idea of tickertape events having both a
> unique name for the sender, and a nickname that can be displayed?
>
> i don't think (?) i would like to require support for the presence
> protocol in all tickertape clients?

Yep, I agree we shouldn't require presence support for using ticker
effectively, and I think that a "Display-Name" or somesuch field on ticker
could be used to replace what would be lost by using a domain-as-identity
scheme.  I could have username 'Matthew at dsto' with a display name of
"Matthew (at home)" or somesuch.

>   Matthew> I really, really want to avoid having a binary crud unique
>   Matthew> 'user id'.
>
> agreed.  i think most of the presence systems have decided that an
> email address is the best solution, since everyone has one already,
> and it's already unique, and it's human-readable, textual and all that
> nice stuff.
>
>   Matthew> The other reason a domain is useful is that it gives you a
>   Matthew> useful starting buddy list that is automatically populated
>   Matthew> and maintained (note that being able to see everyone in the
>   Matthew> whole of tickerland is unscalable).
>
> i do like the idea of have my presence client have a default domain,
> but i'm not sure it needs to be the domain part of my unique name.
>
> for example, i would likely want to use `d at 0x1.org' as my unique name
> because i have a network life outside my employer (well, kinda) and
> because it is persistent across changes in employer.
>
> but i would normally want to have `dstc.edu.au' or maybe
> 'dstc.monash.edu.au' as my default domain (given that i'm the only
> person in the 0x1.org domain ;-)

Your comments and Klaus's make a convincing case that presence clients
should _start_ by defaulting to subscribing only to your domain for
simplicity, but that other domains should be able to be added as needed.
This lets you move domains but still maintain presence contact.  So, when
you are at home as d at 0x1.org, you might also subscribe to the 'elvin.dstc'
domain.

I'm viewing domains as sort of 'public buddy lists' - I want to see everyone
who's online at DSTO and I don't know who they are (now, or in the future)
so I subscribe that domain.  In fact, if 'group' wasn't already used for
referring to ticker groups, I would have used that rather than domain, since
it's more in keeping with its function.

Martin:
> Why cant the clients organise the people they are interested in into their
> own domain groups.
> Automagic is cool but there seems to be no "consitantly reliable" way to
> determin that an individual
> is in the same domain as our client (us).
> Especially when we seem to be abstracting domain to mean a "group" /
"team"
> / "bunch of people we are interested in"

Without a domain concept everyone _has_ to build a static buddy list before
the presence protocol is useful, and people have no way of automatically
announcing that they are now 'out there' to a likely domain of interest.
I've seen the value of this a number of times at DSTO: when someone
experiments with Sticker they immediately see who's already there and some
groups they're listening to.  Without that presence, they would start up
Sticker, fire a message to Chat where it gets buried, after which they never
bother running it again.

Note that you guys are a serious worst-case scenario ;)  You all use ticker
from various locations wearing various hats.  A ticker newbie probably wants
to enter a username/domain and automagically have everything else kick in.
Later, they can start messing with adding people/domains to the buddy list,
but this gives a low-overhead, useful starting point.

In summary, I would still push for people to be in one domain, but to have
optional visiblilty of (and visibility in) other domains.

Sorry to rabbit on, I would have written a shorter response, but I didn't
have time,

Cheers,

Matthew.