Integrate IPFS for Decentralized Storage

This skill builds robust decentralized storage integrations with IPFS, covering content addressing, pinning strategy, and Web3 application integration. Content addressing follows CID versioning conventions (CIDv0 for legacy systems, CIDv1 for new implementations), with proper multihash-format handling, CID validation and format conversion, and content deduplication that falls naturally out of hash-based addressing. Network architecture is designed for distributed availability across multiple pinning nodes, with gateway fallback for reliable retrieval and consideration of peer discovery, NAT traversal, and firewall constraints.

Use it when integrating IPFS as a storage layer for a Web3 or decentralized application that needs reliable pinning across multiple services and content-integrity verification. It is not meant to run without redundancy: the reliability guidance requires multiple pinning services, gateway failover, and pin-status monitoring, since a single-pin, single-gateway setup defeats the purpose of decentralized storage.

Given a file to store, an upload client wraps ipfs.add with configurable pinning, a CID version defaulting to 1, a hash algorithm defaulting to sha2-256, and optional directory wrapping, then optionally propagates the resulting CID to a set of external pinning services. Retrieval races a timeout against streaming the content by CID, falling back to public gateways if the primary node fails. A pinning manager pins to every configured service in parallel (POSTing the CID and metadata with bearer-token auth) and checks pin status across all services in parallel as well. A Web3 integration pattern stores file metadata on-chain: a Solidity contract computing a file ID via keccak256 over the IPFS hash, uploader, and timestamp, recording it in a FileRecord struct with the filename and size, and emitting a FileStored event.

{
  "API": {
    "HTTPHeaders": {
      "Access-Control-Allow-Origin": ["*"],
      "Access-Control-Allow-Methods": ["PUT", "POST", "GET"]
    }
  },
  "Addresses": {
    "Swarm": [
      "/ip4/0.0.0.0/tcp/4001",
      "/ip6/::/tcp/4001",
      "/ip4/0.0.0.0/udp/4001/quic"
    ],
    "API": "/ip4/127.0.0.1/tcp/5001",
    "Gateway": "/ip4/127.0.0.1/tcp/8080"
  },
  "Discovery": {
    "MDNS": {
      "Enabled": true
    }
  },
  "Datastore": {
    "StorageMax": "10GB",
    "StorageGCWatermark": 90,
    "GCPeriod": "1h"
  }
}

Health monitoring checks node connectivity, active peer count via swarm.peers(), repo storage stats, and gateway responsiveness against a known CID. Performance practices layer on top: chunking for large files via the chunker option, connection pooling across operations, local caching of frequently accessed content, and progressive loading for large datasets - alongside security practices (file type and size validation before upload, access controls on private gateways, encryption of sensitive data before storage) and error handling with exponential backoff and graceful handling of network partitions.

Web3 and decentralized-app developers building on IPFS who need a production-grade storage layer - node configuration, multi-service pinning with status checks, on-chain file records, and health monitoring - rather than a single-node, single-pin proof of concept.