Meta: Apex as a Celestia-backed Developer Storage Platform

[tac0turtle]

Summary

Tracking issue for exposing Celestia blob storage through familiar developer interfaces.

The core idea: Apex already indexes and caches Celestia blobs in SQLite. By adding a write path and a generic blob abstraction, we can layer multiple storage APIs on top.

Prerequisites

• Meta: Blob Submission Pipeline #44 — Blob Submission Pipeline (write path — keyring, nonce, tx lifecycle)

Storage APIs

• Feature: S3-Compatible Object Storage API #40 — S3-Compatible Object Storage API
• Feature: Git Remote Storage via Apex #41 — Git Remote Storage via Apex
• Feature: Celestia-backed NPM Registry #42 — Celestia-backed NPM Registry

Architecture

Protocol-specific API (S3 / Git / npm)
↓
Object ↔ Blob chunking + metadata
↓
SQLite index/cache
↓
Blob Submission Pipeline (#44)
↓
Celestia DA

Dependency graph

#43 (this — storage platform)
├── #44 (blob submission pipeline)
│   ├── #4  (tx client decision)
│   ├── #9  (keyring/signing)
│   ├── #5  (multi-account)
│   ├── #8  (nonce management)
│   ├── #18 (rate limiting)
│   └── #19 (tx confirmation)
├── #40 (S3 API)
├── #41 (Git remote)
└── #42 (NPM registry)

The key enabler is a common content-addressed blob storage abstraction that handles chunking, reassembly, and metadata tracking. Once that and the submission pipeline exist, each protocol adapter becomes a relatively thin translation layer.