librelist archives

« back to archive

Trustworthy Contract Handling - Comparison Of Approaches

Trustworthy Contract Handling - Comparison Of Approaches

From:
Jörg F. Wittenberger
Date:
2014-07-29 @ 07:57
Hi all,

I'm gathering infos for a comparison of approaches towards trustworthy, 
tamper-proofed autonomous systems.

So far I have in alphabetic order: Askemos/Wallet, Bitcoin, Ethereum, 
OpenTransactions, Ricardian Contracts.

What about: Drogulus, does it do contracts? Which did I miss?

Should I compare other properties too?

Note that info might be wrong or I'm missing things.  Please correct me. 
Thanks for you comments and suggestions.
http://ball.askemos.org/?_v=wiki&_id=1786

/Jörg

PS: If you feel like testing the payment system demo for yourself: send 
me a note and I send you a wallet.  But beware: this is a demo: I don't 
want to automate the process and the test network will only stand so 
much traffic.  Hence I'll hand out only two handful or so.
Find the "Stone Age Accounting" demo here: 
http://ball.askemos.org/?_v=wiki&_id=1728

Re: Trustworthy Contract Handling - Comparison Of Approaches

From:
Jörg F. Wittenberger
Date:
2014-08-03 @ 12:56
Hi all,

sorry for following up my own post.  (So far I got some responses, 
though not via the list.)

I gather that this might be interesting to the list too:

Am 29.07.2014 09:57, schrieb "Jörg F. Wittenberger":
> Hi all,
>
> I'm gathering infos for a comparison of approaches towards 
> trustworthy, tamper-proofed autonomous systems.
>
> So far I have in alphabetic order: Askemos/Wallet, Bitcoin, Ethereum, 
> OpenTransactions, Ricardian Contracts.
>
> What about: Drogulus, does it do contracts? Which did I miss?

Nicholas: does Drogulus have an idea about contracts?  Should I include 
it in the comparison or does it not qualify?  I'm not sure. See here:
http://ball.askemos.org/?_v=wiki&_id=1786

Not related to Drogulus but to trustworthy (a.k.a. trustless) contract 
handling, one more note.

I ran into codius.  That's interesting too; see the white paper:

https://github.com/codius/codius/wiki/Smart-Oracles:-A-Simple,-Powerful-Approach-to-Smart-Contracts#multiple-untrusted-host-model

 > for example, one could use a 7-of-10 scheme that allows for up to 
three oracles to behave maliciously, be offline, or even be hacked 
without affecting the execution of the contract.

This is the same concept as Askemos deploys.  However: when written like 
this, one might assume the 7 was a number one could choose arbitrarily.  
That's an unfortunate wording.  One could assume the 6-of-10 could work 
as well.

However see Leslie Lamport in the1980 paper
http://research.microsoft.com/en-us/um/people/lamport/pubs/reaching.pdf
byzantine fault tolerance requires *at least* seven out of ten votes.  
Maybe it's worth noting to avoid confusion.

Best Regards

/Jörg

Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches

From:
Nicholas H.Tollervey
Date:
2014-08-06 @ 11:58
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/08/14 13:56, Jörg F. Wittenberger wrote:
> Nicholas: does Drogulus have an idea about contracts?  Should I include 
> it in the comparison or does it not qualify?  I'm not sure. See here:
> http://ball.askemos.org/?_v=wiki&_id=1786
> 
> Not related to Drogulus but to trustworthy (a.k.a. trustless) contract 
> handling, one more note.
> 

Hi,

Sorry, I missed this in the deluge of email that is my inbox. ;-)

Items stored in the drogulus are designed to stand on their own and be
self-verifiable through cryptographic signing.

