AutoDapp: a proposal to decentralize existing web apps • Hacker News Board

Re: AutoDapp: a proposal to decentralize existing web apps

#21

Post by hk__2 » Thu, Apr 09, 2020, 2:06 PM UTC

theK wrote: post #20

verdverm wrote: post #16

Earlier quoted context omitted.

I have yet to see this issue addressed in a meaningful way.

I am very curious about this ideology. The whole world seems to see indelibility of data as a problem in this context. Yet immutability is seen as a generally good thing for a lot of other software cases. Further we cannot manipulate past events and there even is something about repeating history when you don’t know it. So why would we really want to delete past data? From this standpoint wouldn’t deleting data be si…

> So why would we really want to delete past data? From this standpoint wouldn’t deleting data be similar to trying to cover up the past?

This assumes that data is always true and accurate, which is not always the case. Say Bob was convicted for pedophilia but a couple months after the charge was retracted because it was an error. Now Bob can’t find a job because “the data” says he’s a pedophile, even if he’s not.

Re: AutoDapp: a proposal to decentralize existing web apps

#22

Post by pagutierrezn » Thu, Apr 09, 2020, 2:12 PM UTC

q3k wrote: post #9

addisonj wrote: post #8

Hrm.. interesting idea! The tl:dr; appears to be "we built a blockchain based query logger" where essentially the consensus appears to just be that it is valid SQL, and defines an ordering of the statements. Then once everyone agrees to apply the change, then it is applied... With (AFAICT) no interaction with the DB during the consensus process? This seems to be a bit naive of features like locks and transactions tha…

This is naive of any real-world, large scale use of RDBMS systems. Not to mention any actually distributed storage systems.

And don't expect it to support normal transactions or participate in distributed ones

Re: AutoDapp: a proposal to decentralize existing web apps

#23

Post by api » Thu, Apr 09, 2020, 2:17 PM UTC

CJefferson wrote: post #13

One thing I was trying to find. Is it possible to completely erase things from history? Because if not, the first time someone uploads something illegal to your decentralized wikipedia and it gets into the block chain, you are in trouble.

I've heard this called a "pool pissing attack," as in peeing in the swimming pool, and it's already been done to some block chains, which contain CP and other illegal stuff.

One mitigation I've used in one project is to hash records by hashing hashes of their fields, permitting record fields to be selectively deleted from storage (e.g. by a blacklist) without breaking data structure validation capability.

Re: AutoDapp: a proposal to decentralize existing web apps

#24

Post by nradov » Thu, Apr 09, 2020, 2:20 PM UTC

theK wrote: post #20

verdverm wrote: post #16

Earlier quoted context omitted.

I have yet to see this issue addressed in a meaningful way.

I am very curious about this ideology. The whole world seems to see indelibility of data as a problem in this context. Yet immutability is seen as a generally good thing for a lot of other software cases. Further we cannot manipulate past events and there even is something about repeating history when you don’t know it. So why would we really want to delete past data? From this standpoint wouldn’t deleting data be si…

What you're missing is that in some domains like healthcare there are legal compliance requirements to delete past data in certain circumstances. If false or embarrassing or misattributed data ends up in my medical record I want it completely removed, not just marked as outdated. This isn't just ideology, it's a fundamental matter of patient privacy.

Re: AutoDapp: a proposal to decentralize existing web apps

#25

Post by _jal » Thu, Apr 09, 2020, 2:28 PM UTC

theK wrote: post #20

verdverm wrote: post #16

Earlier quoted context omitted.

I have yet to see this issue addressed in a meaningful way.

I am very curious about this ideology. The whole world seems to see indelibility of data as a problem in this context. Yet immutability is seen as a generally good thing for a lot of other software cases. Further we cannot manipulate past events and there even is something about repeating history when you don’t know it. So why would we really want to delete past data? From this standpoint wouldn’t deleting data be si…

> Is there some big idea I’m missing that explains the favoring of the “mutable past” view?

It is called law. There are lots of laws that govern circumstances under which data must be destroyed, and others that make certain data illegal to possess.

You can argue that they're bad laws, and I'd agree that some of them are. But whatever you think of them, ignore them at your peril.

Re: AutoDapp: a proposal to decentralize existing web apps

#26

Post by synctext » Thu, Apr 09, 2020, 2:29 PM UTC

drchopchop wrote: post #7

