BALL

This page has three main sections. (Note that the listings could be empty.) moreā€¦ Tip: Remember the back-button! And don't click the number on the left.

  1. The first item displays a term, URL, text or picture.
  2. Followed by a (still unordered) listing of statements about this subject. (for details follow ">"-link)
  3. Separated by a horizontal rule a "reverse" listing of statements referring to this item in object position.

Replication Protocol

The memo explains (TBD: will explain and move into it's own page) the conditions governing (passive) data replication in Askemos/BALL.

Publications vs. Private Data

Two base cases are distinguished. Publications are immutable objects (places) which are publicly readable. Everything else is considered private.

Publications are replicated to any peer asking for it without restrictions. Peers may (do) cache the information and will serve future requests locally. Private data is only ever replicated to those peers listed as replicates.

Publicly Readable

There is a unique user agent "public" at each peer (TBD: to be detailed: somewhat mapping to the public key of the peer). If a request having the capabilities of the anon public user succeeds the object is considered publicly readable.

Immutable

To determine whether or not a place is immutable the type contract is analyzed. A contract encodes an immutable constant (in BALL at this time) if the source code is equivalent to calling the well known procedure called public-place. (Though notational variations are allowed, e.g., (public-place) and public-place() are equivalent, comments are ignored etc.) Future versions may allow more criteria here.

Verification

For immutable objects a receiving peer SHOULD check that the OID matches the content of the meta data record and discard mismatches.

Active agents may or may not pass the OID check depending on their type. Furthermore only Active agents replicated locally can be verified at the replication layer.

Commissioned notaries check their local state being current by asking the replicates set for their version number and checksum of the latest state. Peers have an outdated version if more than half of the replicates have a more recent one. The peer in lag will replicate the current state from any member of the majority and check that the replicated value matches the checksum from the majority-discovery stage before.

do we need this link?
1890 see also > Capability