4 ms·

Exactly. It's like, Woah, hold your horses there. "Obsolete"? I don't think so. To what extent can this IPFS serve an API or a dynamic database at this point? T

Exactly. It's like, Woah, hold your horses there. "Obsolete"? I don't think so. To what extent can this IPFS serve an API or a dynamic database at this point? To what extent will it ever be able to do that? I think HTTP/websockets is very good for these things. Static data is one thing, dynamic is a whole other story. It seems IPFS is just a new distributed way to archive data. So what? It doesn't help serve something like FB over a distributed network does it? And to what extent could some sort of "protocol" vulnerability stop these networks from being "uncensorable". Are they truly resistant to censorship, or could they be effectively shut down somehow? Wouldn't DDOS attacks cripple these? I mean, that's a crucial flaw, right, you just have to look up all nodes for an piece of content and constantly flood them with DDOS traffic and then, hey, you've censored the network, right?

carolc 9y ago
Databases, and dynamic content in general, can be done with/on IPFS. Take look at OrbitDB (https://github.com/orbitdb/orbit-db https://github.com/orbitdb/orbit-db) - "Distributed peer-to-peer database for the decentralized web" or their blog post "Decentralized Real-Time Collaborative Documents - Conflict-free editing in the browser using js-ipfs and CRDTs" (https://blog.ipfs.io/30-js-ipfs-crdts.md https://blog.ipfs.io/30-js-ipfs-crdts.md). And all that works in the browser without running a local IPFS in the background. That's pretty amazing imo.
- lgierth 9y ago
  Noms is also a great example of a peer-to-peer database: https://noms.io https://noms.io
- Luker88 9y ago
  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 9y ago
    > "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/ http://scuttlebot.io/). I highly recommend to take a look an understanding the data structures underneath.
    - userpass 9y ago
      http://scuttlebot.io/more/protocols/secure-scuttlebutt.html 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 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 9y ago
- imtringued 9y ago
  Think of orbitdb as a git repository where everyone has write access. Malicious nodes will spam hundreds of gigabytes of data into it until it's large enough nobody can clone it. Even if you solve the spam problem you still have the problem that you need to download the constantly growing dataset. The blockchain is already 160GB big even though it's transaction throughput is anemic. Full p2p applications can't offload computation, computations have to happen on your computer and for computations you need the entire dataset. This is fine for messaging and static files. Federation is a far better idea. You get the benefits of centralisation and decentralisation.

carolc 9y ago

Databases, and dynamic content in general, can be done with/on IPFS. Take look at OrbitDB (https://github.com/orbitdb/orbit-db https://github.com/orbitdb/orbit-db) - "Distributed peer-to-peer database for the decentralized web" or their blog post "Decentralized Real-Time Collaborative Documents - Conflict-free editing in the browser using js-ipfs and CRDTs" (https://blog.ipfs.io/30-js-ipfs-crdts.md https://blog.ipfs.io/30-js-ipfs-crdts.md). And all that works in the browser without running a local IPFS in the background. That's pretty amazing imo.

lgierth 9y ago
Noms is also a great example of a peer-to-peer database: https://noms.io https://noms.io
Luker88 9y ago
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 9y ago
  > "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/ http://scuttlebot.io/). I highly recommend to take a look an understanding the data structures underneath.
  - userpass 9y ago
    http://scuttlebot.io/more/protocols/secure-scuttlebutt.html 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 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 9y ago
imtringued 9y ago
Think of orbitdb as a git repository where everyone has write access. Malicious nodes will spam hundreds of gigabytes of data into it until it's large enough nobody can clone it. Even if you solve the spam problem you still have the problem that you need to download the constantly growing dataset. The blockchain is already 160GB big even though it's transaction throughput is anemic. Full p2p applications can't offload computation, computations have to happen on your computer and for computations you need the entire dataset. This is fine for messaging and static files. Federation is a far better idea. You get the benefits of centralisation and decentralisation.