An item stored in the DHT is a collection of named fields and associated
values (it's a JSON object):

* value - the actual value to store.
* timestamp - a UNIX timestamp representing when the creator of the item
thinks the item was created (so it's easy to work out the latest version
of an item given two candidates).
* expires - a UNIX timestamp beyond which the creator of the item would
like the item to expire, be ignored and deleted in remote nodes.
* name - a meaningful name given by the creator for the key.
* created_with - the version of the drogulus the creator used to
generate the item.
* public_key - the creator's public key.
* key - the SHA-512 value of the compound key (based upon the public_key
and name fields) used as the actual key on the distributed hash table.
* signature - a cryptographic signature generated using the creator's
private key with the fields described above.

The public_key field is used to validate the signature value. If this is
OK then the compound SHA-512 key is checked using the obviously valid
public_key and name fields.

This ensures both the provenance of the data and that it hasn't been
tampered with. Any items that don't pass the cryptographic checks are
ignored and nodes that propagate them are punished by being blocked. It
also confirms that the generated SHA-512 key for the item is correct
given the public_key and meaningful name ensuring no other entity may
set items with this unique key (assuming no key collision vulnerability
in the hashing function).

Does this make sense..?

Happy to answer questions and please remember, this is more an
experiment in code. I'm currently working on the drogulus on the
"rewrite" branch here:

https://github.com/ntoll/drogulus/tree/rewrite

Getting quite close to something releasable. ;-)

All the best,

Nicholas.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT4hhaAAoJEP0qBPaYQbb6udsIAKNGDL3ufCqyB2qyKLDfJ4WX
/+Zosq3ulUQTSjbvsSEONyd+QjzE2PDB24uMniq7Vd3BZYrS+n2DeMWKDKSlzc8Y
o7NyI7hvtkgie/K+1AoxzpdLOSg1MKu2pmG3dg5jxwclEO4DvXn5b7Ocl+NEfiCs
5+5lNI3AEP9ibdbRYOw6XTFsE0vIVAYOMkjsIw+XvSsQaHf0fJDorrqN0qdPC0nU
XG01A0GwcydPp6bgqiMbp2hm9ZbKX/qsNI22+ljVphHCAoIzyiF5FMhkgEqDBkWv
Ohk6HefPeDcpALde2nrgQNwhXpdXzh3q6OdLlu6JpkXQK4QF6C5XMS6s3WofMbQ=
=hZRG
-----END PGP SIGNATURE-----

Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches

From:
Jörg F. Wittenberger
Date:
2014-08-07 @ 09:31
Am 06.08.2014 13:58, schrieb Nicholas H.Tollervey:
>
> Items stored in the drogulus are designed to stand on their own and be
> self-verifiable through cryptographic signing.

Thanks for your feedback.

I see quite some interesting things in Drogulus.

However I'm "sort of" skeptic when I read "crypto signing".  This term 
is too generic and too often implies secret key crypto. However an 
important part of a signature is in these schemes hidden in the process: 
as a proof of integrity, we are interested in a hash over the object's 
content.  This proof should hold even if the secret key was lost or 
published.

