[Luker88]

In general? No. Just because you can, it does not mean you should use a distributed db. Please remember to say that distributed, open databases have very narrow use cases.

Leaving aside use cases like credit card information, there are a lot of user information that is illegal to share unless the user explicitly consents. In the EU you can't even share your access logs by default.

And how do you handle authentication? Passwords? how do you avoid user enumeration, the collection of user email and info?

Distributed filesystems and CDN in general are great, but let's use them for things that do not actually need a single bit of security, please.

[carolc]

> "Distributed filesystems and CDN in general are great, but let's use them for things that do not actually need a single bit of security, please."

The notion that distributed filesystems are inherently, or can't be, secure is way off. I would argue that with these technologies, such as IPFS, they can be more secure.

The use cases are not only "open databases" (by which I assume you mean open to public), private databases and data sets can be achieved just as well. Just because it's "distributed" doesn't mean it can't be private or access controlled.

Agreed on the comment re. "...illegal to share unless the user explicitly consents" and I believe this will turn out better in the trustless, distributed web, eventually. Our whole current approach is based on the client-server paradigm forcing us to put every user and their data into one massive centralized database. But we can change the model here. Instead, how about you owning your data(base) and controlling who gets to access it? "Allow Facebook to read your social graph?" "Oh, no? How about another social network app?". As a user, I would want to have that choice.

That bridges to your next point on authentication, which can be done on the protocol level with authenticated data structures. You can define who can read/write to a database by using public key signing/verification. It could be just you, or it could be a set of keys. One good example of this is Secure Scuttlebut (http://scuttlebot.io/). I highly recommend to take a look an understanding the data structures underneath.

[Luker88]

The problem is not that only authorized clients can write, that is the easy part (signatures are enough for that).

The problem is limiting read access. Having a globally distributed db means that anyone can get a copy.

You can use ipfs for public data, and to store private encrypted data (with caveats: make sure you change the encryption key/nonce for every data change).

There is no way to modify private data depending on anonymous access without things like omomorphic encryption, and the whole system is completely void of any form of forward secrecy.

As someone who works with encryption and security, I can not recommend storing anything private on distributed systems. Leaks way too much data, and there are too many caveats. You can have securely designed applications, but I see no way to safely port common websites completely on distributed infrastructure without leaking a lot of data that today is supposed to be kept secret.

[userpass]

http://scuttlebot.io/more/protocols/secure-scuttlebutt.html >"Unforgeable" means that only the owner of a feed can update that feed, as enforced by digital signing (see Security properties).

https://github.com/ssbc/patchwork >You have to follow somebody to get messages from them, so you won't get spammed.

Doesn't that make it completely pointless because updates are still centralised? It merely shifted trusting a single provider to trusting each user which is not a scalable solution. The value add is so low you might as well just use IPNS and make people subscribe to IPNS addresses.

[arj]

But it is scaleable. On scuttlebot you follow people just like you have friends in real life. I also don't need to ask the government permission to talk to that person. That is DEcentralized for you right there.