fmp — Federated Music Protocol

What it is (and is not)

fmp is a wire protocol plus a data model. It defines how independent, self-hosted servers describe tracks, how clients discover and fetch them, how identity works, and how servers federate metadata on demand.

fmp is not a platform, a company, a client, or a catalog. There is no central registry, no canonical server, and no protocol-level authority. Anyone can run a server; anyone can write a client; the protocol is the only thing in common.

Music distribution today sits on rented ground. Streaming platforms hold the catalog, the identity, and the reach; the listener owns nothing and the uploader controls nothing once uploaded. DRM turns purchased music into a revocable license. Geo-blocking partitions the catalog by jurisdiction. fmp starts from a different premise: you own what you publish, you own what you download, and no single server owns the network.

Principles

Key is identity.: An Ed25519 keypair on the client is the account. No registration, no password recovery, no homeserver lock-in. Losing the key means losing the identity — a deliberate trade, not an oversight.
Own what you publish.: Downloads are DRM-free, real, playable files in an open, signed format.
Provenance, not protection.: Every track is cryptographically bound to its uploader's key. This proves origin; it does not prevent copying. fmp signs, it does not lock.
No consensus.: Every node acts on local information only. There is no global agreement to reach, so there is nothing to partition.
Instance vs. client sovereignty.: Instances decide what they carry; clients decide what they reach. Neither overrides the other. Defederation by an instance is never censorship of the network, because content-addressed tracks can be routed around it by the client.
Popularity-based caching.: Content replicates toward demand. Origin servers are protected from raw leeching because popular content is cached closer to where it is requested.
Trust is not in the protocol.: No protocol-level web-of-trust. Since no protocol decision depends on how trusted a key is, creating many keys buys an attacker nothing at the protocol level. Trust, where wanted, lives in clients and instances, not in fmp.

How it works

Identity

Identity is an Ed25519 keypair. The public key is the user. Handles are best-effort, cosmetic labels — they collide freely, and the key fingerprint is always the disambiguator. Authentication is challenge/response: possession of the private key is the login. No password, no account record.

Tracks

A track is identified by a triplet:

(name, content_hash, uploader_pubkey)

The name is cosmetic and non-unique. The content hash is Blake3 over the audio bytes: identical audio has an identical hash regardless of who uploaded it or what it is called, so deduplication and cross-origin routing fall out naturally while provenance stays attributable per uploader key.

Federation — lazy, not eager

Servers do not mirror each other's catalogs. Federation happens on demand: when a local user actively reaches toward another server, the servers exchange the relevant metadata for that interaction — like DNS resolving on demand rather than mirroring the whole namespace. Audio never eagerly federates; audio bytes stay at their origin and move only through the cache, pulled toward demand. Running an fmp instance does not mean hosting the whole network's catalog.

Caching economy

Popular content would hammer origins into the ground, so each server runs a popularity-based cache: LFU-with-aging scoring, high/low watermark eviction, operator pinning. The effect is an emergent CDN — popular tracks replicate outward toward the servers whose users request them, unpopular tracks stay at origin and cost the network nothing. Cache policy is local behavior, not wire protocol.

The wire

A custom lean binary protocol over TCP with mandatory TLS 1.3. No HTTP layer, no JSON-over-WebSocket. Every message is a length-prefixed frame:

┌──────────┬──────────┬───────────┬──────────────┬─────────────┐
│  magic   │ version  │  pkt_type │  body_len    │    body     │
│  2 bytes │  1 byte  │  2 bytes  │   4 bytes    │  body_len B │
└──────────┴──────────┴───────────┴──────────────┴─────────────┘

Packet types are grouped (sys.*, id.*, track.*, fed.* mandatory; cache.*, stream.*, dl.* optional). Unknown optional packets are silently ignored, so the protocol stays forward-compatible and small enough to reimplement.

Own your downloads

The download format is a real, untouched audio file plus a small detached provenance sidecar — playable in anything, DJ-software-compatible, verifiable when you want it:

mytrack.flac            ← untouched audio, plays in anything
mytrack.flac.fmpsig     ← detached provenance sidecar

Verification recomputes Blake3 over the audio, checks it against the sidecar's content hash, then verifies the Ed25519 signature. If both pass, origin and integrity are proven. This proves who published it and that it is unmodified — it deliberately does not prevent copying. Provenance, not protection.

Honest positioning

fmp is not the first federated system with a free client. Nostr, the ActivityPub Fediverse, and Bluesky already operate at scale, and Nostr in particular matches the key-is-identity model closely. What is distinct about fmp is that it is music-native by design: a caching/replication economy tuned for large audio blobs, an owned DJ-compatible signed download format, trust deliberately kept out of the protocol, and a lean binary-protocol philosophy rather than generic JSON.

fmp does not aim for mass adoption. It aims to be a well-built niche tool that succeeds if onboarding is trivial and the protocol stays small enough to reimplement.