Central Services: Difference between revisions
No edit summary |
(so Central Services includes distributing all data, from day one? that's hard to achieve) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
These are the most basic and implicit [[Consumerium Services]]. Without these basic things like running [[server software]] and adjudicating the various [[protocol requirements]] and keeping co-ordinated with the evolution of the [[healthy signal infrastructure]], everything just sort of stops working slowly. | These are the most basic and implicit [[Consumerium Services]]. Without these basic things like running [[server software]] and adjudicating the various [[protocol requirements]] and keeping co-ordinated with the evolution of the [[healthy signal infrastructure]], everything just sort of stops working slowly. | ||
A short term goal is a [[healthy buying infrastructure]] that just "works" at all, on ''any'' scale, and allows us to test [[hardware requirements]] and [[protocol requirements]] and develop more robust [[software requirements]]. | |||
Then, we would deploy a network using the new and more tested [[hardware standard]]s, and use [[self-funding]] methods to pay for '''Central Services'''. | |||
A medium term goal is [[Transparent Consumerium]] that would let many bidders and volunteers monitor activities and keep to high [[performance standard]]s. | A medium term goal is [[Transparent Consumerium]] that would let many bidders and volunteers monitor activities and keep to high [[performance standard]]s. | ||
| Line 8: | Line 12: | ||
It's usually easier to start central and go distributed slowly over time, but this requires a strong decision to do so right from the very beginning, so that major [[hardware requirements]] and [[protocol requirements]] will take the long term need into account. | It's usually easier to start central and go distributed slowly over time, but this requires a strong decision to do so right from the very beginning, so that major [[hardware requirements]] and [[protocol requirements]] will take the long term need into account. | ||
---- | |||
For [[privacy]] and to push forward a [[Consumerium protocol]], however, we want to avoid central store of [[user data]] where ever it is possible, and we want [[label data]] and [[barcode]]s as well to be pushed out as far as the [[Consumerium checker]] as fast as any of it changes. | |||
Centrally stored data is subject to all kinds of diseases and it's pretty much the primary place [[cracker]]s will target to get user data. ''The danger is that some kind of [[Consumerium Data Whorehouse]] will end up storing all the stuff that we need but don't want to admit we need, then, let anyone get it and do whatever uncontrollable things to it. Really, we want to avoid this outcome.'' | |||
Since it will be accessed only by [[server software]] probably via [[SQL]] it is important that this software be quite careful to authenticate data requests. Ideally it would log them also for further [[privacy]] protection, and perhaps in [[Transparent Consumerium]] there will be so little privacy lost in publishing these queries that they can all be made safely publicly visible. | |||
Latest revision as of 22:21, 26 November 2003
Central Services are those Consumerium maintenance and other services that are run by the Consumerium Governance Organization. These are things that the Consumerium License assumes will be provided by someone, somewhere.
These are the most basic and implicit Consumerium Services. Without these basic things like running server software and adjudicating the various protocol requirements and keeping co-ordinated with the evolution of the healthy signal infrastructure, everything just sort of stops working slowly.
A short term goal is a healthy buying infrastructure that just "works" at all, on any scale, and allows us to test hardware requirements and protocol requirements and develop more robust software requirements.
Then, we would deploy a network using the new and more tested hardware standards, and use self-funding methods to pay for Central Services.
A medium term goal is Transparent Consumerium that would let many bidders and volunteers monitor activities and keep to high performance standards.
A long term goal is Distributed Consumerium that would let this work even in developing nations and require only the Consumerium License without any active oversight or legal intervention or management to work even against the threats that we can't even believe are real that will be used against the network in places where things are very corrupt.
It's usually easier to start central and go distributed slowly over time, but this requires a strong decision to do so right from the very beginning, so that major hardware requirements and protocol requirements will take the long term need into account.
For privacy and to push forward a Consumerium protocol, however, we want to avoid central store of user data where ever it is possible, and we want label data and barcodes as well to be pushed out as far as the Consumerium checker as fast as any of it changes.
Centrally stored data is subject to all kinds of diseases and it's pretty much the primary place crackers will target to get user data. The danger is that some kind of Consumerium Data Whorehouse will end up storing all the stuff that we need but don't want to admit we need, then, let anyone get it and do whatever uncontrollable things to it. Really, we want to avoid this outcome.
Since it will be accessed only by server software probably via SQL it is important that this software be quite careful to authenticate data requests. Ideally it would log them also for further privacy protection, and perhaps in Transparent Consumerium there will be so little privacy lost in publishing these queries that they can all be made safely publicly visible.