If I upload a movie to ipfs, and then, on another node, I request it, will it automatically start showing the movie(as in it shows the movie and also downloads more and more chunks ? ) If that’s true, I guess, file sharing works getting chunks SEQUENTIALLY ? correct ? I think that’s how torrent works too.
There are 2 modes to link chunks together (--trickle option in ipfs add)
- Without (merkle-dag) the default, creates a well rounded format that is well suited for random access and highspeed download.
(Here Qmfoo is the hash you are gonna share to other users, Qmbar,Qmfaa and Qmfee are middle blocks, similar to Qmfoo, all other blocks (the bottom ones) are actually containing different shard of the file)
- With (trickle-dag) it will line up thing, you should have a slower initial lag while loading the head of the file, but you should also expect atrocious random performance, also note that this way of storing the file has currently a speed limit, merkle’s speed is exponential the more block fetched, the more you can fetch (until you reach data stores, trickle’s speed is constant, fetching a middle block only reveal one new middle block). However there will be less listings to store and the overall size would be smaller:
(Here Qmdoo is the hash you would be sharing, also note that even the data is stored using the same underlying blocks, the final hash is different)
The overhead is way less big than what my example is showing, I don’t think there is any reason to use trickle unless you really need to save a few Kb on multiple Gigs files since merkle has exponantial theorical speed (btw the speed difference may be partially fixed in the future by graphsync, but it’s still WIP).
Also a chunk is 256Kb or less, so if your file is <256Kb it isn’t even chunked and just used as is.
sharing works getting chunks SEQUENTIALLY
This depends, I think it’s what is currently done with ipfs cat but if you use partial content on a gateway (such while watching a movie in your browser on a gateway) you can lazy load part of a file on demend (like streaming sites do, only loading the few next minutes). In theory it would also be possible to download in a random order if you want (like most torrent implementation do), (this is maybe even what ipfs get and ipfs pin do but I’m unsure).
i read somewhere that with filecoin, it doesn’t store the whole file at one node ever because it doesn’t want any node to see the whole file…
Idk where you read this but it’s just wrong, sending only parts of a file isn’t an effective way to protect against that (encryption is) as even if you receive half of a file, this half might still contain keys, passwords or general data you don’t want other to see. The actual reason filecoin is spliting file is so if a node dropout you loose way less of your data (filecoin also uses parity to overstore files, so filecoin can stores like 3 copy of the file (including parity) and so you can loose 2/3 of your nodes and still recover the initial file).
Yes, but if I encrypt, and whichever node receives a file and knows how it was encrypted, then it can use the same algorithm to decrypt it. Not an ideal, but much better…
This depends of what you do.
IPFS shares plain files without carring too much about there content or what you do with thoses so it’s up to you and how you encrypt them.
You should probably encrypt using a keyed algorithm (encryption with password) such as AES.
Example with openssl on linux, I’ll encrypt the file test with the password test and add it, then fetch it and decrypt it (note that crypto is hard, and there are many issues with this example, I wouldn’t use this in the wild like this, you could leak part of your key or greatly simplify bruteforcing) :
$ cat test | openssl enc -aes-256-cbc -pass pass:test | ipfs add --pin=false -Q -
QmV3nWXuS3TgsWMkwUNSx4MVN4z4rBagdqBtN2fhMERvjp
$ ipfs cat QmV3nWXuS3TgsWMkwUNSx4MVN4z4rBagdqBtN2fhMERvjp | openssl enc -d -aes-256-cbc -pass pass:test
Hey :)
If this was done correctly, you could change the password to something long that no one knows and even if they were able to see that it’s AES CBC, they wouldn’t be able to do anything without the key (obviously the key must be shared OOB (out-of-band, so not publicly on IPFS, the key is private and should stay that way)).
So the assumption that it starts downloading and streaming chunk by chunk is correct. I don’t know what guarantees you’re mentioning.
It might or it might not, it’s up to what you do with it.
You can do whatever you want depending of what you need (sequential can have less overhead and have faster delay to meaning full data). Random is faster and more reliable.
If you just want to stream movies on top of IPFS, that already works perfectly. You just need a browser that use partial content on top of a gateway and this already work (such as firefox, and likely chrome too).
Just open any video file in a gateway or using <video> and you will be lazy loading part of the file (streaming it). If you want to do ipfs in the browser, I’m not sure, I know very little about ipfs-js.
Extra notes
Movie codecs aren’t sequential, they are mostly random (depending of what you use this change, but the simplest of them usualy start by a header with some metadata, then a video track, then an audio track (or both swapped)) so while playing a video you will read a tiny bit of data in the start, then start reading 2 tracks at different places, so it’s mostly random accesses (also note that scrubbing in the timeline will make that fully random), some more complex codecs and container are even more random. (thus making merkle-dag better for most of them)
