Improving RSS feeds in social music platforms

While documenting RSS for music makers I tested the RSS features of Funkwhale, Mirlo and Bandwagon, with very different results. I’m making this post wiki in case others want to add information and keep it updated.

Artist feed

This is the basic use case. The goal is to offeran RSS feed with the artist’s new releases, offering descriptions with rich formatting text, cover art, and an embedded player or the downloadable audio file when the artist wants that.

As of April 2025, Funkwhale offers basically everything an artist needs to distribute their music via RSS, with a feature set on par with Soundcloud.

This is a random :sweat_smile: example of an artist feed created by Funkwhale, with audio automatically downloaded by AntennaPod and playable directly from AntennaPod.

More screenshots

RSS feed entry of a song, and then the description available as “Shownotes”, also with Funkwhale / AntennaPod


The following features have been tested with AntennaPod, a popular open source podcast player.

Feature Funkwhale Mirlo Bandwagon
Artist RSS feed :white_check_mark: :white_check_mark: :white_check_mark:
Artist feed title :white_check_mark: :white_check_mark: :white_check_mark:
Artist image :white_check_mark: :x: + :x:
Artist description :white_check_mark: :white_check_mark: :x:
Album/Song title :white_check_mark: :white_check_mark: :white_check_mark:
Album/Song description :white_check_mark: :x: + :white_check_mark:
Album/Song art cover :white_check_mark: :x: + :x:
Album/Song player :question: :x: + :x:
Song audio download :white_check_mark: :x: + :x:

Note: Funkwhale offers RSS at an artist channel level, and channels can have single songs listed. Mirlo and Bandwagon offer Artist feeds, and entries are albums by default, even when albums often contain just one song. This complicates the distribution of audio files via RSS because there isn’t a specification for downloading multiple audios for an album.

Multi-artist feeds

Platforms can create RSS feeds based on criteria like all recent releases, new releases by music genre, playlists, and so on. Then users can subscribe to these feeds to discover new music from multiple artists.

Feeds Funkwhale Mirlo Bandwagon
Playlists :x: :x: :x:
Tracks by tag :x: :x: :white_check_mark:
All new tracks :x: :x: + :white_check_mark:
All new albums :x: :white_check_mark: :white_check_mark:
All new artists :x: :x: + :white_check_mark:

Note that the same feature limitations from the section above will apply to these feeds. For instance, if a platform doesn’t include downloadable audio files by an artist, they won’t be available in these feeds either.

4 Likes

I have put a lot of time on this draft and RSS for music makers already, and I welcome help at least from Faircamp users to add the related information.

1 Like

Additionally, we’re unlikely to make songs available via RSS if people need to buy them.

Here’s some tickets to track some of this work on Mirlo

1 Like

related :

2 Likes
1 Like

Progress in Mirlo by @simon. :tada:

FYI CastoPod supports premium episodes that can only be download by people who have paid a subscription (or fulfilled some other criteria determined by the podcast creator). So in theory, using similar methods, a music service could enable artists to share their music over RSS, but limit some or all of it to premium subscribers.

I could very well be wrong but my understanding on these kinds of premium episodes is that they’re largely security by obscurity–if you have the magic sauce URL you get access to the episodes.

Maybe there’s more to it than that? I’ve subscribed to premium episodes before for other podcasts and that’s mostly just copying a special URL in to my podcast player.

Maybe this is also Good Enough for most artists?

That’s for artists to decide. But I think it’s worth noting the comment I made in another topic;

If fans have made the effort to find to find an artists page on an indy platform, and pay them money, they’re probably not an attacker who needs to be defended against. In the unlikely event they pay money to be able to share the special extras with people who haven’t, that won’t stop the people inclined to pay from doing so anyway.

The main thing that motivates digital pirates is a desire to make information and culture available to everyone, regardless of ability to pay. So I highly recommend the approach Cory Doctorow takes with audio versions of his books. Free the work for everyone, under a CC license, once a declared funding goal is reached (eg costs are covered, or costs+margin for the artist).

Completely agree about human pirates — I reckon small artists are safe there. it’s more AI scrapers you’d have to watch out for. @keef has a great series of blog posts about that: An Evil Genius Robot

1 Like

Yes indeed. Thinkbot ignores robots.txt files, and has been aggressively scooping up every binary file it finds, music zips and all.

The massive botnet crawler I’m dealing with on another site at the moment seems more interested in text files, thankfully, as it would be harder to block.

1 Like

Sure, but that’s not a problem specific to pay-to-access works, which is what I was commenting on there. In fact, IANAL but I suspect evidence of scraping behind even the softest paywall would be evidence of unambiguous copyright violation, and highly actionable.

FWIW I may be in the minority here, but although I’m disgusted by the con of leasing Trained MOLEs as “AI”, I’m not opposed to web scraping per se. I utterly reject both the ‘copyright is stealing’ canard and the ‘public not Public’ doublethink. The problem here is asymmetric power relations, not permissionless copying of public-facing data.

Recently I was trying to come up with a better way of building a federated streaming/discovery system, and I ended up deciding that the current morass of incomplete and half-baked RSS standards is more of an impediment than anything else, and decided to experiment with building new library federation protocols from the ground up. This is very much a work in progress but you can see a basic prototype at Sockpuppet Radio with both an HTML+MF2 and a JSON version.

It would be really nice if some export/federation format like this could be used to support basic interoperability between multiple systems (e.g. Funkwhale, Bandwagon, Mirlo, etc.), without being beholden to the design flaws and complexity of RSS.

The HTML version of that page also links to the start of a series of blog posts where I ramble about how a truly decentralized/federated streaming platform could work. I also discussed this somewhat on another thread here: Some thoughts on a fair music streaming platform (I’m only reposting the feed aspect to this thread as one of the Funkwhale developers pointed me to this thread when I was asking about their RSS ingest support).

4 Likes

@fluffy would you be down to put some links together in a GitHub ticket for Mirlo for this? Basically proposing what it could look like for an album and an artist page?

1 Like

Sure, we’ve talked about this a bit on the Mirlo Discord but having a bit more of a formal tracking process would be sensible.

2 Likes

Yeah my issue is 100% if it’s not a ticket I will forget about it. I don’t have object permanence :laughing:

1 Like

How does this contrast with what @bandwagon is doing using ActivityPub? Which is also an HTML/JSON protocol.

It differs in that it’s built around the idea of being a very simple, domain-specific format to publish and consume without needing to contort it to being ActivityPub-shaped and all of the operational and maintenance overhead that entails.

Incidentally, this project now has its own thread over at Canimus: yet another federation/syndication approach

2 Likes