busybee fluffy rambles

This is quite a bit different than my original vague protocol “spec,” as conversations with a bunch of other folks got me thinking about stuff. I especially want to thank Simon, one of the developers of Mirlo, who has kept me motivated on the project and who asked a few of the right questions to get me thinking about some of the hairier stuff.

And of course, I always have to thank Jamey Sharp, who was instrumental in improving my understanding of how things like paginations and deletions/revocations should work, particularly from our prior conversations about RFCs 5005 and 6721 which were the direct inspiration for those facets.

I also decided to write a bit more about how the consumers of the feeds might interact with it, a bit more on how private collections might work, and an extremely rough sketch of how some payment strategies might be implemented. That last topic alone could be the source of a dozen fully-fledged whitepapers.

There is still a lot to do on this. Many sections could be rewritten for clarity, and there could be much better examples. Having everything in a single big README.md is probably not great, either.

I’d really like to get in discussion with some of the existing open streaming initiatives, like Funkwhale, Bandwagon.fm, and TheIndieBeat, and see if there’s any interest in them supporting the protocol, or any issues they have with it that could be shaken out.

To that end, I’ve started a thread for it on The Social Music Network, which is a great gathering place where a lot of folks are working on these projects. I think of it as being “IndieWeb, but for Spotify.” I’m hoping that a lot of the discussion will take place there, and it’s definitely a place where folks should join if they want to talk about the future of independent music on the Internet.

My own next step is to completely rewrite the JSON feed for my music website now that I have a better idea of how it should be shaped. Building an actual implementation will probably help me to shake out some of the details.

Anyway, now that this is published in a public, editable space, I hope others will join in with their own edits and pull requests so that we can make something incredible together.

Some ancillary thoughts about protocol stuff

Protocol-wise, I am primarily leaning towards using JSON. HTML+mf2 makes a certain amount of sense for the same reasons IndieWeb prefers it (namely that there’s no need for “an API” when the data is just embedded in the webpage that it’s about, with no need for ancillary discovery), but most of the platforms which are interested in supporting this are all implemented as SPAs and so they aren’t actually rendering HTML in a way that it can be used as an API, so there’s going to have to be some sort of explicit API anyway, and JSON is a lot easier for implementors to reason around. It does mean that there’s now a need for actual API discovery, but two mechanisms are briefly described in the current spec.

Also, the current mf2 audio vocabulary is… limited, at best, and I feel like mf2 necessarily requires way too much semantic interpretation on the part of the consumer/client. See how IndieWeb post type discovery works and then add the myriad complications with things like albums, compilations, playlists, singles, and so much else… I just wanted a clean slate that is shaped like how music collections actually work.

I’ll continue to support mf2 on my own website, of course, but I don’t expect that to ever actually be useful in the big picture. But it could still be nice as a means for a client implementor to add more fine-grained content discovery, or for things like social readers to embed players for newly-published content even if it doesn’t go into a collection.