[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.