>
> An item stored in the DHT is a collection of named fields and associated
> values (it's a JSON object):
>
> * value - the actual value to store.
> * timestamp - a UNIX timestamp representing when the creator of the item
> thinks the item was created (so it's easy to work out the latest version
> of an item given two candidates).
> * expires - a UNIX timestamp beyond which the creator of the item would
> like the item to expire, be ignored and deleted in remote nodes.
> * name - a meaningful name given by the creator for the key.
> * created_with - the version of the drogulus the creator used to
> generate the item.
> * public_key - the creator's public key.
> * key - the SHA-512 value of the compound key (based upon the public_key
> and name fields) used as the actual key on the distributed hash table.
> * signature - a cryptographic signature generated using the creator's
> private key with the fields described above.

When it comes to contracts, one might find it a good idea to define a 
slightly higher level hash function: extract (or attach) relevant 
information to assert provenance: creator, witness, time etc. and hash 
these together with the hash of the actual value.

Now if you take this hash as canonical identifier for the object, you 
can always proof it's integrity.  See also:
http://www.iang.org/papers/ricardian_contract.html
for yet another explanation of the same concept.

Question: Am I correct to understand that the "key" field serves this 
purpose?

I'm a bit concerned about the inclusion of some public_key here. This 
identifier should IMHO only cover non-repudiable, public (or 
semi-public) meta data.  No private data an nothing one would ever want 
to change.

> The public_key field is used to validate the signature value. If this is
> OK then the compound SHA-512 key is checked using the obviously valid
> public_key and name fields.
>
> This ensures both the provenance of the data and that it hasn't been
> tampered with. Any items that don't pass the cryptographic checks are
> ignored and nodes that propagate them are punished by being blocked. It
> also confirms that the generated SHA-512 key for the item is correct
> given the public_key and meaningful name ensuring no other entity may
> set items with this unique key (assuming no key collision vulnerability
> in the hashing function).
>
> Does this make sense..?

Yes, quite a lot.

> Happy to answer questions and please remember, this is more an
> experiment in code.

I fully understand that.  See: in about 2000 I started coding around 
similar ideas.  As the system majored, we ran into various additional 
ideas.  Maybe some are interesting or inspiration:

Once we have the DHT, what do we do with it?  I'd like it to handle my 
conversation and business.  Publications, private messages, 
archive+backup, calendar, notes etc.

So I need an environment where I see agents (be them accounts 
representing human users or automated, autonomous processes) 
communicating via asynchronous, unreliable, unidirectional messages.  
That's how we observe human interaction in writing. Humans or juristic 
persons sending letters, registered mail etc.

Side note: Tuns out documents like contracts (which is what "business" 
boils down into) could seen as a finalized subclass of agents which just 
don't change state ever.  However in practice a fuse mounted directory 
at my desktop is just yet another such agent, certainly changing state.

Next I need a dispute (or debug) mode.  This must be deadly simple: 
"pull the network plug".

At this point I still want to be sure I have all *my* data and can 
access it.  (Sorry for the complication wrt. DHT design.  ;-)

Now we know that I have one copy of all data I *really* care about which 
I can physically secure.

At this point we can ask how we may update automated agents. Sometimes 
they might just have a single owner, but often control is to be 
purposefully split.  At this point the GET/PUT semantics are no longer 
enough.  We need some kind of custom, version control alike check in 
script to be run to verify that the request is permitted and complete 
for this object. It looks like a good idea to have a type property in 
the agent object pointing to another (signed) object which holds the 
script code and important: human readable terms and conditions.  The 
other object would be the contract governing the agents actions on 
incoming requests.  No script object found: either no updates or locate 
script in the object itself.

Now we need "trust but verify": since we must not allow any single human 
to control the agent, we can not allow a single computer to compute the 
update and then somehow copy the new state to other peers.  After all 
the origin peer might be a traitor.  We need autonomy from individual 
intent for these agents.  Therefore we have several peers (notaries) 
commissioned to backup the process and verify proposed updates.  Instead 
of blindingly accept any kind of update, those accept an update request 
and transform it into the actual update (or the script may reject the 
update for application defined reasons. So the script is run in a 
sandbox at each notary.)

Let's care for a moment about privacy.  Crypto always has a chance to 
break for many reasons.  And crypto is in the way of autonomous 
automated agents and often in the way to the user too.  Crypto relying 
on secret keys is great on the wire for data in transit. For data at 
rest, it's a risk increasing over time.  Instead we ask: which peers do 
we commission to such an agent?  This set should really be controlled by 
the users.  (I.e., the update policy script *must* be able to deny 
changes.)  This is a trust decision wrt. the person administrating the 
peer and the peer hardware and maybe more.  Nothing technological means 
can judge; it's a judgment about those very means among more.  Ergo: 
publications and messages may leave the commissioned set, private data 
will never.

Eventually I wonder how much effort it would be to maintain those expire 
times.  I don't want to do that manually.  Maybe there could be an 
automated garbage collector?  Establish a link structure from your user 
account and everything not reachable from any local user may be removed 
on this peer.

For the script language: it should be first and foremost a "hashbang" 
type of a language: simple and often only used to start the real 
interpreter for the contract script at hand.  However there is nothing 
bad about having a powerful language to be started that way.  We had 
about ten developers of varying experience (from bachelors to full time 
contracted CS masters) in a working environment with close feedback test 
and develop atop of our prototype for several years while we where 
working on the underlying replication engine and feature.  Too many 
features that is, see "fuse" before.  In this time we grew quite a 
flexible language BAIL: a mixture of XSLT, a python-style syntax (a.k.a. 
"sweet syntax"), a pure functional Scheme subset and SQLite.  Very funny 
to work with, because each object has it's private table space - zero DB 
administration.  However this language is certainly not the point. The 
CoreAPI to control the DHT entries is much more.  It's only seven 
required elements ad eight more to make it practical.
http://askemos.org/index.html?_v=search&_id=1728 (the documentation is a 
little terse ;-)

Do those ideas make sense to you?

