Meta-Tool

[David Bovill]

Hi Friedrich (spoken like a true developer :) - a quick question (aside from
what LF stands for :)

Have you followed the development of Jabber / XMPP from the early days -
what do you think accounts for their relative success in terms of defining
an agreed extensible protocol, while steadily building working
implementations? What is different with regard to the task of creating an LD
implementation / server in terms of scope and scale than that of
implementing the JaberD server?

No one wants to write specifications in advance of knowing what to build, in
fact not many people want to write specification ever (and thank god for
that given that 80% of the features never reach the final product). However
I feel pretty stongly that there is a genuine and highly advantageous ground
that we would all be able to benefit from if this were done properly, ie one
that does not hinder a developer, nor stall the process in painful
kin-arguments over the finer details of proxy based algorythms, but does
enable both a common recognised debating platform, marketing platform for
Liquid Democracy, and a minimal extensible protocol / API and real world
"data sets" which ALL developers could benefit from.

Hmmm... maybe not so "quick"....

What I'd argue for, or at least clear a bit of space for a discussion
around, until the details are clearer to me (I am around 5 years out of date
with regard to lloking at the details of the implementations / projects you
are refering to), is that is should be possible to specify a minimal API in
which for instance the core delegation activities (perhaps a standardised
representation of the graph?), and associated media content (referenced by
url) are accesible by different LD implementations, if only to allow
importing the data for a given community.

This would allow any given web application to import the data (using
standardised rest calls), and add it's own functionality. There would be no
need for individual implementations to agree on the results or even offer
the same functionality, but it would allow them to share use cases and test
data with which to base the development of their own applications. It is my
experience that one of the big impediments to the development of robust
applications has been the lack of real community provided test data, and the
over-abundance of half worked out software searching for users. I'd suggest
that pooling users / test data would help all developers?

More ambitious would be to add the following. When I give talks about Liquid
Democracy I emphasise the "fluid" aspect, and the idea that there is no one
particular mechanism. In fact the issue here and the value of the term is
that it allows us to conceive of a virtually infinite spectrum of decision
making techniques (algorithms and software implementations), some fit for
one purpose, while others more suited to another. What this "rhetoric"
translates to in terms of implementation is that we could add to the shared
user data repository thing, the idea of different implementations returning
different "results" to common repository. This would then allow perhaps a
showcase opportunity in which a user or particular group could select a
particular LD implemenation, and then see the result expressed in some
agreed format (something simple to implement like an html embed, or
standardised XML perhaps). If a viewer wanted to explore the process in
detail she would be taken off to the implementers web site.

I'd agree with Martin that starting with a simple OpenID / oAuth requirement
is a good start, and would at the least allow more users to experiment with
less registration hassle between implementations.

I also agree with the "vision thing" but with certain reservations. It can
be good for teamwork, and it is good to build a recognizable front for
newcommers to the idea (in marketing parlance a brand) - but it can also be
a source for internal ego based squabbles between different implementations
/ theories. For that reason I think it is good practice to keep the vision
thing general, and emphasize the difference to real-existing parliamentary
democracy, and the "aims" of the project rather than explicitly associate
this with a software road map, or theoretically detailed implementation.


2009/12/3 Friedrich Lindenberg <friedrich at pudo.org>

> Hm, I feel a bit like you're trying to make this argument by
> repetition, but maybe that's just the sheer number of lists we're both
> on ;-)
>
> > 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.
>
> First off, we're nowhere near a common registration protocol. While I
> very much like Mike's attempt to define a common vocabulary and a set
> of requirements, this actually just shows how much more work needs to
> be done here (and, I feel, that we shouldn't over-engineer this in a
> first iteration). Judging from yesterday's minutes of the Berlin LD
> squad, they seem to have put any OpenID work on ice pending the
> evaluation of LF in Berlin. This essentially means that we'll not have
> an concrete use case for registration in a little while. Setback.
>
>
> As for your proposal for creating a Grand Unifying Platform, I think
> you should really start to consider the difficulties involved in this.
> Let me again state that I do appreciate the idea, but I don't want to
> build the framework before knowing what kind of LD does actually work.
> At this stage, none of the platforms involved have yet gathered and
> maintained any social momentum.
>
> It's like we're developing three very large carrier airplanes, each
> built for a slightly different purpose. One of them is made for
> carrying freight, another for transporting people and the third is
> actually a helicopter in disguise. None of our planes have actually
> left the ground yet and we don't have the models to predict whether
> any of them will. No-one would suggest that this is a very good moment
> to standardize propeller sizes. We don't know which size works.
>
> Of course we'll have to talk about interoperability in the long term,
> but right now there is just no basis for a debate based on empirical
> experience. Let me take your vote mirroring proposal as an example:
> you don't discuss different kinds of voting systems, preference voting
> v. binary voting, security, synchronization and timing issues, etc.
> etc. Essentially this is a proposal for the replication of Votorola
> pollserver state in a controlled environment, but that's it.
>
> You'll probably disagree with all of what I've said because I describe
> LD as a tool (actually, an airplane, sorry for that), while you
> consider it a platform. But I feel that strategically we're better off
> introducing LD into small groups and organizations to gather the
> experience we need to refine our implemenations. These groups could be
> NGOs, protest movements, open source projects etc.
>
> Asking for the LD tools to synchronize all those internal platforms is
> actually asking for LD to synchronize all those organizations (i.e.
> civil society). That's a legitimate goal, but it's something that
> people with more resources and better strategies than us have failed
> at repeatedly. There is a possibility LD might overcome this, but the
> main premise of such a scenario is that LD has been running
> successfully within some of the involved groups for a while. There is
> no way that (a) we're going to develop a functioning protocol
> framework for a complex LD from scratch without heavy experimentation
> with different implementations beforehand and (b) that any serious
> political group would adopt such a software just based on its
> theoretical merits.
>
> This is all just meant to explain why I think we should focus on a
> shared discussion on individual technical issues, but why I won't
> invest any resources into a Grand Unified Platform while I don't see
> an actual use case (i.e. a likely adoption by many groups).
>
> Cheers, Friedrich
>
> --
> Friedrich Lindenberg <friedrich at pudo.org>
>


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