IPFS Storage

Content-addressed, self-hosted, streaming IPFS storage — no external gateway required.

What is a CID?

A CID (Content Identifier) is a cryptographic hash of your data. The same bytes always produce the same CID — making it a permanent, verifiable address.

Glashaus supports both CID formats:

CIDv0: Legacy format: Qm… (34 chars)
CIDv1: Modern format: bafybei… (59 chars)

Content-addressed

Same bytes, same CID, always. The address IS the proof of content.

Immutable

CID is a cryptographic hash. Content cannot change without changing the CID.

Globally unique

CID is the address AND the proof of integrity. No central authority needed.

Self-verified

Anyone can verify the bytes match the CID. No certificate authority required.

Self-Hosted Gateway

Glashaus runs its own IPFS gateway inside Next.js. There is no external gateway dependency — content is streamed directly from S3 storage without leaving our infrastructure.

Gateway URLs:

bash

https://glashaus.xyz/api/gateway/ipfs/<CID>
https://glashaus.xyz/api/gateway/ipfs/<CID>/path/to/file.jpg

HTTP Range support

Only fetches the bytes you asked for (RFC 7233). Save bandwidth by requesting only what you need.

256 KB peak RAM

Streaming blocks regardless of file size. Even 10 GB files stream smoothly with minimal memory.

Path resolution

Directory traversal via DAG-PB: /ipfs/<CID>/images/logo.png resolves to the correct file.

Parallel fetch

Up to 20 concurrent S3 block requests. Fast, efficient retrieval without overwhelming storage.

How Blocks Are Stored

Files are chunked into 256 KiB UnixFS blocks. Each block is stored as blocks/{cid} in S3. The blockManifest on every Pin tracks the raw leaf CIDs.

Upload

Your file is chunked into 256 KiB blocks via ipfs-unixfs-importer. A DAG-PB tree is built from these blocks.

Store

Each block is written to S3 at blocks/{cidString}. The root CID is calculated and stored in MongoDB.

Retrieve

The gateway reassembles blocks on-the-fly using HTTP Range requests. Only the requested byte range is fetched.

DHT Announcement

Content is durably stored (S3 + Mongo) on upload. DHT announcement is explicit and optional — use the provide endpoint to announce your CID to the distributed hash table.

Fire-and-forget endpoint:

bash

curl -X POST https://glashaus.xyz/api/ipfs/routing/provide?arg=<CID>

DHT Best Practices

DHT announce is slow (~10–14 seconds) and best-effort. Your content is live and accessible via the Glashaus gateway immediately after upload, regardless of DHT status. Other peers can discover your CIDs only after they appear on the DHT.

Inspect via Console or MCP

Query the IPFS node using either the Glashaus Console (/ipfs slash commands) or the MCP server (for Claude Desktop).

IPFS node inspection commands across the Console and MCP interfaces
Action	Console slash	MCP tool
Node identity	`/ipfs id`	`ipfs_id`
Connected peers	`/ipfs peers`	`ipfs_swarm_peers`
Pinned CIDs	`/ipfs pins`	`ipfs_pin_ls`
Find DHT providers	`/ipfs findprovs <cid>`	`ipfs_routing_findprovs`
Announce CID	`/ipfs announce <cid>`	`provide endpoint`