[EM] Delegable proxy/cascade and killer apps

[Michael Allan]

I think I can finally document the theory.  I've been in list
discussions for a year now.  It's payed off in design ideas.  Now I
have working code.  But it's hard to sustain a discussion (and maybe
hard to put the code into practice) without a clear theory.

I hope it's on topic for this particular list.  The theory does build
from a voting method (DP/C) of course.  Here's roughly how it starts:

  http://zelea.com/project/votorola/d/theory.xht

  (hit refresh, to see the latest figures)

Maybe other members of the list are interested in critical theory of
society, and how it could hook up with voting (aside from Fred Gohlke
and me)?  Anyway, I just a need a week or so before I can answer
questions and critique...  For now, pardon, I'll just reply to
particular points.

> A system could have a strong network effect combined with a large
> critical mass.  However, they are normally related.  A stong network
> effect would mean that the start-up requirement shouldn't be that
> massive.

Sorry, then my definition of "network effect" was wrong.  I doubt we
disagreed about anything else.
 
> Delegable proxy is like your system.  Everyone can change their vote
> and proxy assignments at any time.

I have to ask Abd when he's next online for refs (even to list
postings) so I can credit them.

So the vote is shiftable by the original caster.  Does the caster also
know that it assents to single action, such as the promulgation of a
particular bill, or the empowerment of an officer?  (I have to ask
Abd.)
 
> >  It introduces another "warehouse" into the supply chain...
> 
> Well, if it to cut down on noise.  Effectively, the proxy is saying "I
> will only read changes made by this group of people" and also "This is
> my proposal".

Limiting the group who can push to my draft.  That's what I meant by
giving write access to my immediate, principle voters (maybe 5-20
people) who may be proxies themselves.  It can be done with a single
Wiki.

> In effect, it is like an inbox wiki and an outbox wiki.  A proxy who
> isn't creating his own proposal could just point at his proxy's outbox
> wiki.
> 
> This is a reasonable balance as the proxy may not have unlimited time.
>  For low level proxies, they aren't likely to be professional proxies.

The separate "out" Wiki gives me a clean copy, so people know I
approved it.  I like that part.  But I can get that from a single Wiki
too.  The last revision edited by me is the clean copy.

With a single Wiki, I don't have to do all of the text integration
(from in to out) by myself.  Often the inputter's own integration will
suffice.  I just clean it up a little.
 
> > There may be no "elsewheres" left to go.
> 
> Why not?  There should be a huge number of low level proxies.  If you
> are a near top level proxy, then the higher level proxies should at
> least listen to you, especially as you can carry your supporters to
> them.  If they don't, then maybe you need a better negotiating
> strategy.

(The number of proxies may not be huge.  In the early stages it will
be small.  On the other hand, with a little patience, it may
eventually grow.  So there's openings in time, as well as space.)

But you agree that every draft ought to have an un-suppressable
presence, even if nobody else likes it.  That's all I was arguing for.

-- 
Michael Allan

Toronto, 647-436-4521
http://zelea.com/