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. <div class="gmail_quote">2009/12/3 Friedrich Lindenberg <<a href="mailto:friedrich@pudo.org" target="_blank">friedrich@pudo.org</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 ;-) <div> > 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. </div>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 <<a href="mailto:friedrich@pudo.org" target="_blank">friedrich@pudo.org</a>> <div><div></div><div> -- You received this message because you are subscribed to the Google Groups "Votorola" group. To post to this group, send email to <a href="mailto:votorola@googlegroups.com" target="_blank">votorola@googlegroups.com</a>. To unsubscribe from this group, send email to <a href="mailto:votorola%2Bunsubscribe@googlegroups.com" target="_blank">votorola+unsubscribe@googlegroups.com</a>. For more options, visit this group at <a href="http://groups.google.com/group/votorola?hl=en" target="_blank">http://groups.google.com/group/votorola?hl=en</a>. </div></div></blockquote></div>