Briefing

Specialist note

File Storage with IPFS and Blossom

This is optional specialist material. It covers two separate ideas: IPFS for content-addressed data, and Blossom for media upload and retrieval in a Nostr-oriented workflow. [R1][R2]

Back to handbook Go back

Sections

Use this page as a guide: separate IPFS from Blossom first, then compare them and keep the limits visible.

IPFSContent-addressed storage and CIDs. BlossomBlob storage with Nostr-style authorization. Compare againstCheck the incumbent storage options. LimitsTrade-offs and operational constraints.

IPFS

IPFS uses content identifiers, or CIDs, so the address comes from the content itself rather than a server location. [R1]

Core mechanism

  • The content is hashed to create a CID. [R1]
  • Different content gives a different CID. [R1]
  • The same content usually gives the same CID under the same settings. [R1]
  • The CID points to content rather than a specific server. [R1]

Why people care about it

  • It makes integrity checking straightforward. [R1]
  • It supports distribution across multiple nodes. [R1]
  • It can reduce dependence on one server when distribution is already in place. [R1]
  • It is often a better fit for content than a plain location URL alone. [R1]

Blossom

Blossom is a specification for storing blobs on media servers, with Nostr keys used for identity and signed events used for authorization. [R2]

Core mechanism

  • Blobs are addressed by their sha256 hash. [R2]
  • Servers expose HTTP endpoints for upload, retrieval, and listing. [R2]
  • Users sign authorization events with Nostr keys. [R2]
  • It is designed for media storage and retrieval rather than as a full replacement for general file hosting. [R2]

Why people care about it

  • It gives Nostr users a practical media layer. [R2]
  • It separates identity from the storage server more cleanly than a single platform can. [R2]
  • It is useful where uploads and retrieval matter more than long-term archival guarantees. [R2]
  • It keeps the discussion on a specific storage workflow rather than a vague decentralisation claim. [R2]

What to compare it against

The value of each approach depends on what problem you are trying to solve.

IPFS compared with

  • Plain HTTP URLs on a conventional server. [R1]
  • CDNs or mirrored file hosting when simple availability matters more than content addressing. [R1]
  • Local-first apps that can avoid a distributed retrieval layer. [R1]

Blossom compared with

  • Ordinary media upload endpoints. [R2]
  • Centralised social platforms with built-in media hosting. [R2]
  • Other relay-linked storage systems when identity and moderation are the main constraints. [R2]

Limits and trade-offs

What critics are right about

  • Availability depends on pinning and node retention. [R1]
  • Content addressing differs from guaranteed permanence. [R1]
  • Access patterns can be more complex than plain HTTP. [R1]
  • Public gateways can reintroduce points of control. [R1]

Boundaries

  • It depends on media servers staying reachable. [R2]
  • Moderation and abuse handling still matter. [R2]
  • It is an ecosystem layer rather than a universal storage solution. [R2]
  • It works best when paired with a clear identity and relay model. [R2]

Primary sources

Further reading

  • Read the Nostr page to see how Blossom fits into a signed-event communication system.
Back to handbook Go back Next topic: Nostr

Sources

References