We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.

We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.


Jörg F. Wittenberger [LibreList] Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches 2014-08-07 11:31:57 (6 years 2 mons 21 days 06:55:00 ago)
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 

> 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:
for yet another explanation of the same concept.

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

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?