Migrate Cover Art Archive storage to Sia decentralized network

MusicBrainz Development
,
1

I’ve been contributing to MusicBrainz recently and noticed that Cover Art Archive has pretty consistent availability issues — 500 errors, slow image loading, timeouts. This got me thinking about the underlying infrastructure.

Cover Art Archive is hosted on Internet Archive, which itself has been under significant strain lately — DDoS attacks, legal pressure, and general instability. For a static file collection like cover art, this seems like a fragile dependency.

I’d like to propose exploring Sia (sia.tech) as an alternative storage backend for CAA. Here’s why it makes sense:

  • Cover art is static files — perfect fit for decentralized object storage
  • CAA’s total storage footprint is likely in the tens of terabytes range, which on Sia costs a few dollars per month
  • Sia provides redundancy without relying on a single organization’s infrastructure
  • It’s censorship-resistant, which aligns well with an open, community-driven project
  • No single point of failure — if one host goes down, files remain accessible

The migration path would involve uploading existing images to Sia and updating the CDN layer to serve from there instead of archive.org. The API would remain unchanged from the user perspective.

Has anyone explored this direction before? Would love to hear thoughts from the team.

2

This looks like an interesting direction worth investigating. I’d just distinguish between the storage layer and the CAA service itself.

Sia could potentially be a good storage backend: cover art is largely immutable, redundancy across independent hosts is attractive, and an S3-compatible interface could keep the CAA largely independent of the underlying storage technology.

However, decentralised storage does not by itself solve public HTTP access, caching/CDN, monitoring, recovery, or long-term archival. I’d also be cautious about treating redundancy within Sia as a complete archival strategy - an independent backup/exit path would still be valuable.

So rather than “move CAA to Sia”, I’d suggest looking at Sia as one possible storage backend for CAA, while keeping the API and service layer storage-agnostic.

A small proof of concept with a representative subset of CAA could then measure latency, availability, bandwidth/egress costs, operational complexity, and recovery. If those numbers look good, it could become a very interesting option.