Hacker News Reader

Comment by realPubkey | Hacker News Reader

I doubt the usefullness of orbitDb. Ipfs-nodes only store and distribute content which they have accessed before. When you have a database with user-based data, noone except yourself will distribute it. This means you could have the same distribution with plain webrtc instead of height-ping ipfs.

View on HN

It's true that availability is not "automatic" as per the software itself (rarely is in P2P networks). To make sure the data stays online (whether IPFS or OrbitDB), one needs to make sure there are enough nodes serving the data. In OrbitDB the replication protocol will make sure the full database is downloaded and served upon opening the database and as all db-data is IPFS-data, the db will be served just like any content on IPFS. So for example, for an application built with OrbitDB and IPFS, one would probably want to run some nodes themselves to "pin" (IPFS parlance) the databases and serve them to the network.

Edit: There's an open issue for a "OrbitDB pinning service" (https://github.com/orbitdb/orbit-db/issues/352), it's in the works atm.

But doesnt this mean I just distribute a big json over ipfs? Where do I need orbitDB for that?

Not quite. The data structures for the "database" part are more complex than a single json structure. Each update to the database is an "individual json" which get linked together using an append-only log CRDT (https://github.com/orbitdb/ipfs-log) and you'd essentially serve that log. So instead of "one big json", it's "many small jsons" and the state (view) of the database gets calculated from those small jsons.

Thank for clearing that. I think I have to read the docs more carefully

Although with webrtc you still need a signaling server and a turn/stun server. It would be interesting to try getting the webrtc stack to work fully serverless by using js-ipfs to exchange ip for stun and then do signaling using js-ipfs with websockets. Then you could open up peer channels to exchange data without using js-ipfs but by using it for the initiation and signaling layers you could potentially setup a pure p2p video chat system or file sharing system.

True, currently we always need some sort of signalling server to be able to connect to browser<>browser peers but once you done that, you can connect directly to other browsers (truly P2P in the browser).

Now, if we can have js-ipfs and go-ipfs nodes on desktop automatically act as signalling servers (if you start with a `--server` flag or something), we'll be able to decentralize the need for signalling servers as well, and remove another point of centralization. Getting us closer to the goal as well.

Maybe in the future we'll be able to have TCP/UDP sockets in the browser, but we'll see when/if that happens.

Disclaimer: I work fulltime on IPFS

Reply on news.ycombinator.com