[ticker-dev] Latest draft

[Bill Segall]

> In fact, this concept may also improve the idea of the <username>
> channel if things were switched around to be the "personal"
> channel with Distribution <username>.

The idea of personal hadn't occured to me and I like it a lot. I
(unsurprisingly) run a personal Elvin router and a lot of my personal
instrumentation/info groups could really benefit from a "scope of me".
e.g., I currently have a cvs group and a bill.cvs group instead of a cvs
group with distributions of "me" and "mantara".

Thinking further, my distribution falls into several catgeories and
without wanting to get into an ontological war I have the rough broad
categorisations:
personal: just me
work: colleagues/corporate
world: everybody

Between the gaps, I also like to distribute stuff to some selected
individuals on a case by case basis. An example is the conversations I
might have with Ruth and I currently accomplish this with Elvin security
which in some ways is a more appropriate mechanism. The bit I don't
understand with this group is the gap between distribution and security.
This traffic is always restricted to my local router but other private
and secured groups I have are distributed. It's almost as though I need
a:
security: "list of federation rules"
to add to the above list.

I'd also like a:
friends: a kind of buddy list system

With this view, the "work" distribution is also just a special group of
people, and in fact if I had a broader ability to specify groups of
interest I might choose it. Before we begin to specify distribution
lists which could become a nightmare, what I'm wondering about is how
the UI might allow me to specify what I wanted without worrying (yet)
about the underlying mechanism.

>From a UI point of view, I currently find "leakage" to be a problem.
Leakage seems to be a phenomenen of CBR in some ways - it's as though we
have this terrific routing ability but we can't manage to get the UI to
obey what our brains are thinking. How can we build a UI to specify what
we want, how do we trap mistakes to ask users without it being
intrusive, how can we inform users *before* they post about what they
are actually doing? Once we have these ideas in place, how do the
messages contain attributes that more easily manage the routing choices?
(and from a Mantara perspective, how do we easily manage fderation rules
once we've made those decisions?)

Is a dropdown menu significantly harder than a toggle button? Can colour
help? Once I've received a message how can I tell it's distribution so I
don't accidentally blurt  out someone's secret? Could I help leakage by
having a replace option on reply so that I can "cancel" my previous
message? --- the number of times I've wanted that :-)

Experimental would seem like a great plan from the specification
viewpoint. I think this could go a long wat to encourage a new era of
trying things out. I suspect that part of the problem is that we're way
too focussed on getting this spec "right". Perhaps we should just close
it out and then start on the next version. Specs are great things but
there needs to be revisions and new versions as well.

Bill.