FreeMix — music royalty cascade as a use case for attested.network

Working Groups Attested Network
1

Hi all — This is Joshua Iz, founder of FreeMix (freemix.fm), a decentralized music sharing and remix platform built on ATProto. Excited to see the attested.network spec published — it maps directly to a problem we’ve been designing around.

What FreeMix does: Producers upload tracks and stems with machine-readable licenses (our FreeMix License Framework — think Creative Commons but purpose-built for music workflows). When someone remixes a track, an attribution record in their PDS links the remix back to the source. This creates a remix tree — full chain of provenance for every derivative work.

The royalty cascade problem: When a remix sells, the original artist should get a cut. When a remix-of-a-remix sells, both upstream artists should get cuts. We need verifiable, portable proof that these payments happened — tied to the ATProto identity graph, not locked in our database.

How attested.network fits:

  • FreeMix as broker: We orchestrate the royalty split based on the remix tree (original artist gets X%, remix artist gets Y%, platform fee Z%). Stripe handles money movement. FreeMix attests that the split happened correctly.

  • entitlements → license grants: A payment’s entitlements array can strongRef our com.freemix.license.grant records. Buy a track → get a verifiable, portable proof that you hold a license to those stems. The license record lives in the payer’s PDS and travels with them.

  • Multi-recipient cascades: The three-party model works cleanly for 1:1 payments, but remix chains create N-recipient scenarios. A remix-of-a-remix sale might need to attest payments to 3+ parties. Curious how the spec envisions this — multiple proof records per payment, or a single payment record with multiple recipient references?

  • CID verification: We already integrated badge.blue’s CID-first attestation for track integrity verification (content snapshots with CID pinning). The attested.network spec using the same framework means our verification pipeline extends naturally to payments.

Questions for the group:

  1. Multi-recipient payments: Does the spec support a single payment splitting to N recipients with individual proofs? Or would each split be a separate oneTime record? For a remix chain 3 levels deep, we’d need proofs for the original artist, the first remixer, and the platform.

  2. Conditional entitlements: Our license tiers have modifiers (NonCommercial, ShareAlike, Royalty percentage). Can entitlements carry metadata about the terms, or should that live in the referenced license record?

  3. Broker trust for cascades: In a royalty cascade, the broker (FreeMix) is asserting the split percentages are correct based on the remix tree. Is there a pattern for attesting the calculation behind a split, not just the payment itself?

Happy to share more about our architecture or provide more info. We’re just hitting beta now and planning commerce integration imminently. The spec timing is excellent.

If anyone wants access just sign up for the beta here: https://freemix.fm/ and I’ll get you approved.

— Joshua

2 Likes
2

@ngerakines.me any thoughts here?? TY!

3

Interesting project. I signed up for the beta. I am not going to answer your questions about attested network, but you might be interested in my lexicon proposal for how to deal with copyright data: Announcing indiemusi.ch alpha: the groundwork for music streaming on atproto - hilke thinks
As an indie artist/label I will not upload any audio to my PDS before I can protect it in a Permissioned Data space, but I stay curious about your idea.

1 Like
4

Hi @hilk.eu just approved you - thanks for signing up!

Like your proposal and it overlaps with some of the work I’ve done with FreeMix. We have lexicons for release, track, stems, license grants, and more but could definitely incorporate some of what you have laid out.

While the permissioned data spec is still in flux, we already protect the artists’ uploads at both a license and permissions layer. We may revisit the way that it set up once permissioned data matures if it makes sense. Where it already makes sense (and some of this is in your post) is for organization/label accounts where there are sort of two (or more) joint owners of the material.

FreeMix isn’t a streaming service per se, but tracks can be shared across the network. Yet we incentivize uploading remixes and derivatives back to FreeMix for the attribution chain.

Currently I’m building out the payment and royalty infrastructure along with automatic stem separation on upload so stay tuned!

5

Hello from the Philippines! Just chiming in as someone who do mixtapes/playlisting for fun on his free time while autistic, how’s the compatibility with the existing CC licenses would work out, especially the BY-4.0/BY-SA-4.0 ones?

6

Hello,

The FreeMix licenses are roughly based on Creative Commons licenses but only apply to tracks uploaded to FreeMix. So if you wanted to make a mix of tracks downloaded from FreeMix that include the FM:DJ license or Mix modifier, that would be ok to do. Credit/attribution would be dependent on the license granted.

What would not generally be ok is to upload a mix of FreeMix and non-FreeMix tracks as we have no way of policing that and thus it could be subject to DMCA takedown request.

You can read the docs for more details on FreeMix licenses and how they work here: FreeMix License Framework | FreeMix Docs