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?
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.
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.
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.
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?
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).
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.
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.
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.