Best

/Jörg

PS: Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches

From:
Jörg F. Wittenberger
Date:
2014-08-07 @ 10:00
Am 07.08.2014 11:31, schrieb Jörg F. Wittenberger:
> BAIL: a mixture of XSLT, a python-style syntax (a.k.a. "sweet 
> syntax"), a pure functional Scheme subset and SQLite. Very funny to 
> work with, because each object has it's private table space - zero DB 
> administration. However this language is certainly not the point.

Little off-topic: also funny is BAIL's take on parallelism.  Tuns out 
that is was a highly common pattern to read objects from via identifiers 
returned by SQL queries and alike sources.  This often requires high 
latency network traffic.  Therefore xslt:for-each and the alike 
xsql:for-each evaluate their template for all selected values in 
parallel. xsl:variable do syncing.  The application programmer is never 
bothered.

/Jörg

Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches

From:
Nicholas H.Tollervey
Date:
2014-08-15 @ 16:46
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 07/08/14 10:31, Jörg F. Wittenberger wrote:
> Am 06.08.2014 13:58, schrieb Nicholas H.Tollervey:
>> 
>> Items stored in the drogulus are designed to stand on their own
>> and be self-verifiable through cryptographic signing.
> 
> Thanks for your feedback.
> 
> I see quite some interesting things in Drogulus.
> 
> However I'm "sort of" skeptic when I read "crypto signing".  This
> term is too generic and too often implies secret key crypto.
> However an important part of a signature is in these schemes hidden
> in the process: as a proof of integrity, we are interested in a
> hash over the object's content.  This proof should hold even if the
> secret key was lost or published.
> 

The drogulus uses public key cryptography (RSA) for signing digital
assets.

>> 
>> An item stored in the DHT is a collection of named fields and
>> associated values (it's a JSON object):
>> 
>> * value - the actual value to store. * timestamp - a UNIX
>> timestamp representing when the creator of the item thinks the
>> item was created (so it's easy to work out the latest version of
>> an item given two candidates). * expires - a UNIX timestamp
>> beyond which the creator of the item would like the item to
>> expire, be ignored and deleted in remote nodes. * name - a
>> meaningful name given by the creator for the key. * created_with
>> - the version of the drogulus the creator used to generate the
>> item. * public_key - the creator's public key. * key - the
>> SHA-512 value of the compound key (based upon the public_key and
>> name fields) used as the actual key on the distributed hash
>> table. * signature - a cryptographic signature generated using
>> the creator's private key with the fields described above.
> 
> When it comes to contracts, one might find it a good idea to define
> a slightly higher level hash function: extract (or attach) relevant
>  information to assert provenance: creator, witness, time etc. and
> hash these together with the hash of the actual value.
> 

So the creator (via their public key) and time of creation are all
constituent in creating the hash.

> Now if you take this hash as canonical identifier for the object,
> you can always proof it's integrity.  See also: 
> http://www.iang.org/papers/ricardian_contract.html for yet another
> explanation of the same concept.
> 

Yes, that is correct.

> Question: Am I correct to understand that the "key" field serves
> this purpose?
> 

It is, indeed a unique identifier for the item.

> I'm a bit concerned about the inclusion of some public_key here.
> This identifier should IMHO only cover non-repudiable, public (or 
> semi-public) meta data.  No private data an nothing one would ever
> want to change.
> 

I'm not sure I understand you completely. The public key is required
in order for third parties to validate the signature (created with the
associated private key).

>> The public_key field is used to validate the signature value. If
>> this is OK then the compound SHA-512 key is checked using the
>> obviously valid public_key and name fields.
>> 
>> This ensures both the provenance of the data and that it hasn't
>> been tampered with. Any items that don't pass the cryptographic
>> checks are ignored and nodes that propagate them are punished by
>> being blocked. It also confirms that the generated SHA-512 key
>> for the item is correct given the public_key and meaningful name
>> ensuring no other entity may set items with this unique key
>> (assuming no key collision vulnerability in the hashing
>> function).
>> 
>> Does this make sense..?
> 
> Yes, quite a lot.
> 
>> Happy to answer questions and please remember, this is more an 
>> experiment in code.
> 
> I fully understand that.  See: in about 2000 I started coding
> around similar ideas.  As the system majored, we ran into various
> additional ideas.  Maybe some are interesting or inspiration:
> 
> Once we have the DHT, what do we do with it?  I'd like it to handle
> my conversation and business.  Publications, private messages, 
> archive+backup, calendar, notes etc.
> 

Quite... the drogulus is supposed to be application agnostic.

> So I need an environment where I see agents (be them accounts 
> representing human users or automated, autonomous processes) 
> communicating via asynchronous, unreliable, unidirectional
> messages. That's how we observe human interaction in writing.
> Humans or juristic persons sending letters, registered mail etc.
> 

Again, quite. Actually, it's not just humans - I've been reading quite
a bit of literature on insect interactions, communication and
behaviour. A good overview and a book I particularly enjoyed was
Deborah Gordon's "Ant Encounters - Interaction Networks and Colony
Behaviour".

> Side note: Tuns out documents like contracts (which is what
> "business" boils down into) could seen as a finalized subclass of
> agents which just don't change state ever.  However in practice a
> fuse mounted directory at my desktop is just yet another such
> agent, certainly changing state.
> 

Hah... a trivial distributed "Dropbox" clone built with fuse is one of
my target "quick example" applications (a la "create a blog" for web
frameworks and "create a todo list" for Javascript frameworks).

OK... I'm going to call a time-out. I've read the following but won't
comment simply because I'm about to leave to spend some time on a
remote Scottish island without internet (but I wanted to reply before
I left the relatively connected location of the mainland - I'm playing
email catch-up).

I'll re-read what follows (which upon first reading is very
interesting) and reply in full when I'm back on dry land in about a
week's time. Many apologies, but I'm a sufferer of the intractable
too-much-to-do-and-not-enough-time-to-do-it-in problem.

:-/

N.

> Next I need a dispute (or debug) mode.  This must be deadly simple:
>  "pull the network plug".
> 
> At this point I still want to be sure I have all *my* data and can
>  access it.  (Sorry for the complication wrt. DHT design.  ;-)
> 
> Now we know that I have one copy of all data I *really* care about
> which I can physically secure.
> 
> At this point we can ask how we may update automated agents.
> Sometimes they might just have a single owner, but often control is
> to be purposefully split.  At this point the GET/PUT semantics are
> no longer enough.  We need some kind of custom, version control
> alike check in script to be run to verify that the request is
> permitted and complete for this object. It looks like a good idea
> to have a type property in the agent object pointing to another
> (signed) object which holds the script code and important: human
> readable terms and conditions.  The other object would be the
> contract governing the agents actions on incoming requests.  No
> script object found: either no updates or locate script in the
> object itself.
> 
> Now we need "trust but verify": since we must not allow any single
> human to control the agent, we can not allow a single computer to
> compute the update and then somehow copy the new state to other
> peers.  After all the origin peer might be a traitor.  We need
> autonomy from individual intent for these agents.  Therefore we
> have several peers (notaries) commissioned to backup the process
> and verify proposed updates.  Instead of blindingly accept any kind
> of update, those accept an update request and transform it into the
> actual update (or the script may reject the update for application
> defined reasons. So the script is run in a sandbox at each
> notary.)
> 
> Let's care for a moment about privacy.  Crypto always has a chance
> to break for many reasons.  And crypto is in the way of autonomous
>  automated agents and often in the way to the user too.  Crypto
> relying on secret keys is great on the wire for data in transit.
> For data at rest, it's a risk increasing over time.  Instead we
> ask: which peers do we commission to such an agent?  This set
> should really be controlled by the users.  (I.e., the update policy
> script *must* be able to deny changes.)  This is a trust decision
> wrt. the person administrating the peer and the peer hardware and
> maybe more.  Nothing technological means can judge; it's a judgment
> about those very means among more.  Ergo: publications and messages
> may leave the commissioned set, private data will never.
> 
> Eventually I wonder how much effort it would be to maintain those
> expire times.  I don't want to do that manually.  Maybe there could
> be an automated garbage collector?  Establish a link structure from
> your user account and everything not reachable from any local user
> may be removed on this peer.
> 
> For the script language: it should be first and foremost a
> "hashbang" type of a language: simple and often only used to start
> the real interpreter for the contract script at hand.  However
> there is nothing bad about having a powerful language to be started
> that way.  We had about ten developers of varying experience (from
> bachelors to full time contracted CS masters) in a working
> environment with close feedback test and develop atop of our
> prototype for several years while we where working on the
> underlying replication engine and feature.  Too many features that
> is, see "fuse" before.  In this time we grew quite a flexible
> language BAIL: a mixture of XSLT, a python-style syntax (a.k.a. 
> "sweet syntax"), a pure functional Scheme subset and SQLite.  Very
> funny to work with, because each object has it's private table
> space - zero DB administration.  However this language is certainly
> not the point. The CoreAPI to control the DHT entries is much more.
> It's only seven required elements ad eight more to make it
> practical. http://askemos.org/index.html?_v=search&_id=1728 (the
> documentation is a little terse ;-)
> 
> Do those ideas make sense to you?
> 
> Best
> 
> /Jörg
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJT7jltAAoJEP0qBPaYQbb6jBQIAKeQokUP+dICTeW2iIp8w7T/
y+FC5/KGAJeUHm12QI6GIgbqn8yky676RZUWuSv4HQo0nf+jhr/+ogwx3dJnYzBB
MV/kAqGqfU9/JT8jvVNtrBrpCP3CDkR0VhhpcRQuhNV2ZCPl1jsZJl3r3/XuubKu
KihT0nEpgHeqH32kq4ZoYG4TqMMLT0QUuxW3nvm6b1Qwv/DdTqstlfldxQrGIchh
Ld5AOv88LjfuqEQt3gew+hv+oNe1n4UUXkDEzF89DuNLIOpbjhlbpzAZfZLswYWO
Jv5KPTe17fuBR+eqINEcbfZEWyg/yJGnRp5EshYV04+oOdAVq/VRyrqz56VbcXs=
=pYRE
-----END PGP SIGNATURE-----

Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches

