Meta-Tool

[David Bovill]

That's great Thomas! And yes that is exactly what i observed in the early
days - it was tragically comical how difficult it was to get different
groups to co-operate.

I'd point again to the Jabber / XMPP process of establishing a messaging
standard, as the sort of thing that is needed to distinguish between
implementations and protocol. And yes of course there are better ways of
establishing a common standard (once we have proper voting tools etc), but
it would be nice not to get stuck in another boot strapping catch 22, so the
meeting you mention sounds like a good start.

Not clear what the registration-facility is about? What is the realtion to
this and oAuth openID? Are you including geographic location, and/or real
world political voting constituencies, in addition to pseudo-anonymous
authentication?

2009/12/3 Thomas von der Elbe <ThomasvonderElbe at gmx.de>

> In the field of e-democracy the geatest concern for me was the
> possibility of many tools competing with each other for users. This way
> the whole just emerging movement would have been split and weakened.
> Thats why I´m very happy, that here in Germany 4-5 different projects
> agreed on sharing the same registration-facility. Last weekend we met at
> the invitation of Liquid-Democracy-e.V. The other participating projects
> were Adhocracy, LiquidFeedback and Crabgrass/Echologic.
>
> Now with a shared registration the different engines can still compete
> for the best solution, but not at the cost of the whole e-dem-movement.
> Also many additional possibilities arise.
> The most exciting for me is something like a portal for e-dem-users. For
> the user it would:
>
> 1. be the entrance to the e-dem-world (registration)
> 2. give an overview over all the issues being discussed/voted across all
> the different engines
> 3. show all the engines, in which a particular issues is being
> discussed/voted
> 4. show the current proposals and voting results in that poll (for each
> engine and also totalized (multiple votes revised))
> 5. provide a delegation tool for abstract vote-delegation (e.g. delegate
> all tax-related issues to Mrs.X and all enviromental issues to Mr.Y)
> 6. be the entrance to a particular engine of choice (for single users
> and for delegates (in case the particular engine supports delegation))
>
> It would be like a network of engines connected through this meta-tool.
> But they could also connect among each other through a
> vote-mirroring-facility. Through auto-casting all the votes from one
> engine could be mirrored in all the other engines. So that the user of
> each engine sees where else the same issue is being discussed/voted and
> with what results.
>
> Mike drew two pictures of the auto-casting-tool for me:
> http://t.zelea.com/wiki/User:ThomasvonderElbe_GmxDe/Vote_mirroring
>
> Further possibilities that come to mind are things like: delegates of
> one engine (and not just abstract delegates) voting in another engine.
> They would be like bridges between two engines. This of course depends
> very much on the specifics of the voting procedures. But some engines
> look compatible to Votorola in at least one direction.
>
> I find this all very exciting. :-)
>
> Greetings,
> Thomas



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.reluk.ca/list/votorola/attachments/20091203/67249036/attachment-0007.html>