Introduction
Project Name: Catalog
Name of the organization or individual submitting the proposal:
Miracle Mathias
Independent developer with 4 years of experience, building web and mobile applications for creative professionals.
Describe Your Project.
Catalog is a personal musical works archival platform built on Sia’s decentralized storage network. It gives artists and producers a single, sovereign home for their entire creative catalog — released and unreleased works alike.
Unlike cloud storage folders or streaming platforms, Catalog is purpose-built for music. Works are organized by the artist under Albums, EPs, Singles, and Unreleased sections. Each piece of music is treated as a living “Work” with a full version history — a rough voice memo, a demo, a final mix, and a mastered release are all versions of the same Work, preserved and downloadable at every stage.
Catalog is non-custodial by design. Each artist holds a BIP-39 recovery phrase that is the sole master key to their storage identity on Sia. Catalog never stores this phrase — it is used exactly once during onboarding to derive an App Key, which Catalog stores securely for future sessions. If Catalog ceased to exist, every file would remain accessible to the artist through Sia’s own tooling using their recovery phrase. The artist owns their data in the most literal sense.
When an artist is ready to release, Catalog connects to a music distributor’s API (such as DistroKid or TuneCore) so they can push a track to Spotify, Apple Music, and other platforms in a few clicks — without leaving Catalog.
Think of Catalog like Git for music — a version-controlled, decentralized archive of everything an artist has ever made, with a publish button that routes to wherever the world hears music. The “main branch” is your released catalog; the feature branches are your drafts and unreleased works. The MVP is a web application serving independent artists and producers who want genuine data ownership over their creative work.
How does the projected outcome serve the Foundation’s mission of user-owned data? What problem does your project solve?
Today, an artist’s music lives in pieces across platforms they do not own: streaming services own the listener relationship, distributors own the delivery pipeline, and cloud drives owned by large corporations hold the actual files. An artist who loses access to any of these accounts loses a piece of their catalog. There is no single place where an artist fully owns their music.
Catalog solves this by making Sia the canonical home for an artist’s work — with non-custodial ownership enforced at the cryptographic level. All audio files are encrypted client-side using the Sia Storage SDK before they are ever transmitted. The indexer coordinates storage but never sees plaintext data. The artist’s recovery phrase, never retained by Catalog, is the only path to derive the keys that unlock their files.
This directly serves the Sia Foundation’s mission: user-owned data in a domain — creative work — where ownership has historically been stripped away from creators by centralized platforms. Catalog brings Sia to a large, underserved audience who have strong personal and economic reasons to care about who controls their files, expressed in terms they already understand: “Your music, your key.”
Are you a resident of any jurisdiction on that list?
No
Will your payment bank account be located in any jurisdiction on that list?
No
Grant Specifics
Amount of money requested and justification with a reasonable breakdown of expenses:
Total requested: $6,500
| Item | Cost |
|---|---|
| Developer fees | $6,000 |
| Infrastructure (hosting, domain, CI) | $500 |
| Total | $6,500 |
All grant funds are paid in USD via ACH or wire. Payments received monthly.
What is the high-level architecture overview for the grant? What security best practices are you following?
Architecture:
-
Frontend: React web application (TypeScript). Artists interact entirely through the browser — uploading files, organizing their catalog, viewing version histories, and triggering distribution.
-
Backend API: Node.js / Express server managing user accounts, Work metadata, version trees, and orchestrating calls to the Sia Storage SDK and distributor APIs. No audio files pass through or are stored on Catalog’s servers.
-
Storage layer — Non-custodial Sia integration via the Sia Storage SDK (`@siafoundation**/sia-storage`):
Catalog implements the SDK’s standard authentication and storage flow:
-
App ID (Catalog-level constant): A unique 32-byte identifier hardcoded into Catalog at launch and never changed. This is Catalog’s application-level identity on the Sia network.
-
Recovery Phrase (artist-held, never stored): Each artist has a BIP-39 recovery phrase — their master key. During onboarding, the artist is shown their recovery phrase exactly once and prompted to store it securely, identical to a crypto wallet setup. Catalog never stores this phrase — it is used only once, at onboarding, to derive the App Key.
-
App Key (Catalog-stored, encrypted): The App Key is a public/private key pair deterministically derived from the combination of the artist’s recovery phrase and Catalog’s App ID. The public key is registered with the Sia indexer during onboarding. The private key is stored encrypted by Catalog for all future sessions, so the artist never needs to re-enter their recovery phrase. If Catalog ceases to exist, the artist can re-derive their App Key from their recovery phrase plus Catalog’s published App ID and access all their files independently.
-
Client-side encryption: All audio data is encrypted by the SDK on the client before upload. The Sia indexer at `sia.storage` coordinates storage but never receives or sees plaintext data. Files are erasure-coded into redundant encrypted shards and distributed across independent storage providers worldwide.
-
Object IDs: Each uploaded file receives a unique Object ID after `upload()` + `pinObject()`. Catalog stores Object IDs in its metadata database to reference each version of each Work. The underlying audio content lives entirely on Sia.
-
Distribution: Integration with DistroKid’s or TuneCore’s API. Artist links their distributor account via OAuth. Release metadata (title, artwork, genre, release date) is collected in Catalog and sent to the distributor on the artist’s command.
-
Authentication: Standard OAuth 2.0 / email-based auth with secure session management.
Security practices:
-
Recovery phrases are never stored by Catalog — only used once to derive the App Key during onboarding
-
App Keys (private keys) stored encrypted at rest using AES-256
-
All audio data encrypted client-side by the Sia Storage SDK before transmission — the indexer never sees plaintext content
-
Object IDs stored in Catalog’s metadata database; no raw audio content cached or persisted on Catalog infrastructure
-
Distributor OAuth tokens stored encrypted at rest
-
HTTPS enforced across all endpoints
-
Regular dependency auditing
-
All code open-source and subject to community review
What are the goals of this small grant? Please provide a general timeline for completion.
Goal: Ship a functional, publicly accessible MVP of Catalog that demonstrates Sia as the storage backbone for a real creative workflow used by independent artists, with a non-custodial ownership model that is accessible to non-technical users.
Timeline:
Month 1 — Foundation
-
User authentication and account system
-
Sia Storage SDK integration: App ID setup, recovery phrase onboarding flow, App Key derivation and encrypted storage
-
Core data model: Works, Versions, Collections (Albums / EPs / Singles / Unreleased)
-
Basic file upload (encrypted via SDK) and catalog organization UI
Month 2 — Core Workflow
-
Version tree: upload new versions of an existing Work, view full version history, download any version
-
Metadata management: title, cover art, notes, version labels
-
Distributor API integration (DistroKid or TuneCore): link account via OAuth, push a release
-
Catalog browsing and organization UI (search, filter by type)
Month 3 — Polish and Launch
-
End-to-end release flow: from Sia-stored file to live on Spotify/Apple Music
-
Onboarding flow communicating the ownership model clearly to non-technical artists, including recovery phrase education
-
Beta testing with a small group of independent artists
-
Bug fixes, performance improvements, public launch
Who is the target user for your project?
Independent artists and producers who make original music — particularly those already navigating the self-release landscape (using DistroKid, TuneCore, or similar distributors) who want genuine ownership of their catalog. The initial audience skews toward bedroom producers and independent artists who are technically comfortable enough to care about where their files live, but do not want to manage raw Sia infrastructure themselves. Catalog’s non-custodial model delivers real data sovereignty without requiring any knowledge of blockchain, wallets, or storage protocols.
What are your plans for this project following the grant?
The grant covers the core web MVP. Following successful delivery, planned developments include:
-
Collaboration feature — Shared Works with a branching version tree tracked across multiple contributors. A producer shares a beat with a vocalist; both can upload new versions building on any prior version; every contribution is preserved on Sia with full attribution. Each collaborator’s Sia identity holds their own copy of the versions they contributed. Shared projects appear in a dedicated section of each collaborator’s Catalog.
-
Mobile app — A native mobile experience allowing artists to manage their catalog, upload recordings, and trigger releases from their phone.
-
Recording app integrations — Direct connections to popular mobile recording tools (Voloco and similar) so recordings flow into an artist’s Catalog automatically, without manual file export and re-upload.
-
Sustainable model — Monthly subscription pricing where Catalog covers Sia storage costs, making decentralized storage invisible and accessible to non-technical artists.
Potential Risks That Will Affect The Outcome Of The Project:
-
App ID immutability: Catalog’s 32-byte App ID must never change — changing it would alter all users’ derived App Keys and sever access to their data. Mitigation: the App ID will be generated before launch, documented publicly in the repository, and treated as a permanent constant. No rotation mechanism will be built.
-
Sia Storage SDK maturity: The SDK is in active development and may introduce breaking API changes. We are building on it intentionally to support the Sia Foundation’s ecosystem growth. The storage integration layer will be abstracted behind a service interface so SDK-level changes can be adapted without rewriting application logic.
-
Distributor API access: DistroKid and TuneCore may not have fully public APIs — access may require a partner agreement. Mitigation: begin outreach in Month 1; if blocked, the release flow can degrade gracefully to pre-filling the distributor’s web upload form in the MVP.
-
Scope: The collaboration and mobile features are intentionally deferred post-grant to keep the MVP focused and deliverable on schedule.
Development Information
Will all of your project’s code be open-source?
Yes. All code will be open-source under the MIT license.
Leave a link where code will be accessible for review:
Do you agree to submit monthly progress reports?
Yes. Monthly progress reports will be submitted to the Sia Foundation forum as required.
Contact Info
Email: [email protected]
.