[This notice is to be deliberately updated.]
Recently In The News
See Bruce Schneier: This essay essentially covers the topic
of our background conversations mentioned in "about". He applies
the same reasoning and even the analogy of feudalism. Askemos
does just one thing here: assuming that there is an
"evolutionary advantage" in civil societies above "state of
nature"; and apply this recipe to networked security. Sum: create
an "autonomous" thing, which can handle contracts.
State Of Documentation
At about actual 1000 statements the current documentation
contained enough statements that I felt compelled to refine on
elements beyond the need for reference up to the 1st "fixpoint" -
the principle of social contract.
For the sake of modularisation, there should be a period of
consolidation. Before continued addition of rationale about
linguistic systems - irrelevant so far - adds noise.
However some refinements (maybe a new home page) are in order
before a snapshot worth documenting.
Note that up to here, we collected only universally required
constraints and disambiguation wrt. problem domain. Details often
missing.
The next challenge is the initial contract language.
Lacking a universal language this was done by examples.
Hence forthcoming rationale is strictly neither nessesary nor
universal.
We will lift a programming language from controlling trusted
systems to write contracts controlling autonomous processes. In
doing so we shall strive simplicity, modularisation and few
dependencies to ease integration in the users preferred
environment.
Frontpage Draft Scratchpad
A list of keyword searches
Physical Heritage
IT shapes society.
Often instead of catering it as it should. Cloud service
providers become feudal lords over their customers, putting
forward business rules in uniliteral interest. Clients never know
how long a provider will exist let alone the services they became
dependant of. Legal certainty is the last -- lost -- idea.
Users are in dire need of a slightly different structure, where
avatars are autonomous and providers act like notaries; while
required, still replaceable. Otherwise no big bang changes; ease
and little training. -- And their privacy (almost forgot;-)
Virtuality as simple as "power from the wall".
Customer demands: the Impossible (as always). Safe, secure,
available, indepence and autonomy.
Most of all: simplicity of freedom of choice.
For the power grid this reduces to X Volt at Y Hertz plus the
form of the connector. X and Y are "region encoded" in the plug
for the sake of simplicity. A local different heritage; a pity in
practice but no road block. After all the nice thing about
standards is, that there are so many to choose from.
Why: devices shall work with any station near you. Any supplier
will do.
With respect to
IT
cloud's we envision a problem: One service is brought by
exactly one cloud(y something). Not only are there vastly more
parameters than voltage and frequency. Any valuable thing seen in
any one cloud vaporises in sunlight or rains down in time.
Customer wants valuables (a.k.a avatars, accounts, services)
survive change of weather at least.
Help desk: "Boss we got a problem; customer shown up with
contract in metric units!"
Some comments received… as collected…for inspiration
-
I'll definitely be reading through the Askemos abstract as it
appears to be a more simplified distributed computing model than
using complex libraries like MPI.
-
< davidsarah refreshes their memory on Byzantine agreement protocols...>
For immutable files, Tahoe-LAFS is solving a much simpler problem than
Byzantine agreement or reliable broadcast, because it only needs to
achieve agreement on the file contents for readers who already know a
capability to the file. This is why it can achieve its security properties
for immutable files with less than a 2/3 majority of honest servers.
(Well, currently there isn't adequate restriction on servers joining a
Tahoe-LAFS grid, but that will be fixed by the work on signed introductions.)
I'm writing a longer reply that will go into more detail about the case
for mutable files, but there are some papers I need to read first
(typical aspie perfectionism :-) It's interesting to consider protocols
that would provide stronger security properties for mutable files at
the expense of more costly updates.