IPFS distinguishes content addressing from persistence. Nodes may cache material they fetch and later remove it during garbage collection. Pinning tells a node to retain selected data; it does not make every other node keep a copy. A paid pinning service moves that responsibility to another operator, whose continued operation and funding still matter. Decentralized storage is therefore an operational arrangement, not a property obtained by publishing a hash.

Consider an illustrative community archive with three copies, all paid for by the same expired card. Counting three replicas conceals one shared failure. A better inventory records operators, locations, renewal responsibility and who can restore the archive. Periodically recover it from a different machine while the usual uploader is offline. Include referenced images and attachments in that test. This gives evidence of usable redundancy rather than evidence that a dashboard once accepted an upload.

Indefinite retention requires an ongoing resource plan even when the address itself remains valid indefinitely.

Filecoin's storage-market specification separates discovery, negotiation, publication and activation. Clients and providers agree to terms, lock the relevant funds and publish a signed deal; data is then handled by the storage subsystem. In that documented workflow, an agreement being proposed or published is not identical to the data having reached active storage. The specification is a concrete protocol model, not a description of every storage product or later application built on Filecoin.

Follow an illustrative archive upload through each stage. Record the requested retention interval, the data commitment, the selected provider and the point at which storage becomes active. Then simulate expiration: who renews the arrangement, supplies funds or creates a replacement copy? A token incentive can help enforce a defined obligation, but it cannot define an obligation that the application never arranged.

For a useful comparison between services, examine observable state transitions and recovery responsibilities instead of equating an accepted transaction with a complete long-term preservation strategy.

The Filecoin retrieval-market specification describes locating a provider, querying terms, negotiating a transfer and, in its documented payment-channel flow, exchanging payment vouchers as data moves. Some data may need to be unsealed before transfer. Much of this coordination occurs outside the chain. The important architectural distinction is that evidence of retained storage does not, by itself, demonstrate an application's download experience.

An archive serving occasional disaster recovery and a website serving images during a page load have different requirements. For a teaching exercise, give each the same intact stored file but a ten-minute first-byte delay. The archive may meet its stated recovery objective while the website is unusable. Measure location lookup, first byte, full-file completion, integrity verification and decryption separately. Also test a second retrieval path with the preferred gateway unavailable.

Describe the tested configuration and date; do not turn one successful download into a blanket claim that all providers, regions or future requests have equivalent availability.

IPFS encrypts connections between peers, but that is different from encrypting the files they exchange. Its documentation explains that content identifiers and provider information can be publicly observable. An unguessable-looking CID should not be treated as an access-control policy. Encrypting sensitive material before distribution can protect its contents while leaving some network metadata visible.

Imagine preserving a private research notebook for ten years. Replicating ciphertext protects against losing a storage machine, but losing the only decryption key still makes the notebook unusable. Conversely, distributing the key with the public file defeats the intended confidentiality. A preservation plan must therefore test both byte recovery and authorized key recovery. Also consider what filenames, directory structure and access patterns reveal. Once another party has obtained plaintext or a key, changing a gateway's permissions cannot recall their copy.

The practical lesson is to design retention, retrieval, confidentiality and revocation together, while documenting which guarantees each layer can actually provide.