Sharing network effect, data, and revenue, across a social music network

[strypey]

Continuing the discussion from Does Patreon count?:

@Jordan

We lean heavily into the live and local scene territory

Is SubJam selling tickets? Online ticket sales is something most live promoters need or want, and is currently heavily monopolised. Taking a fair commission from ticket sales seems like an obvious revenue source given your live focus. If so, then tickets for sale could be discovered on other services via cross-site search, and that way SubJam could get reciprocation for helping people on your own service discover and buy records from the music store services.

To be clear;

@Jordan

A ‘finders fee’ for whichever site you’re on when you discover an artist and want to purchase something from them, regardless of where the actual purchase takes place

… was an idea I just burped up as I was typing that comment. I haven’t seen it discussed here before (unless I’ve forgotten), and I have no idea whether its practical, or how to do it. I’m interested in what folks from some of the other projects think about that @mirlo , @bandwagon, @jam , FairPlayer (@txels), and FunkWhale (@petitminion).

@Jordan

… cross-pollinating databases … would take a lot of planning and work

I think it’s important to come at this from 2 different angles. With each informing the other as we move towards testable designs.

Firstly, and most importantly, UX; what practical benefits could a social music network provide to the humans using it, with each of the relevant hats on (musician, listener, label, etc), beyond what individual services can do alone? Then comes the protocol angle; what data needs to be passed between services to realise those benefits, under what conditions, and what’s the most practical way to do that (considering security, privacy, computational and bandwidth efficiency, etc)? There’s been a lot of discussion on both of these areas on this forum, so there’s a wealth of ideas and proposals to dig into.

On the protocol side, most of the projects here use RSS in some way, so that’s one way to pass data between services. FunkWhale, BandWagon and Mirlo are all using ActivityPub to standardise some of the interop between them, and that comes with the benefit of being interoperable with the rest of the fediverse too. There’s been a new protocol called Canimus - I think it’s now called Chorus? - which I think is for decentralised music streaming? Not sure how that compares to what FairPlayer are doing. There’s also been some discussion about how to use the SubSonic API.

But deciding which protocol(s) to use, and when, depends on the UX we’re trying to create. When lost in the weeds of technical discussions, it can be really helpful to take a step back, and ask; how does this help a person achieve a thing that matters to them?

[fluffy]

@strypey

There’s been a new protocol called Canimus - I think it’s now called Chorus? - which I think is for decentralised music streaming? Not sure how that compares to what FairPlayer are doing.

Canimus was the original name of Chorus, but most people hated it and so the name changed while it was still possible to change it.

The point to Chorus is that it’s a structured collection format for publishing freely-streaming music to endpoints. It’s what Fairplayer uses to communicate with a few publishers (currently pulling from Mirlo and my own music site), and the greater ambition is that it will be a format that a lot of people use to publish their collection information to others. Such collections can then be aggregated and then provided to listeners via a web-based player or a subsonic server or the like. That player would then also keep track of what people are listening to and then direct them to send money to the musicians they enjoy.

The current state of Fairplayer is a pretty good proof of concept for where things are heading, and a bunch of us are working together to define the direction it’s going in.