Musiquay — Vision

Musiquay (pronounced "music key") — the digital home the music scene never had.

The Problem

The music industry's digital infrastructure is broken in two fundamental ways.

The money problem. Centralized streaming platforms dilute artist compensation through opaque, pool-based royalty models. Artists are not paid by the people who actually listen to them. Subscription revenue is pooled and redistributed based on total platform-wide play share — a system that structurally favors mega-artists and punishes independents. The platforms take their cut first, always.

The scene problem. Music doesn't happen in isolation. Behind every track there's a producer, a mixer, a mastering engineer. Behind every show there's a venue, a promoter, a sound tech, a lighting rigger, road crew. Behind every release there's a designer, a photographer, a filmmaker. The current digital landscape treats music as a consumer product — a transaction between "artist" and "listener" mediated by a corporation. It ignores the vast, interconnected ecosystem of people who make music happen. These people have no shared digital space. No professional network that understands their world. No place they can all call home.

And the platforms that do exist? They lock everyone into proprietary silos. Your playlists, your connections, your listening history, your professional network — all trapped behind corporate walls, extracting value from the community that created it.

The Vision

Musiquay is the Bandcamp the indie scene always dreamed about.

Social by design. Decentralized by architecture. Built on the Nostr protocol. Open source. Foundation-governed. A digital home for every single person in the music ecosystem — artists, listeners, venues, tech staff, promoters, labels, agents, managers, road crew, riggers, producers, mixers, mastering engineers, designers, illustrators, photographers, filmmakers. Every fucking one.

Music unites all of these people. Musiquay gives them a place to find each other, work together, and build something that belongs to them — not to shareholders.

Publishing music on Musiquay is a statement. It's not just a distribution choice. It's an ideological act — a declaration that music belongs to the people who make it and the communities that sustain it. A refusal to feed the machine. A fuckall to the dirty industry.

Core Principles

1. The scene is the platform. Musiquay is not an artist-to-listener storefront. It is a network for the entire music ecosystem. A venue listing its upcoming shows creates value. A promoter connecting with artists creates value. A photographer sharing gig shots creates value. A sound engineer's profile and body of work creates value. The network effects come from the scene, not just the music.

1. Decentralization first. Musiquay is not a traditional SaaS product with a monolithic backend. It is a UI layer and relay infrastructure for the Nostr event network. Anyone can run their own relay, host their own media, and retain full ownership of their identity and data. Your identity is a cryptographic keypair that you own — not an account on someone else's server.

1. Direct compensation. Listeners pay artists directly for what they actually listen to. No opaque royalty pools. No intermediary deciding who gets paid. If you listened to 60% indie jazz and 40% punk this month, that's exactly where your money goes.

1. Open source, foundation-governed. The project operates as a foundation, not a startup seeking an exit. The codebase is open source. Sustainability comes from donations and institutional sponsors, not from extracting value from users or artists. There is no equity. There is no venture capital. There is no exit strategy.

1. Radical transparency. Revenue share percentages are public. Foundation operating costs are public. When someone sets their contribution to 0%, everyone can see it. Sunlight is the best disinfectant.

1. Originals only. Like Bandcamp, Musiquay is for original music. Artists publish their own work. This is a platform for creators, not a repository for ripped content. Takedown processes and content moderation policies will be defined as the project matures, but the principle is clear from day one: this is a home for people who make music, and the music they make.

1. Protocol-level guarantees. Identity, playlists, subscriptions, permissions — these are all handled at the Nostr protocol level using cryptographic keys, not by application-layer access control that a single company controls.

What Musiquay Is

• A home for the music scene — artists, listeners, and every professional role that makes music happen, all with first-class identity and discoverability.
• A Nostr relay optimized for music and scene events.
• A web and mobile UI for the entire community to interact with the network.
• A media layer (Blossom servers) for audio storage and delivery.
• A payment layer using Lightning Network for instant, direct micropayments.
• A foundation that maintains the software, operates reference infrastructure, and serves the ecosystem.

What Musiquay Is Not

• Not a walled garden. Users own their keys and can interact with any compatible relay or client.
• Not a DRM platform. The goal is not to make music un-rippable — that battle was lost decades ago. The goal is to make paying artists so frictionless that it becomes the default.
• Not a blockchain project. While Lightning Network (a Bitcoin Layer 2) is used for payments, the core value proposition is the distributed event system and the scene network, not cryptocurrency speculation.
• Not a startup. There is no equity, no venture capital, no exit strategy. Musiquay is infrastructure for music, governed as a public good.
• Not positioning against anyone. Musiquay has its own vision. It's not an "alternative to X" or a "competitor to Y." Other projects in the space are doing their own thing. This is ours.

The Name

Musiquay = music + quay.

"Quay" is pronounced "key" — as in the key to music, and as in the cryptographic keys that underpin the entire system. A quay is also a wharf, a place where things arrive and depart — fitting for a relay network where events flow between participants.

The domains are owned and secured.

Long-Term Aspiration

A world where:

• Any artist can publish original music to an open network and get paid directly by their listeners.
• Any listener can build a library, create playlists, and discover music without being locked into a single platform.
• Any venue, promoter, engineer, designer, or crew member can build a professional presence in the same space where the music lives.
• The entire scene — from bedroom producers to festival headliners, from local sound techs to touring road crews — has a digital home that belongs to them.
• Any developer can build clients, tools, and integrations on top of open protocols.
• The infrastructure is sustained by the community it serves, not by advertising or data extraction.

Music has always been about community. It's time the infrastructure reflected that.

Guiding Ideas

Validation Without Bureaucracy

Musiquay's credits system doesn't require official confirmation to be useful. The system is designed to embrace ambiguity rather than demand certainty.

• Unconfirmed credits are still valuable. A fan uploading credits from a CD booklet creates structured, queryable data even if no participant confirms it. "This album lists Engineer X in the liner notes" is already better than nothing.
• Confirmation is signal, not gate. Whether a credit has 0 confirmations or 5 attestations, it exists on the protocol and contributes to the scene graph. Confirmation amplifies trust, but absence of confirmation doesn't delete the credit.
• The scene self-corrects. Obvious errors get flagged. Fabrications get called out. But edge cases and incomplete data don't break the system—they're a natural state of any community-maintained database.

This approach recognizes how the music world actually works. Credits are often incomplete, disputed, or lost to time. The system should accommodate this reality, not demand perfection.

No Business Logic in the Protocol

Musiquay event kinds define structure, not behavior. The protocol specifies how to represent a credit, a roster entry, or an edition—it does not specify what clients should do with that data.

• Confirmation workflows are client-side. Whether a client shows "pending confirmation" badges, auto-sends notification DMs, or does nothing at all is up to the client developer.
• Aggregation is client-side. How a client combines release credits, track credits, and wiki contributions into a unified view is a presentation choice, not a protocol requirement.
• Reputation systems are client-side. If a client wants to surface "confirmation rate" or "attestation count," it calculates that from the events. The protocol doesn't define what counts as "reputable."

This separation keeps the protocol lean and extensible. New clients can experiment with different UX paradigms without requiring protocol changes. The events are the source of truth; everything else is interpretation.