Yes - I think I get it. Quick question is this any different form providing "vote casting" messaging API, that any implementation can post to and optionally subscribe to? <div class="gmail_quote">2009/12/4 Michael Allan <<a href="mailto:mike@zelea.com">mike@zelea.com</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I was originally saying what Friedrich says: it's premature to talk about vote pooling, and it's hardly feasible anyway. But I eventually came to agree with Thomas. It's not premature at all. There are two immediate problems (two sides of the same coin) to address: split consensus among voting engines, and irrational competition. I added brief explanations to the intro here: <div class="im"> <a href="http://t.zelea.com/wiki/User:ThomasvonderElbe_GmxDe/Vote_mirroring" target="_blank">http://t.zelea.com/wiki/User:ThomasvonderElbe_GmxDe/Vote_mirroring</a> </div><div class="im">Friedrich Lindenberg wrote: > 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. </div>None of this is properly documented yet, so it's not easy to see. But I think it's the opposite of what you say. I think autocast mirroring is both a practical solution, and also universal. On the practical side, autocasting simply doesn't raise any issues of timing and security that aren't already raised by manual casting. How could it? The autocaster is a bona fide agent, a stand-in for the user. It can do whatever the user does, only faster. Universality isn't a problem, either. The native engine retains the original vote. The other engines get a thin translation that's entirely dependent (mirror-like) on the original. So there's no loss of info. At the same time, there's no ugly standards-stew of common vote representations. Mirroring is an elegant solution compared with pooling. It's robust, too. Some kind of translation is usually going to be possible between any two voting methods (X,Y), provided you don't have to worry about the reverse translation and (crucially) the attendant loss of info. What pair (X,Y) can't we code a one-way translation (X->Y) for? For that pair, any engine using Y will be blind to the votes of engines using X. That's all, the system won't fall apart. It's robust. The autocaster is also something that a developer could start working on tomorrow. The interfaces it needs the most (vote monitoring and vote casting) won't be hard to agree, because they're pretty narrow. And once it's coded, there's no lack of alpha voting engines to test it on. The testing will be a draw for users, and the kind of thing - like David says - that can snowball to everyone's advantage. (But mirroring won't really come into its own till we have common registers. So I guess this is a good use case for the registration framework, too.) -- Michael Allan Toronto, +1 647-436-4521 <a href="http://zelea.com/" target="_blank">http://zelea.com/</a> </blockquote></div>