AIOZ Pin Knowledge Hub
Persistent data plays a critical role in decentralized applications. From distributed storage to pinning mechanisms, ensuring that files remain available is fundamental for building reliable systems. Here we explore the technologies and practices that help developers manage and maintain decentralized data.
Explore how pinning, distributed storage, and decentralized infrastructure work together to keep data reliably available.
Go to AIOZ PinLatest from AIOZ Pin
The newest guides, updates and reports about AIOZ Pin and related infrastructure across the AIOZ ecosystem.
Content Moderation on IPFS: What Actually Happens
Pinning services can remove their own copy of a file. They cannot remove it from IPFS. Here is exactly what a takedown does and does not accomplish.
IPFS Transports: TCP vs. QUIC Explained
libp2p connections can run over more than one transport. Here is exactly what changes with QUIC instead of TCP, and why IPFS dials both at once.
GossipSub: How IPFS's PubSub Layer Actually Works
The DHT answers who has a CID. GossipSub answers a different question: how do peers push real-time updates to everyone listening, without a lookup at all.
All
IPFS
Case Studies
Announcement
DNSLink: Pointing a Domain Name at IPFS Content
DNSLink lets a regular domain name resolve to IPFS content using nothing but a DNS TXT record. Here is the exact syntax and how it compares to IPNS.
IPNS: Mutable Pointers to Immutable IPFS Content
IPNS solves the one thing a CID can't: staying the same address while the content behind it changes. Here is how a name gets derived, signed, and updated.
How IPFS Verifies Content Without Trusting the Gateway
IPFS content verification lets a client check retrieved data against its CID directly, without trusting whichever peer or gateway sent it. Here is how.
libp2p: The Networking Layer Underneath IPFS
IPFS libp2p is the peer-to-peer networking stack that DHT lookups and Bitswap transfers actually run on. Here is what it handles: identity, security, and NAT.
UnixFS: How IPFS Represents Files and Directories
The raw IPFS Merkle DAG has no concept of a file or folder. UnixFS is the format that adds one. Here is exactly how, node type by node type.
IPFS Garbage Collection: What Unpinning Actually Does
Unpinning an IPFS file does not delete it immediately. Here is exactly what pin types exist, what garbage collection actually removes, and when.
IPFS Content Addressing vs. Location Addressing
Content addressing vs location addressing is the core design split between IPFS and HTTP. It fixes tampering and link rot, but creates a new problem: discovery.
How IPFS Finds and Retrieves Files: DHT and Bitswap
IPFS splits content retrieval into two jobs: a DHT finds who has your file, Bitswap fetches it. Here is exactly how provider records and want-lists work.
How IPFS Splits Files: Fixed vs. Content-Defined Chunking
IPFS defaults to 256 KiB fixed-size chunks, but also ships Rabin and Buzhash content-defined chunkers. Here is why the choice affects deduplication.
Anatomy of a CID: Decoding an IPFS Identifier
An IPFS CID is not a random string. It encodes a version, a codec, and a hash algorithm plus digest. Here is how to decode a real CID piece by piece.
How IPFS Shards Large Directories: The HAMT, Not a B-Tree
IPFS does not use a B-tree for large directories. It uses a HAMT, a Hash Array Mapped Trie. Here is exactly how it shards a folder once it outgrows one block.
How IPFS Really Works: Merkle DAGs, Chunking, and Routing
How does IPFS work under the hood? Every file becomes a Merkle DAG of hash-linked blocks, found via a DHT and moved with Bitswap. Here is the full path.