The primary use case for Chorus is providing people a means of subscribing directly to artists' output to put it into their music collection, to then be played through their own mobile app. The intention is that the subscribed music would then become a part of their collection that can be played at any time, living alongside their purchases from other platforms.
To this end, a Chorus receiver would be a piece of software that connects to the Internet and subscribes to a number of Chorus feeds. This could be a single-user instance, or it could support multiple users, and provide the ability for the users to select music to put into their collections. The receiver would then track individuals' music play activities for the purposes of discovery and determining fair payments or making purchase suggestions.
Playback could occur from a browser-based application or, more likely, via connected applications.
The receiver should also handle caching and transcoding of music files, both to support lower-bandwidth connections and also to avoid overwhelming a popular musician’s webserver or causing them a large bandwidth bill.
openSubsonic is a client protocol for connecting a player application to a collection. At its core it is basically a means of streaming an iTunes-style collection to a mobile device, and it is supported by a number of existing music collection servers, such as Subsonic and Navidrome, and some sales channels such as Bandcamp support the protocol as well.
There are also quite a few player applications that work with openSubsonic, but they tend to either only support a single collection at a time, or at best treat each collection as a separate “silo” without the ability to browse and play music from multiple collections simultaneously.
To that end, an openSubsonic aggregator could connect as a client to multiple openSubsonic accounts, and would send the same query to each account, aggregating the results together into a single view for the player application. It could also allow setting a priority for which sources take precedence when multiple sources have the same items (for example, most listeners would want to use purchased content from Navidrome or Bandcamp before going with the versions that come from a Chorus feed).
Such an aggregator would be easy to self-host or to provide as a community-hosted option.
Ideally, the aggregator would also have a Chorus receiver built-in, to reduce the complexity of an individual user’s setup; this would allow users to only have to connect to a single receiver, and configure it with a connection to their private collection infrastructure. For that matter, it could also be where the private collection is hosted.
There is a lot of flexibility in how this may be implemented.
Another potential use case for Chorus is to provide a means for Internet radio stations (i.e. shared livestreams) to get the latest releases from new artists and then add it to various playlists that are on continuous broadcast.
In this setup, Internet radio stations could subscribe to participating musicians' Chorus feeds directly (and download the files and metadata that way), which would be simple to integrate with most existing Internet radio systems (such as Icecast or AzuraCast).
In theory it should be straightforward to have a Chorus receiver also adapt its discovered content into ActivityPub, such as for Funkwhale, Bandwagon, or any of the many other efforts to put music on the Fediverse.
]]>While it’s out of scope to insist on a particular payment strategy (and payments are specifically not a part of the Chorus protocol), this document will explain a few ideas for how listeners can fairly compensate the artists that they listen to.
In this system, listeners would be able to choose what “streaming rate” is fair, ideally based on a unit per time. For example, with the assumption that a typical user listens for 100 hours per month and that they would be willing to pay $10/month for their listening, their stream rate would be 10ยข/hour.
The receiver then keeps track of a balance for every listener and artist. As a listener listens to music, their balance decreases, and the balance of the artists they listen to increase by the same rate.
Whenever an artist reaches a payment threshold, the system notifies the listener with the largest negative balance that they should send that artist’s balance over to them. When given proof of payment, the artist’s balance decreases by the transaction amount, and the listener’s balance increases by the same.
As a variant on the “support ledger” strategy, there could be a monthly collection of funds, and at the end of the month, any artists whose balance exceeds a payment threshold would be paid their full balance.
Anything left over would be split up among the artists with the top balances that fall below the threshold; for example, if the threshold is $5 and the coffer has $127 in it, then the top 25 unpaid artists would then receive $5.08, and their balances would be decreased by that amount (going negative, as an advance on future payment thresholds).
This strategy could also be used to allow for things like community support or ad revenue or the like to offset the costs of people who are unable or unwilling to pay.
The recorded duration should be based on actual play time instead of the reported duration in the collection; this is to avoid things like collections overreporting the length of the track, or allowing people to game the system by repeatedly listening to just a few seconds of a track, or filling their feed with 10-second songlets. This also allows for prorating based on partial listens or the length of a track.
]]>