lkjhgfdsa57

FreeNet is a distributed key/value store. It can be used to store files by storing the contents of the file under a key that is the hash of the file content. Generally you operate on Freenet at the level of keys and values.

ZeroNet operates at the level of sites. Sites contain multiple files. Seeding of data happens at the site level.

You could implement ZeroNet on top of Freenet but implementing Freenet on top of ZeroNet wouldn't make much sense.

When inserting new data, Freenet pushes data out to nodes. ZeroNet pulls data from requestors. With Zeronet you can't disconnect your node until other nodes have a complete copy if you want the data to remain available. It is difficult to tell when it is safe to do this. With Freenet the data isn't stored on your own node, it is pushed out to other nodes when first inserting. When the insert completes you know you can safely turn off your node. The data remains available.

ZeroNet does not pay you for hosting. Maidsafe is more file storage, ZeroNet is more about distributed site sharing. ZeroNet could be implemented on top of Maidsafe but not vice versa. There's also the fact that ZeroNet works today, has been working for a year or two, whereas Maidsafe is still in test stages.

I think IPFS would make a good backing store for ZeroNet. Rather than storing files on the filesystem of the user they could be stored in IPFS.

ZeroNet is better at dealing with such sites now but it's still problematic when a site grows past a threshold where requestors need to be prompted to increase the size. Nodes that are just seeding don't automatically seed the changed site since they don't respond to the size change request.

One way of dealing with it is to make the images "Optional content". This means they are not sent to requestors of the site immediately - they are requested only when specifically wanted. Users can choose to seed optional files - in which case they'll mirror them all - or they only seed the ones they've looked at. Optional files don't count towards site size limits.

All sites that viewed an existing site contain a copy of it and share the data. There is a "thundering herd" problem of multiple requesters for the site initially being distributed but once that's done then multiple nodes will have it and can seed it. The original site shutting down is no problem at that point.

IPFS shares the same problem and knowing when it's safe to shut down a node in both IPFS and ZeroNet is difficult.

Freenet solves this by having an insert of data sent directly to peers immediately. The site isn't stored on the inserting node. Once the insert is done it's safe to close the node and the content is still available.

ZeroNet doesn't use bittorrent for file transfers. The bittorrent network is only used for the DHT to map site addresses to IP addresses (or TOR hidden service names).

File transfer is done over a service that ZeroNet runs on a particular port with its own protocol.

Have you left the ipfs daemon running? Do any errors show in it? Does this show any connections:

    ipfs swarm peers

The IPFS daemon installation will result in an internet facing service being installed. It's not "web accessible" but accessible using the protocols that IPFS uses. Other nodes will contact your instance and communicate with it.

Your node will share its external IP address, and all internal IP addresses configured on the machine it is running with all other IPFS nodes.

You can remove the content after publishing but then other nodes won't be able to retrieve it. If you know the other party has received the content you can use IPFS commands to remove it and eventually, as nodes garbage collect their content, it will go away. This assumes no other node decides to permanently pin your content before your remove it.

You have to have the daemon running for as long as required for other parties to retrieve the content. If you can get another node to 'pin' the content you can shut your node down when that node has retrieved the data.

You are not anonymous. If you share the hash of the content then any IPFS user can go from that hash, to your node hash and from there to all IP addresses configured on your machine with a couple of IPFS commands for as long as you have the content share by your IPFS daemon.

> Given a URL for an HTTP resource, how do you know it does not contain child porn before you retrieve it?

As clueless404 stated, on the http web you don't automatically seed the content that you accidentally retrieved. On IPFS you're distributing it.

As an example, another posted here provided an IPFS link to resources, some of which are a copyright violation in some regions. In IPFS you can discover the nodes that are seeding it:

    $ ipfs dht findprovs ...contenthash...
    QmfWQHVazH6so9p27z27rr8TJSdBFGpH7hunDcaZ1EAQ2c
    ...

These are the node id's sharing the content. You can find all the IP addresses published by the nodes, including private ones:

    $ ipfs id ...nodehash...
    {
      ...,
      "Addresses" : [
        "/ip4/127.0.0.1/tcp/4001/ipfs/...hash...",
	"/ip4/192.168.1.5/tcp/4001/ipfs/...hash...",
	"/ip4/172.17.0.1/tcp/4001/ipfs/...hash...",
	"/ip4/1.2.3.4/tcp/4001/ipfs/...hash..."
      ],
      ...
    }

If your node accidentally retrieved a hash containing content that was illegal or otherwise bad your physical IP is easily discoverable.

A database of bad hashes is easily calculated given existing content using:

    $ ips add -n foo.mp4
    added ...hash... foo.mp4

This generates a hash for a file without uploading it to IPFS. You can then use findprov to see if anyone is sharing it.

Freenet encrypts content, parcels it into chunks and distributes those chunks amongst peers. Does this meet your definition of "distributed content farm that might place CP on my computer"?

I'm curious because I've seen objections to Freenet for that reason yet the content stored is in no way CP. No bad content can be reconstructed from the data in your store. Not just because it's encrypted but because you'd be holding random small chunks of the file.

The vast majority of Freenet content is probably about Freenet itself (Web of trust data, Sone traffic, FMS traffic), not bad content.

Redacted case notes from a Freeneter acting as an expert witness on a case: https://asksteved.com/freenet-case/case-redacted.pdf

Freenet is facing this. They got a 25k donation from duckduckgo and for the last couple of months debate on how to spend it, whether the previous paid developer gets to continue, etc. They're running a poll at the moment to decide on projects and priorities. The developer mailing list is the details.

Seems to fit the same usecase as Freenet USK keys: https://wiki.freenetproject.org/Updateable_Subspace_Key

They allow the holder of the private key to add new data and clients who know the public USK can get notified of updates. In Freenet you can also get the old versions of the data for as long as they stay around on the network.

Onioncat [1] provides this functionality for Tor and I2p. You get an Ipv6 address and it works with any application that supports IPv6. The address is based on the hidden service (in the case of tor) backing the onioncat instance.

[1] https://www.onioncat.org

Don't forget Freeenet https://www.freenetproject.org/, which has the goal of anonymity. IPFS isn't anonymous and the IP address of users pinning the content is easily discoverable.

Freenet has at least one site that lists magnet hashes and inserts some of the torrent content directly into the network.

The FMS decentralized message system in Freenet is spam resistant using a web of trust. Some Frost users have recently migrated to using it more since the frostbite bug caused problems

Freetalk is dead/stalled due to development issues.

ksk@tvtorrents on Freenet mirrored kat tv specific magnet links and files but they've stalled due to the kat api being down.

There is a freenet site that lists torrents, magnet links and inserts the file into Freenet but they use the kat API so I assume it's dead too. It shows that a Freenet based site could be workable though.