Do IPFS and Holochain complement each other? Could IPFS data be served through a Holochain happ like Holo is doing with Holochain itself? Could it replace the need of Filecoin or what Textile is doing?
The future holds a large ecosystem of open source projects; that I’m sure.
I’ll be curious to hear from someone more knowledgeable than me, but as far as I understand it, IPFS could be integrated into the functions of a hApp for large file storage, which is less practical with Holochain alone.
absolutely a major use-case! there will be alot of cool things to do with data architectures on Holochain.
dApp = Happ = membrane
https://redux.developer.holochain.org/docs/guide/planning_a_dapp/
also check out: http://ceptr.org/
This thread might be old. But its relevance is as high as ever.
In my opinion, everything thats more than a few lines of text and has the capacity of being edited or deleted, should not be stored on the DHT of a hApp, because it will lead to unnecessary bloat.
One solution could be to only store the meta-data on the DHT, with a link to the actual file on IPFS. Agents trusted with that information would have to keep a copy of that IPFS data (and be able to proof it) until the author edits / deletes the entry. Then they are allowed to delete the IPFS data (the meta-data will of course remain intact on the DHT).
@jakob.winter hum… Any reason why the files can’t be stored in a separate DHT where only always-on servers live?
Imagine a YouTube clone, running on Holochain. I publish a 20 minute video about Pop-Corn (worth 2.6 GB of storage). Right after uploading, I realize that I accidentally mixed up the first letters of the title (P and C) 
I hasten to correct my error and re-upload the new video, deleting the first video in the process.
But if that file was stored on an immutable DHT, it will not truely be deleted, just marked as deleted.
Had we only stored the meta-data on the DHT and the video on IPFS, the first version could just be forgotten / deleted. No harm done. The only remnant would be a tiny entry in the DHT, worth a few KB of data.
Of course we could also use an immutable DHT for the meta-data and a second, mutable DHT for the actual data, from which files can be truely deleted. But why re-invent the wheel, when IPFS does an awesome job already and has an active community behind it?
That being said: I am just arguing from a theoretical standpoint. I have no idea, how easy / hard it would be to incorporate IPFS into a hApp…
Mmm I see your point… But if you are smart about the sharding of that file (and you have to be because Holochain has an entry size limit of 16MB) then only one chunk has to be replaced, and all the other ones will be deduplicated.
If you need really deletable data, you can always follow the throwaway DHT pattern, in which you delete the Cell when you want to forget its data.
I’m not saying we shouldn’t use IPFS ever with Holochain, I’m saying that for most cases I don’t think we need to.
I think doing a IPFS clone on Holochain is really simple, it’s basically this: GitHub - holochain-open-dev/file-storage: File Storage zome and UI module to store files in a holochain DHT, I don’t know what else is needed in a Holochain DHT that IPFS would provide (performance and storage of that module can and will be improved).
I am not at all married to IPFS. If you believe recreating a similar pattern on Holochain is rather simple, thats great news!
My focus is on the avoidance of unnecessary data-storage. Your point about the max-size of unnecessary data being closer to 16MB (because none of the other chunks changed) is reassuring. But having the option of completely forgetting / deleting the unnecessary bits is more elegant, imo.
Could you elaborate on that? I’m not familiar with it.
