busybee fluffy rambles

The typical IndieWeb experience is to have a feed reader (usually consuming RSS/Atom, sometimes html+mf2, sometimes ActivityPub) that subscribes to updates from individual authors. This model maps pretty well to podcasts (and is in fact the basis of them), but doesn’t map particularly well to listening to music.

What I’m envisioning would break this down into two parts: the producers, and the consumers.

Producers (bands)

In this model, every band/artist would provide a feed of their releases, where a release contains collections of tracks. The feed would have a generic “support this artist” link for people to send money, and the release and tracks would have links for people to purchase the specific music. Each track would have a streamable link to the music (mp3/m4a/ogg/etc.) at whatever quality the artist deems appropriate for streaming purposes.

Consumers (listeners)

Next, the listener would have some sort of “radio” (similar to a feed reader) that subscribes to bands' feeds and can add the music to a pool of available stuff to listen to. The radio would be what chooses tracks to play, and, most importantly, would keep track of which songs the listener listened to, and maintain a running tally of how much time they spent listening to each thing.

At some regular interval, the radio would then remind the listener of which music they listened to during that interval, and suggest sending them some amount of money to cover it. It could be up to the listener to decide what their “streaming rate” is for artists; for example, they could decide that they want to support the musicians they listen to at a rate of 10¢/hour (which could be overridden on a per-artist basis), and once a month the listener can see that they owe Sockpuppet $5.50, and send them some money and reset the counter.

Next, the radios can also provide a peer-to-peer music rating system, similar to, say, Vouch or the like, where you can publish the songs that you like or dislike, and subscribe to other peoples' like/dislike feeds as well, allowing any concordance in ratings to drive discovery. This would also provide a natural alternative to last.fm et al, since your listen feed could also be public.

Finally, allow people to also store their purchased music in their radios so that they can get it at higher quality, and associate the purchase with the streamable music so that you get those songs at higher quality. Collected/purchased music could also be given a different hourly stream rate (so you can still choose to send tips to bands that you listen to or you can decide that once you’ve bought an album it goes down to $0/hour). The collection should be something you can self-host on a home network or the like and/or using block storage such as S3/B2/etc., and in this way you can also include music that hasn’t been opted in to this streaming mechanism (which would, of course, not be advertised or made available to others).

This “radio” thing could also easily become a hosted service that people can buy a subscription to, and then that hosted service could automatically pool payments to various musicians, for example. Basically making it an indie, federated equivalent to Spotify combined with last.fm.

Why I like these ideas

The current streaming landscape is incredibly unfair to musicians. Payments are based on a global pool of all listeners on a particular platform, and are based on the number of times a song is played, and not on the duration of the music that’s been played. This has incentivized musicians to make shorter, repeatable songs, because a 90-second notion is worth the same amount as a 60-minute ambient epic. Wouldn’t it be nice if it were up to the proportion of time that someone is enjoying music for how much the musician gets paid?

This system would of course rely on the honor system for payments to actually happen, but I believe that listeners actually do want to support the musicians they listen to, and anyway, by the streaming feed being lower-quality stuff that still incentivizes people to buy and collect music, and also helps to mitigate the issues that lead people to move to streaming to begin with, since this would let people have a heterogeneous collection where some stuff comes from streaming and some stuff is what they own and they wouldn’t have to actually manage device syncing and so on. So you have the best of both worlds: unlimited access to all the music on the platform, as well as still being able to listen to your own collection which can’t be taken away from you.

There’s also a case to be made for supporting Bandcamp/Faircamp/Mirlo pages and the like as a streaming source, as those systems already provide feeds of lower-quality web-based previews and mechanisms for supporting the musicians. Care would of course need to be taken to do this with consent, so I’d want there to be some easy opt-in mechanism where musicians can submit their discographies (or individual releases) to a feed provider as a stepping stone.

Finally, by democratizing the discovery process, people can choose whatever algorithm they want, and there’s no special inroad for the major labels to get an outsized influence on what people find out about. (In fact it would be unlikely for major labels to ever want to participate in this feed mechanism to begin with.)

Why I don’t like these ideas

The discovery approach needs to be resilient to bad metadata. Ideally there would be some audio fingerprinting mechanism (such as MusicBrainz AcoustID) at play.

This also relies quite a lot on the honor system, although in my experience, the amount of money I get from the streaming services is basically $0 anyway, so as a musician I’d appreciate at least getting a chance of discovery and someone opting to directly support me anyway.

The amount of individual payments involved get to the microtransaction level, and without some sort of large-scale payment pooling system (which cannot operate on an honor system for what I hope are obvious reasons!) it becomes quite impractical for anyone to ever get to a payment threshold that would make it actually worthwhile. So maybe it makes more sense to encourage people to make music purchases based on the music they’ve been streaming, rather than sending tipjar payments. (Either that or suggest sending, say, $10 to the artist with the highest balance in any given month, and then that artist gets a negative balance for a while.)

And, of course, convincing enough musicians and listeners to give it a try would be challenging.

Some ancillary protocol thoughts (hand-wavey and half-baked)

This is mostly back-of-the-envelope stuff that I’d only expect to make sense to other IndieWeb participants.

I keep thinking that the feed should probably be provided as HTML+mf2, where there’s just, like, a human-readable “discography” page which includes all releases and tracks, with mf2 metadata for the streaming discovery purposes. Then each individual release/track/etc. should also provide mf2 so that discovery can just point to the individual item’s URL.

As far as I know there’s no mf2 music/media spec; the microformats wiki has a somewhat half-baked draft for hMedia as part of mf1 but it hasn’t been updated to mf2.

I’m thinking that the following attributes would be reasonable to consider (in addition to the standard h-entry/h-card suite):

• General attributes:

  • u-support: the URL used to support the artist (ko-fi/patreon/etc.); this can live on the artist’s h-card
  • u-purchase: the URL used to purchase the item (which would be on the h-entry for tracks and albums/release groups)

• Track-specific attributes (which would still be stored on the track’s h-entry):

  • u-audio: the URL for streaming the music
  • p-lyrics: the track’s lyrics
  • p-acoustid: the audio fingerprint of the track
  • h-release: the release group(s) on which to find this track

• Discovery feed attributes

  It’d probably be useful to allow a listener to have multiple “stations” (cf Pandora) each of which is a separate h-feed with its own h-card (giving the listener the opportunity to provide a name for the station, a blurb about their rationale behind it, etc.)

  Each h-entry on the feed would comprise e.g.:

  • dt-published: when the listener started listening to the song
  • p-name and p-author: used for track title and performer
  • u-listen-of: the URL of the track (specifically its own h-entry or other public HTML page)
  • p-acoustid: the audio fingerprint of the track, for when there’s no u-listen-of (e.g. for collected/purchased music that’s not opted into this streaming universe)
  • dt-updated: when the disposition took place
  • p-disposition: the listener’s disposition, probably one of:
    • listen: listened the whole way through
    • skip: skipped to the next track
    • like: specifically liked the track (implies listen)
    • dislike: specifically disliked the track (implies skip)
  • h-release for release-level information, if available