>What is IPFS?
A fully decentralized, distributed and encrypted file distribution platform.
>why would one use it
* Distributed and decentralized: no single point of failure, censorship-resistant.
* You can have a mutable address (i.e. always points to the latest version of a site), or a static address (points to a specific file). Yes, you can host sites over IPFS.
* Peers are found fast for new downloads. You don't need to wait that much to start a download.
* You can watch your animu while it downloads, I watched few episodes that way and it didn't even buffer.
Presentation of ipfs by its lead designer:
>how to upload a single file
$ ipfs add ./$file
Access it at localhost:8080/ipfs/$outputted-hash
>how to upload a dir
$ ipfs add -r ./$dir
Access it at localhost:8080/ipfs/$last-outputted-hash
>how to make the thing mutable
$ ipfs name publish ./$file-or-dir-hash
Access it at localhost:8080/ipns/$output-hash-aka-peerid (it's ipNs not ipFs)
To update, publish another hash and it will be available at the same IPNS address.
>gateways (how to access IPFS if you don't have it installed)
>I2P and Tor support coming soon™. We need that thing anonymous so pls halp.
>Sites with content on them
/ipns/gindex.dynu.com/ site index
/ipns/QmUqBf56JeGUvuf2SiJNJahAqaVhFSHS6r9gYk5FbS4TAn anime tracker
threadly reminder to pin files that you care about.
Video for big guys:
Can be streamed easily by putting the url in a videoplayer of choice. IPFS is that fast.
We also have the full /g/entoomen library:
We got quite a lot of stuff now in the index.
Someone was archiving mame roms over at notjesus but then they stopped posting before they uploaded anything. Not sure if they uploaded them or not yet.
We also already have the atari collection.
In case you were planning on doing either of these systems.
To the guy from last thread who posted this:
I cant seem to access the DAICON directory, is it still being seeded? Also according to ipfs, the folder is 280 MBs. If you want this added to my tracker, Im gonna need the full show.
ipfs is fucked
If someone else has the file and uploads it, then since it's content addressed, both of you will seed the file. Additionally, if someone requests the hash (even if they don't have the file), then they can receive it from you even if you didn't give them the hash yourself.
Onion routing isn't encryption, tor and i2p encrypt traffic and then rout it. The encryption is not part of the routing protocol and the routing protocol does not rely on encryption - they're 2 completely different things. The routing protocol provides anonymity, the encryption provides encryption. Together they prevent any information leak. Encryption alone only prevents MITM and on-the-fly reads. Routing alone only prevents learning the origin and end of traffic without doing a MITM or on-the-fly read.
Encryption is a fundamental requirement for onion routing. Without it, all nodes along the path you're sending your traffic will know the entire remaining list of nodes in the path, meaning they will always know the destination node and have a fair chance of figuring out the source.
>doesn't even use delay tolerant networking for dealing with speed-of-light latencies measured in minutes between planets
baka desu sempai
When you fetch content, you query nearest nodes first and on, such that large-distance relays work just fine. It is a sane approach to delay tolerance that scales better than looking for a file forever when you don't know if the file even exists.
Huh? I was responding to someone who thinks encryption == anonymity. It doesn't matter if you think layering encryption in Tor or i2p is pointless or not. The point is that IPFS does no such thing.
It can be extended to fit any future transport protocol, IIRC.
The good news is the protocols already exist.
Setting up a virtualized network with something like 15-minute latency between hosts would be a good way to do it, but I'm not sure how you'd set that up in any common virtualization platform.
>Setting up a virtualized network with something like 15-minute latency between hosts would be a good way to do it, but I'm not sure how you'd set that up in any common virtualization platform.
I'm pretty sure pf can simulate packet loss and delay, I see no reason why it couldn't delay 15 minutes and limit bandwidth too
>>51575023$ ipfs get <hash>/<filename>
or$ ipfs resolve <hash>/<filename>
$ ipfs get <filehash>
if you want to do it all by hashes for some reason.
Substitute get for pin, cat etc. as you see fit.
You can just browse through the directory in your browser, or you can use ipfs get <directory-hash> or ipfs get <directory-hash>/<filename>. You can also see a directory's content (filenames and hashes) by ipfs ls <directory-hash>.
ipfs reminds me of tahoe-lafs in a few ways.
I understand they don't serve the same purpose.
Tahoe has the shared datastore and duplication, which ipfs sort of has with the caching, its just not a set amount of distribution.
Tahoe normally doesn't have public gateways, so it's a plus that all ipfs gateways are essentially equal.
Well, I have a ADSL2 router with integrated WiFi (WPA2-PSK). Only my PC is using the network right now.
My PC is connected by wire to another router, which acts as a WiFi receiver - I use that so that my TV can also connect to the network.
What made you stop shilling GNUnet, OP?
Slow as fuck
Buggy as fuck
No chance of a viable GUI in a thousand years
No 3rd party interest
20 years in development, still unusable
Fast as all fuck
GUI is usable
Healthy 3rd party interest
Alpha begun only a year ago, perfectly usable
>mfw ipfs leaks your ip to the other peers
>mfw you are willingly giving "ipfs.io" their ip addresses
>mfw you're literally telling them which illegal files you're about to pirate ("The.Dark.Knight.Rises.2012.720p.BluRay.x264.YIFY.mp4")