Web Service (Web 2.0)

[Michael Allan]

Hi Paul,

> I think it would be useful to have a single portal so people can try
> this method of delegate cascading for consensus building on any issue
> whatsoever regardless of state jurisdiction (city, province, country).
> For instance, many issues can gain momentum via cross-border
> solidarity. Take the boycott of apartheid South Africa for example.
> This may not be what you envisioned the the tool to be used for, but I
> see merit in providing a general-purpose service that might be useful
> at at all scales and all matters whether they be global or internal to
> a particular community. This would provide a way to introduce this
> form of consensus building to people on issues that they feel most
> passionate about (people generally are not passionate about state
> politics), which would pave the way for using it on larger scales and
> in state politics.

So top down (global) and not bottom up (local).  You are maybe
thinking of a global international site, as shown here (top of fig.):

  http://zelea.com/project/votorola/s/manual.xht#Peripheral-Subnet
 
You can set that up.  The crucial requirement is probably voter
authentication.  You can compile an authenticated voter list from the
registers of the local sites.  See the figure here:

  http://zelea.com/project/votorola/s/manual.xht#voter-register

In your case, you might start out with something like this:

       G  <--  Gr

     / | \
    /  |  \

  L    M    N

The global periperal site (G) synchronizes on the voter registers of
the core sub-sites (L, M, N).  So as each city and local region comes
online, you tap into its register feed.  The human side of your admin
overhead is kept to a minimum.  The voter lists are self maintaining
and you have no electoral districts/boundaries to worry about.  Mostly
it's a technical admin job.

For voters who aren't yet covered by a local core site, you can have a
temporary global register (Gr).  (Some of us were talking about this
offline recently.)  It won't be able to authenticate voters in
ordinary ways (maybe not at all), but it will allow them to transfer
their registrations to the local sites, as they come online.

Anyone can then raise an international issue, and people everywhere
can vote it up.  It would require years to approach anything like a
global consensus (authenticated).  By then you'd be obtaining your
data feeds from national and federal core sites, not directly from
local core sites.

The crucial requirement in the code is the database synchronization
interface, and the aggregation of the super-register.  Neither is
developed yet.  You could get by temporarilly (for alpha testing) by
integrating G + Gr in a single pollserver, and (unlike a normal
super-site) accepting your registrations directly.  Your votes would
all be unauthenticated at first.  (But so pretty much are everybody
else's, until the trust network is better developed.)

> So I would want a single installation (or portal that has one or more
> installations on the back end) that works for all 'issues' or
> 'causes'.

The above will work for international issues.  You can't do local
issues from the same pollserver, because you couldn't possibly
adminster it all centrally - it would be politically impossible, and
an admin nightmare too.  I would end up breaking into more rational,
manageable pieces.

But you seem to be thinking of a pollserver hosting facility, and
that's interesting.  I never really thought of it before.  A local
administrator doesn't need to install his own hardware and systems
software.  He can use a hosting facility.  He can then concentrate on
the configuration of the pollserver (central host) and the human side
of admin (local).

This is possible with the current code.  Pollservers are logically
separate, and every core site has at least two (offline and online
pollserver).  So there's nothing to prevent you from running thousands
of them on a single server (or server pool) side by side.  SSH will
probably suffice for the admin interface.

The code will need optimizations to keep the memory footprint down, as
it scales.  But most of that has to be done anyway, and none of it
challenges the design.  The implementation is currently inefficient of
course, but you could start hosting today (on a limited scale).

> Thanks for your work!

(You're welcome, it's a pleasure to work on.)

-- 
Michael Allan

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