So, it's not even that the SQL state is distributed, it's that every change to the SQL state has to be "validated" and appended to a blockchain? At a 1M DAU traffic level? How often are blocks/writes written? Who pays for all that data storage? How "decentralized" would it really be, considering the incredibly onerous requirements to run a validator at the target scale?

Indeed, as a professor who studies these systems for a living I also had to think. Will this scale? Big step forward if we get something like this finally to 1 million people. Who owns the server infrastructure? How are these miners paid? The usual token-based incentive? Where do I buy these with real Euros or Dollars?

Incentive alignment is key. We known since Bittorrent tit-for-tat that creating a micro-economy is a hard problem. I hope they get some sort of token and micro-economy going, but this is a known hard problem.

Re: AutoDapp: a proposal to decentralize existing web apps

#27

Post by verdverm » Thu, Apr 09, 2020, 2:36 PM UTC

theK wrote: post #20

verdverm wrote: post #16

Earlier quoted context omitted.

I have yet to see this issue addressed in a meaningful way.

I am very curious about this ideology. The whole world seems to see indelibility of data as a problem in this context. Yet immutability is seen as a generally good thing for a lot of other software cases. Further we cannot manipulate past events and there even is something about repeating history when you don’t know it. So why would we really want to delete past data? From this standpoint wouldn’t deleting data be si…

HIPAA, GDPR, CCPA, Right to be Forgotten, DMCA

The ideology is law, most blockchains as is do not comply with law. So the are effectively unusable in practice (generally speaking too)

Re: AutoDapp: a proposal to decentralize existing web apps

#28

Post by ryscheng » Thu, Apr 09, 2020, 2:37 PM UTC

crispyporkbites wrote: post #4

Trying to understand this one - this is saying we take an standard 3-tier app and instead of storing data in our normal sql/nosql database, we route it through some kind proxy called a "validator", which is a blockchain based data store, that uses the same database API. And the benefit of doing this is to allow other users to be able to validate the integrity of data and ensure historical changes cannot be overwritte…

That's exactly right! The argument is that if you look at truly reliable cloud services (think Google). They already use consensus protocols to replicate the database globally for fault tolerance purposes. The spanner paper does a decent job explaining their architecture. https://static.googleusercontent.com/media/research.google.c...

Why not do it for decentralization purposes too? Blockchains are just a another class of consensus protocols. IMO one of the defining aspects of blockchains is the stronger threat model. Traditional consensus protocols are designed to be crash-fault tolerant, not byzantine-fault tolerant.

I wouldn't get tripped up by the word "validator". In the academic world we probably would have used the term "node" or "replica". It has a special meaning in the blockchain world because it conveys a sense of trust and work-checking.

"Who pays" is a fantastic question. The blog completely elides the question about incentives which in my opinion will vary depending on the app. For creating an censorship-resistant Wikipedia, it'll be different than a communications app. Hoping to write a blog post about that soon after we get more built to show.

Re: AutoDapp: a proposal to decentralize existing web apps

#29

Post by CJefferson » Thu, Apr 09, 2020, 2:39 PM UTC

theK wrote: post #20

verdverm wrote: post #16

Earlier quoted context omitted.

I have yet to see this issue addressed in a meaningful way.

I am very curious about this ideology. The whole world seems to see indelibility of data as a problem in this context. Yet immutability is seen as a generally good thing for a lot of other software cases. Further we cannot manipulate past events and there even is something about repeating history when you don’t know it. So why would we really want to delete past data? From this standpoint wouldn’t deleting data be si…

I think this is a case where "Think of the children" is the right answer.

Someone uploads pictures of a child being violently sexually abused to a blockchain. It is my honest opinion the majority of people would not want to continue distributing those photos. It is certainly the law of many countries that it is illegal to distribute such pictures.

Re: AutoDapp: a proposal to decentralize existing web apps

#30

Post by steve76 » Thu, Apr 09, 2020, 2:43 PM UTC

verdverm wrote: post #16

CJefferson wrote: post #13

One thing I was trying to find. Is it possible to completely erase things from history? Because if not, the first time someone uploads something illegal to your decentralized wikipedia and it gets into the block chain, you are in trouble.

I have yet to see this issue addressed in a meaningful way.

Use peer to peer, like a list of well known dat archives, as a data source for a static site generator.

In-app peers listen to one another like web sockets. They write what they want and the site sources the best.