IPFS builds on top of IPLD by describing a format for data to represent files and combines it with it's p2p network to publish and load files. Unlike BitTorrent, if two datasets in IPFS contain the same data, it's easy to share peers between them to find data and to deduplicate storing this data on disk.

IPFS has a couple of approaches to links. Primarily they use Content Identifiers, AKA CIDs, with two ways of turning them into links. In a lot of places they make use of /ipfs/{CID}/ style URLs which are made to be easy to convert to paths within IPFS gateways and mirrors the underlying Libp2p multiaddress format which uses paths with a "type" prefix. However, more recently IPFS has been using ipfs://{CID} URLs which have had some growing pains based on the encoding of the CID. Initially, IPFS was using the CIDv0 spec that is based on the Base58 Bitcoin encoding for the data which is case sensitive. This caused problems with loading IPFS URLs in browsers since the hostname portion of a URL is case insensitive and generally gets converted to lowercase when parsed within a browser. From that lesson, they started migrating to CIDv1 which defaults to base32 encoding that uses all lowercase characters. There's still some growing pains when people try to use CIDv0 style links that are the default in order tools, so if you have a URL that starts with Qm, you might want to update it with a CID inspector In addition to IPFS links, there are also IPNS links which can make use of public keys or DNS names instead of CIDs, like ipns://{Public Key or DNS}/. The DNS functionality comes from the DNSLink standard.

IPFS is similar to bittorent in that it operates on Merkle Trees, but instead of grouping data together under a single infohash, it focuses on addressing each chunk of data individually.

IPFS uses a data format called IPLD (Interplanetary Linked Data) which takes Merkle Dags to the next level by creating a powerful data model with different "types" and ways of traversing data.

IPFS builds on top of IPLD by describing a format for data to represent files and combines it with it's p2p network to publish and load files.

Unlike BitTorrent, if two datasets in IPFS contain the same data, it's easy to share peers between them to find data and to deduplicate storing this data on disk.

Like BitTorrent, IPFS datasets can be referenced using the hash of the root of their merkle dag which they call the CID (Content IDentifier), and in order to change any data, you will need to generate and share a new CID. Unlike bittorrent the formats of the hashes used for CIDs are flexible and the same bit of data can use different hashes. The different hash functions and encodings are defined in the multiformats specification.

Another advantage of IPFS over BitTorrent is that large datasets can be handled by sparsely loading just the chunks that you need as you traverse the merkle dag. E.g. if you have millions of files, but only need one, you can traverse the graph just accross the nodes that point to that file and ignore the rest of the dataset. However, this sparseness can be slower since you will need to wait for individual nodes along the path to be fetched from the network as you traverse the dataset.

IPFS stores data with "repositories" or "block stores" which can be configured to store data in various formats. These formats are typically very different from the file data they represent so it's a lot harder to mirror an IPFS dataset directly to the filesystem, and doing so will require storing data both inside IPFS's blockstore and on your filesystem, potentially duplicating the amount of storage necessary for using with other apps. Generally, the "blockstore" handles storing binary data which represents the encoded IPLD nodes or raw buffers so it can be very space efficient whe combined with deduplication.

Another advantage of IPFS over BitTorrent is that large datasets can be handled by sparsely loading just the chunks that you need as you traverse the merkle dag. E.g. if you have millions of files, but only need one, you can traverse the graph just accross the nodes that point to that file and ignore the rest of the dataset. However, this sparseness can be slower since you will need to wait for individual nodes along the path to be fetched from the network as you traverse the dataset.

What's interesting is that in addition to TCP and UDP for connecting peers, it can seamlessly integrate other transports like QUIC which can have better perfromance and security guarantees than TCP and WebRTC which can easily bridge web browsers to the rest of the network. In fact, there's even support for connecting peers over a device's Bluetooth connection.