FlureeDB, a Practical Decentralized Database (2017) [pdf]
flur.ee
flur.ee
Censorship is rarely a technological issue, but one of laws.
No possibility for data regulation? Well, data regulation is already there, and they're effectively advertising that they are trying to bypass those regulations. If they actually can do that, it won't be long before someone rules "Use of FlureeDB violates GDPR compliance" and all your nice tech isn't worth squat. The database may prevent data regulation, but you can still put the people using it in jail.
* Brian Platz addresses the question
* first goes through benefits of immutability in Fluree in context of auditing
* suggests one approach is storing PII (personally identifiable info) in encrypted manner in public fields, and storing the decryption keys separately -- the act of "forgetting" is the act of destroying the decryption keys
* another approach: on the public Fluree blockchain DB store a UID that has no public ties to PII ... and store the PII in a private corporate-side Fluree blockchain DB ... the Fluree system allows JOINs across Fluree systems, so internal corporate-side queries can do JOINs to consolidate public info with PII stored internally ... now to the "forgetting" part ... in spite of immutability guarantees, Fluree does have one escape, which is the possibility in the private Fluree (for which the corporation completely controls consensus) to "retract" that entity containing the PII, along with a tombstone and a full audit trail of the retraction
Both these approaches seem to address the right-to-be-forgotten pretty well. The Fluree guy also suggests that for the PII part perhaps Fluree isn't the system you want, and perhaps that should be stored in some other system.
* governments want to improve public health
* parents in a given geographic region can opt-in on birth of a child to enroll their child in a longitudinal data-gathering regime
* parents' and child's PII (personally identifiable information) is stored in a special private Fluree instance (or other DB), and each is assigned UIDs that can be public without disclosing their identity
* the child's UID, along with basic demographic info (that can't be used to resolve their identity) is pushed to the public Fluree DB ...
* some info, such as genetic profile, very specific outcomes of educational tests, etc., might be stored over time in a very secure DB not open to the public
* basic measures of health, education, nutrition, could be stored publicly and available to researchers ... with more and more info stored over time
* more info about a child's "history" that might be useful in correlating with positive / negative outcomes also might be stored publicly
* public health researchers could analyze trends, etc., to determine what education and nutrition programs, environments, etc., contribute positively to good outcomes
* public health and other researchers, such as medical, pharma, nutrition, etc., researchers, could use public data to find "cohorts" of children that might be suitable for studies ... and reach out in the system to families (whose identities will not be disclosed until appropriate) of those children to give them more info about why their child should become part of a study, and give them a chance to opt-in or contact researchers for more info
That's just one very interesting application off the top of my head, and Fluree (I'm not associated), as a Public Benefit Corporation (PBC) who states they eventually plan to open-source all or much of their technology, might be a good venue in which to deploy such a system ... a system that would require high levels of confidentiality, trust, while still being open to the extent possible and advisable.
As a result, copies of the original document are pretty valuables unless they are certified by a court/agency as being official. Governments should definite move towards more modern databases and technology, but given that they "are" the central database, I don't see the benefit of decentralized one.
I'm not sure cryto-shredding is a legit method to "delete consumer data"
If it is irretrievable, and the crypted data looks like noise, I would argue that the content is gone.
Unless the encryption uses post-quantum crypto, in theory it’ll all be “un-shredded” if quantum computing becomes feasible. We’ll have bigger problems at that point, but still, it’d make you “unforgotten”.
It's built from hypercore, the same library powering the DAT protocol.
Also, someone recently wrote a graph database on top of hyperdb: https://github.com/e-e-e/hyper-graph-db
Two critiques:
* Given that this is a hosted offering this seems like an odd definition of de-centralized, from my reading a more accurate description would be: allows cross-partition queries. Edit: response below indicates this aspect is missing from the linked whitepaper but available elsewhere.
* The graph database section is hand-wavy. This seems like it could be similar to Datomic where with a small enough dataset you may have amazing performance, but at a large enough scale you will be lacking index-free adjacency.
Note that I think I heard this in the Epicenter podcast (https://www.youtube.com/watch?v=fdne9EvFNaw) featuring the Fluree founders. ... aahh, at this point in the podcast they talk about the federated/distributed Fluree: https://youtu.be/fdne9EvFNaw?t=3770
EDIT: pointer to "federated" / distributed database in podcast
It was hard to keep reading after this.
https://hyperledger-fabric.readthedocs.io/en/release-1.1/led...
Yep, that’s what I’ve asked above. Might spur a conversation if your claim is legitimate.
Are you possibly limiting the term decentralized to blockchain DBs? That would be a stretch. Decentralized DBs existed for a long time before blockchains.
I did read the entire paper and it was interesting.
You're more specific meaning of the word should have been spelled out before the claim. The meaning that I read was perfectly valid and shared by many others.
I apologize. I have a serious problem in forum discussions of not paying attention to who writes each post. I absorb all replies and then reply to the group. My bad. (Edit: And I thought you were the author).
>dismissing a paper on such pedantic terms as you originally did
I never dismissed the paper. Read my first post carefully. I enjoyed it and did read it before commenting. I was just pointing out my shock at the claim, which seemed ridiculous given my understanding.
> you keep escalating this
I thought I was participating in an argument about the meaning of the term "decentralized". I was defending my understanding to multiple people telling me I didn't know what I was talking about.
> Having taken advanced distributed computing courses
I have been working with databases for over 45 years. Most of that time decentralized meant lack of a centralized (single point of failure) computer, not a person or organization. It is only recently (10 to 15 yrs?) that the user meaning has appeared. Please forgive my classic interpretation.
The tagline at the github repo at https://github.com/basho/riak is "Riak is a decentralized datastore from Basho Technologies". I don't think they would lie.
How does it compare against:
- IPFS (yes, plenty of people are doing DB stuff on IPFS)
- GUN (full disclosure, I'm the author, https://github.com/amark/gun )
- Scuttlebutt ( http://scuttlebot.io/ )
- Beaker Browser
They go on to talk about "append-only" data structures (this alone does not make a system a blockchain or decentralized, but I don't see any further reasoning on it), because technically, you could do things very similarly with:
- Kafka
- Cassandra
- Couch
And "append-only" is not practical, there are lots of caveats you have to handle (you don't get eventual consistency for free, performance is terrible on reads, etc.), it often times just makes scaling up harder, which is not "practical".
The next section begins to discuss "blockchain" technology, but I don't see code on GitHub:
- https://github.com/fluree/flureedb (empty repo) ?
But their main website is already advertising $1000/month "Enterprise" plans. The whole point of Blockchain and Decentralization is not to be vendor-locked into a proprietary centralized DBaaS. Why isn't the code Open Source?
Adding to the list: - BigchainDB (https://github.com/bigchaindb) a practical BFT blockchain DB (disclosure, I'm the co-author)
- SWARM
- OrbitDB
And also, it's a very very bad idea to have public storage - one (encrypted) PII entry illegal datum and it's over.
I really would like to work on something like that but so far it's only enthusiasm and zero education. I am a pretty senior programmer in my eyes (16 years of official career, 25 years in total tinkering, started at 12-13 year old teenager) but sadly all that experience does not translate directly to areas like these.