From:
Jörg F. Wittenberger
Date:
2014-08-15 @ 17:21
Am 15.08.2014 18:46, schrieb Nicholas H.Tollervey:
>> Question: Am I correct to understand that the "key" field serves
>> this purpose?
>>
> It is, indeed a unique identifier for the item.

Great!

>> I'm a bit concerned about the inclusion of some public_key here.
>> This identifier should IMHO only cover non-repudiable, public (or
>> semi-public) meta data.  No private data an nothing one would ever
>> want to change.
>>
> I'm not sure I understand you completely. The public key is required
> in order for third parties to validate the signature (created with the
> associated private key).

May I ask: why does it have to be that way?

Experience teaches that public/secret key schemes need to be change over 
time.  We call them "circumstantial" for the dependency on a secret 
being kept secret.

It would be IMHO much better if the proof would be possible even without 
relying on PKI limited by such secrets.
Most signature schemes actually sign a hash of the underlying info 
anyway.  Why not expose it as an independent proof?

> Quite... the drogulus is supposed to be application agnostic. 

(as is Askemos  ;-)

>> So I need an environment where I see agents (be them accounts
>> representing human users or automated, autonomous processes)
>> communicating via asynchronous, unreliable, unidirectional
>> messages. That's how we observe human interaction in writing.
>> Humans or juristic persons sending letters, registered mail etc.
>>
> Again, quite. Actually, it's not just humans - I've been reading quite
> a bit of literature on insect interactions, communication and
> behaviour. A good overview and a book I particularly enjoyed was
> Deborah Gordon's "Ant Encounters - Interaction Networks and Colony
> Behaviour".

No, don't do that to me!  Ant's.  Yes, sure I looked at those too!

>
>> Side note: Tuns out documents like contracts (which is what
>> "business" boils down into) could seen as a finalized subclass of
>> agents which just don't change state ever.  However in practice a
>> fuse mounted directory at my desktop is just yet another such
>> agent, certainly changing state.
>>
> Hah... a trivial distributed "Dropbox" clone built with fuse is one of
> my target "quick example" applications (a la "create a blog" for web
> frameworks and "create a todo list" for Javascript frameworks).

Want one?  Takes a minute.  ;-)

> OK... I'm going to call a time-out. I've read the following but won't
> comment simply because I'm about to leave to spend some time on a
> remote Scottish island without internet (but I wanted to reply before
> I left the relatively connected location of the mainland - I'm playing
> email catch-up).

See you soon.

/Jörg