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 ourcom.freemix.license.grantrecords. 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:
-
Multi-recipient payments: Does the spec support a single payment splitting to N recipients with individual proofs? Or would each split be a separate
oneTimerecord? For a remix chain 3 levels deep, we’d need proofs for the original artist, the first remixer, and the platform. -
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?
-
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