Will comment properly later - have been working on server infra-structure and services for a similar national / regional / one-click install set up - so this may mirror nicely! <div class="gmail_quote">On 8 February 2010 17:22, Michael Allan <<a href="mailto:mike@zelea.com">mike@zelea.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hey Thomas, Here's the proposal I mentioned. This would supercede the plan of setting up a pollserver hosting service. This is a proposal for increasing Votorola's speed of deployment. The goal is to ensure that Votorola can keep pace with the rollout of the common voter register (streetwikis and trustservers). It takes almost no effort to set up a streetwiki. So the overall register (T,S) might deploy rapidly across a wide area, creating a surge in demand for voting facilities. (T) (T) /|\ /|\ / | \ / | \ / | \ / | . / | \ / | . (S) (S) (S) (S) (S) -> deploy T = Trustserver S = Streetwiki (P) (P) (P) P = Pollwiki | | | . V = Voting engine, or | | | . Votorola pollserver | | | | (V) (V) (V) (V) FIG 1. The problem is that voting engines (V,P) cannot keep pace with deployment of the register (T,S). The problem is that, in order to keep pace, we require a new pollserver/pollwiki pair (V,P) for every streetwiki that pops into existence (fig. 1). That's not so easy. It takes a technically skilled administrator to set up a pollserver. Then the administrator probably has to do the initial work of defining electoral districts, too. It's a lot of work, up front. The proposed solution (obvious when it's layed out like this) is to copy the trustserver's trick of deployment. Each pollserver (V) now serves multiple pollwikis (here we show 3 or so, but in practice the number would be higher). (T) (T) /|\ /|\ / | \ / | \ / | \ / | . / | \ / | . (S) (S) (S) (S) (S) -> (P) (P) (P) (P) (P) \ | / \ | . \ | / \ | . \ | / \ | / \|/ \|/ (V) (V) FIG 2. Part of the solution, multiple P per V. We can then go one step further, and push the functions of Votorola's pollwiki into the common streetwiki (fig. 3). These functions include: i. District definition ii. Issue/poll definition iii. Position drafting The first two are common information anyway, so it makes sense to put them in the streetwiki. But the third also fits, because it gets tucked away in the user's own subpages. Presumeably only Votorola users will be creating position pages. No problem. (T) (T) /|\ /|\ / | \ / | \ / | \ / | . / | \ / | . (S) (S) (S) (S) (S) -> \ | / \ | . \ | / \ | . \ | / \ | / \|/ \|/ (V) (V) FIG 3. The rest of the solution, P merged into S. As each new streetwiki S comes online, it is immediately served by an existing pollserver V. In less than a day, an ordinary (non-tech) user can: 1. Set up a new streetwiki 2. Get a few people registered 3. Extend trust and get them authenticated 4. Open a local issue (electoral or normative) 5. Vote using the engine of choice (only Votorola shown here) 6. See the results mirrored across all engines Beyond the local level, there is a second tier composed of "statewikis" (A). Unlike streetwikis, statewikis do not have a registration function. Rather, they serve mainly for navigating among related streetwikis. For example, each A might serve a different German state. Each would provide maps to show the location of the towns and regions under its jurisdiction, with links to their streetwikis; or an invitation to set one up, if there is none (as you suggested earlier). (S) (S) (S) (S) (S) \ | / \ | . \ | / \ | . \ | \ | / | / | \ | / \|/ \|/ \|/ \|/ \|/ S = Streetwiki (V) (V) (V) (V) (V) A = Statewiki (A) (A) (A) (A) (A) -> deploy \ | / \ | . \ | / \ | . \ | / \ | / \|/ \|/ (V) (V) FIG 4. Beyond the local level (top), the functions of P are merged into common statewikis (A). So the statewiki is where (ii) statewide issues are defined, and where (iii) users keep their position drafts for the statewide polls. An ordinary user can set up a statewiki if one does not already exist, and start voting that day. (And so on, for the national and global tiers.) Like S, each A is seamlessly forkable. We'd still need to do some work in Votorola. But it could probably be done in week-long chunks, as needed. There should be no lengthy delays up front. What do you think? (Others too? Please comment if you have time.) I haven't thought it all through. I may be missing something. -- Michael Allan Toronto, +1 647-436-4521 <a href="http://zelea.com/" target="_blank">http://zelea.com/</a> -- You received this message because you are subscribed to the Google Groups "Votorola" group. To post to this group, send an email to <a href="mailto:votorola@googlegroups.com">votorola@googlegroups.com</a>. To unsubscribe from this group, send email to <a href="mailto:votorola%2Bunsubscribe@googlegroups.com">votorola+unsubscribe@googlegroups.com</a>. For more options, visit this group at <a href="http://groups.google.com/group/votorola?hl=en-GB" target="_blank">http://groups.google.com/group/votorola?hl=en-GB</a>. </blockquote></div> -- You received this message because you are subscribed to the Google Groups "Votorola" group. To post to this group, send an email to votorola@googlegroups.com. To unsubscribe from this group, send email to votorola+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/votorola?hl=en-GB.