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.
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.
Can anyone be bothered to explain to me how this works?
I know that IPFS is some sort of distributed content-addressable thingy. So I expected that ipfs.io would deliver some JS to my browser, which would get it to look-up some distributed hash table in order to find peers with the content (a la torrents).
However I'm not running JS and that page loads just fine. So how does it work?
The ipfs.io url is a public IPFS gateway, ie. bunch of IPFS nodes running on servers and "caching" content to be served through that domain. From that perspective, you're not accessing the content through the IPFS protocol but through http like any website. It's a public service operated by the IPFS community, but underneath it does all the "...get it to look-up some distributed hash table in order to find peers with the content (a la torrents)".
However, if you install the IPFS client (https://dist.ipfs.io/#go-ipfs), you can get the blog post peer-to-peer through IPFS by running `ipfs get QmY2LufsW3v6AfxTTkp6SGqDGa5AeJhSZXH8RSsdiao4Ds`. Note how the hash in the ipfs.io url is the hash of the content stored in IPFS.
I think it depends on what the use case for IPFS is. Many use it "server-side" to just transfer and store files, so a "native client" makes a lot of sense. The IPFS devs always recognized the importance of the browser though and as such js-ipfs (https://github.com/ipfs/js-ipfs) has always been a first-class implementation of IPFS. With js-ipfs, the IPFS protocol works in the browser and can be embedded to JavaScript applications in a way that doesn't "require a new client".
Highly recommend to read into IPFS and how it works to understand the various use cases and possibilities. A good starting point would be https://ipfs.io/ and https://github.com/ipfs/ipfs.
There is already a Javascript implementation [1], but it is not feasible to setup a full IPFS node in every browser tab that loads an IPFS resource. Instead you can use ipfs-companion [2], a browser extension that lets you easily load IPFS resources in your browser. While it can use the Javascript implementation, this is not recommended as it is currently pretty resource heavy [3].
js-ipfs, the Javascript implementation of IPFS, has made a lot of progress in the past 6 months. It's still early but totally usable.
We've been working on go-ipfs and js-ipfs interop so that browser nodes can talk to "native" nodes. It's not fully ready yet but soon. This will open a lot of doors for a more advanced network and applications using IPFS.
Is there a working ipfs demo page anywhere? I've had a look around and can't find one (the closest appears to be Orbit, but the ipfs-js version is down).
I'm particularly interested in using ipfs pubsub capabilities. It looks like an interesting way of allowing multiple users of a web app to talk to each other without needing (much) server side support.
Unfortunately there's no proper demo page :/ We're working on improving the docs (we know this is big issues atm).
There's an old version (from June) of Orbit at http://orbit.libp2p.io which you can try. Much has happened since and we're working on bringing the js-ipfs version Orbit back to a working state.
Can I just take a moment to talk about how happy I am that the IPFS team is actually taking protocol documentation seriously, allowing for multiple implementations and the ability to understand how the protocol works?
IPFS and Matrix seem to be the only teams doing this: Dat and SSB have vague protocol documentation at best, only documenting bits of the protocol at all.
The cool thing about unique hash per message is that it makes that message linkable in other applications, after all it's just an IPFS hash. So for example, if you share a file in Orbit, you can get that file with IPFS just like you would get it normally.
Developer of Orbit here. Great to hear all the feedback, thank you!
Most questions have been already answered, but to clarify:
Orbit indeed uses IPFS pubsub (https://github.com/ipfs/go-ipfs/pull/3202) for real-time message propagation, no servers are involved. In addition, it uses orbit-db (https://github.com/haadcode/orbit-db) - a distributed database on IPFS - for the message history, so the messages are not ephemeral and the channel history can always be retrieved. This is a really nice property and allows Orbit to work in "disconnected" or split networks, as well as offline.
Orbit has been a testbed for IPFS applications and orbit-db came out of that work, enabling various types of distributed, p2p applications and use cases: comment systems, votes/likes/starring systems (with counters), feeds, etc. And now with IPFS pubsub, we're finally at a point of being completely serverless and distributed which is hugely exciting and opens so many doors for future work!
I'll be hanging out on #ipfs in Orbit if you're interested to try it out. Note that the Electron app and the web version at orbit.libp2p.io don't talk to each other atm (we're working on this), so I would highly recommend to try out the Electron app.
While you're at it, try drag & dropping files and folders to a channel, that's one of the coolest feature of Orbit atm imo :)
We're actively developing Orbit and making a push in the next few months, if you're interested to take part in the design and development, or would like to develop your own apps using the same tech, join us on Github https://github.com/haadcode/orbit/issues.
Thanks for the comments everyone, much appreciated!
