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