Understanding IPFS

I have uploaded an image to ipfs and downloaded it. And I feel very stupid. Because I can not do anything useful.

Questions that I have:

  • How a chat application works? Does it create a new file for each message? How it get notified about new messages? How two specific pairs find each other? Sharing hashes does not make any sense.
  • Does all clients have to install ipfs to use it? How can they update a specific context? Because the hash changes every time.

Specific problem that I have to solve:
Assume in this problem there are between 10,000 to 40,000 regular nodes and some supervisor nodes. Regular nodes want to send some data to supervisor nodes periodically and receive orders occasionally. How ipfs can help with this? Do all nodes (from PCs to some embedded systems like Raspberry Pis) need to install ipfs bin? How can they find each other by purely using ipfs (assuming some predefined configs are made on nodes)?

All in all ipfs feels like a super interesting thing and when I think about it, I feel like stupid characters in movies when facing an Alien spaceship; exiting! But then what?

1 Like

IPFS can deliver static content only. This can include client side javascript, so applications can be built that access APIs via ajax. The API would need some kind of server independent of IPFS, although it could use IPFS for storage. For example, I have built an ipfs based website that pulls post/comment data from the STEEM blockchain. (It wasn’t built with IPFS in mind, and I have thought of IPFS based optimisations in that regard).

So “How a chat application works?” What chat application? Have you seen one?

I can think of several ways to implement one. Indeed, I the STEEM blockchain allows private messages between users, so if I add support for that to my own IPFS based site, I could implement a private chat based on those messages.

But you could create an API to store the messages on a database, or on IPFS itself (although in that latter case you’d still need to record the hashes somewhere).

As for the hash changing every time, that is why we have IPNS. This is a single hash that always points to the latest registered hash.

IPFS can deliver static content only. …

I understand that ipfs acts as a protocol/transportation layer and the logic must be implemented inside the application itself.

So “How a chat application works?” What chat application? Have you seen one?

Yes, I have seen bunch of them. For example this one GitHub - orbitdb/orbit: A distributed, serverless, peer-to-peer chat application on IPFS has a working example website too.

blockchain …

I think it’s most likely that I have a rather insufficient understanding of that word. And based on that understanding, IMO blockchain is not a proper algorithm/technology for implementing chats - at all. Syncing a million messages (text, sound and video) on every new message, even if the blockchain contains only references to those media, sounds impractical to me.

As long as IPFS lacks a good ecosystem of documentation/tutorials - in this substantially sub-optimal state - “replacing web/http/etc with ipfs” is more of a wishful thinking (I know; blabbering about OSS is easy, but ipfs sounds super awesome and not blabbering is hard in it’s case - please excuse me).

The STEEM blockchain is already doing it. Although it doesn’t store images and video on the blockchain. D.tube (STEEM based video hosting) uses IPFS to store the videos. Of course, Graphene based blockchains work a little differently to Bitcoin based ones, as they are based on Distributed Proof of Stake rather than Proof of Work. This allows them to be much more efficient. This doesn’t necessarily mean they work better at decentralising currency, but it they have different goals and functions.

It also depends how decentralised you want the chat to be. Steem can only do private messages 1-to-1, and currently lacks a good interface for it. A public chat could be implemented in a post thread, but it would in theory be open to all steem users. You could hide posts from some in your interface, but they would still show up in the thread on other steem based websites viewing the thread.

It is possible, as it already exists, but whether it is what you are looking for is a whole different ball game.

1 Like

IPFS can deliver static content only.

There are a few things worth noting here:

  • Since most content is identified by hash, it can’t be changed
  • Within IPFS, you can use either IPNS (has some issues right now, but is being steadily improved) or DNSLink as exceptions to the above rule — both of these let you make mutable pointers to other IPFS objects.
  • Lots of people are also exploring other alternatives to IPNS and DNSLink, like the blockchain-based ones @antonchanning mentioned. There’s no real “best” solution that’s emerged yet.
  • IPFS also has a built-in publish/subscribe (pubsub) feature. Most chat tools (and a lot of the database stuff) is built on top of that — it allows for speedy communication and updates. If you’re trying to communicate changes to existing objects through pubsub, you’ll also want to look into CRDTs, which are an important tool for distributed databases. OrbitDB is a good example of this in practice.
  • Individual nodes can also link up and communicate directly using Libp2p, the core networking library underlying IPFS.

Some other resources on dynamic data in IPFS:

Assume in this problem there are between 10,000 to 40,000 regular nodes and some supervisor nodes. Regular nodes want to send some data to supervisor nodes periodically and receive orders occasionally. How ipfs can help with this?

People are still figuring out the best ways to do things like this on IPFS, but a good idea to start with might be to use pubsub for most of this communication. You’ll need to implement your own system for signing or encrypting messages (depending on your security concerns) — IPFS doesn’t provide any higher-level tools for that (yet). If you need to maintain a list of public keys for nodes that are allowed to be “supervisors,” you might maintain that in IPNS, or just regularly rebroadcast the list over pubsub.

Do all nodes (from PCs to some embedded systems like Raspberry Pis) need to install ipfs bin?

You can also use IPFS as a library directly in a Go or JavaScript program. But for the most part, yes. If you want nodes to communicate in a distributed fashion, without needing to know much about each other, they’ll need to do all that communication with IPFS or Libp2p.

How can they find each other by purely using ipfs (assuming some predefined configs are made on nodes)?

Unless you have a short list that doesn’t change often, you’ll probably want to use a system like pubsub, so your nodes don’t necessarily need to communicate directly with each other. You could also have a decentralized (but not fully distributed) system where all nodes are configured with the addresses for a few central nodes — then they start by contacting those nodes to get a list of other nodes to talk with (this is how ws-star works for connecting IPFS nodes inside web browsers right now).

2 Likes

Thanks for informative and thorough answer!

Still ipfs is a vague idea in my mind and I can not find a good entry point. Seems my grasp of the concept is rather too incomplete. I need to code some stuff to understand it - and there is not relatively obvious entry point.

If you are talking about Dynamic Data, I think PubSub feature of IPFS maybe usefull.

1 Like

No disagreement there! Folks working on IPFS are definitely aware of that and we are working on improving documentation here: GitHub - ipfs-inactive/docs: [ARCHIVED] 🤖 📚 IPFS documentation working group, plus IPFS docs site code

For some good introductory material, you might also want to take a look at The Decentralized Web Primer: Introduction · Decentralized Web Primer

1 Like

Nice timing! And thanks for stepping in!

So far I have seen many topics here, discussed by visionary business people, talking about how nicely ipfs can play in many industry sections - video streaming, healthcare, etc, etc.

(IMHO):

But ipfs will take off when developers can play with it easily. Ideas can go from a weekend toy project to real world business - from a realtime grocery shopping reporting to my wife (got this - with pics - not found that, etc) to a realtime guaranteed cargo delivery system.

As long as there is no concrete developer-oriented documentation and most importantly, step by step core tutorials, ipfs won’t grow that much.

This is a mistake that many OSS projects have made: starting from business people (or solely relying on that).

Instead make it accessible to developers, make it developer-oriented. IPFS clients are not businesses but developers.

Businesses are potential clients for ideas that are developed based on IPFS - not ipfs itself.

1 Like

The recent getting GitHub acquired by Microsoft - for wrong/right reasons - caused some uneasy concerns among teams and developers.

We could use IPFS by now, if it was not going down an “enterprisy” path.