Canimus: yet another federation/syndication approach

Projects
, ,
1

Lots of folks have been talking about means of doing federated/syndicated streaming things, but all of the efforts I’ve seen have been based on various extensions of RSS and ActivityPub, and both of those protocols leave a lot to be desired when it comes to this kind of stuff.

I’ve been thinking/vaguely talking about a simpler, streaming-collection-specific protocol for a while, and I’ve finally collected some thoughts and a protocol sketch into a public place: GitHub - PlaidWeb/Canimus: Federated music publishing protocol for decentralized streaming platforms

My goals are to make something that’s relatively easy for both publishers and consumers to participate in, and which is designed specifically around the shape of music collections, rather than trying to shoehorn music into formats that weren’t designed for it.

I’d love to know what people think!

I specifically would love to see this supported by both Funkwhale and TheIndiebeat as consumers, and Bandwagon, Mirlo, and Faircamp as producers. (I will definitely be building support for this on my own website as well!)

This is the continuation of my blog post from a couple months ago that @simon posted about at Some thoughts on a fair music streaming platform

6 Likes
2

This looks straight forward to me, I’d also love to get @jam and @bandwagon @TheIndieBeat 's eyes on it.

3 Likes
3

(cross-posting from Fun Music Place)

Thanks @fluffy for putting this together. Amazing work. I love the idea of making our own standard that works for music and other audio art. ActivityPub is so generic that it’s useless without coordination between parties, which is what we have to do regardless of what protocol we follow. So, yeah, makes so much sense to design our own.

At first glance, I like what I’m seeing. I would love to think more deeply about the modeling here. An entity-relationship diagram would help us visualize this spec. GitHub be damned, it does allow writing Mermaid diagrams within Markdown, and it works well (Codeberg supports that too I believe).

I’m trying to grasp how players would work. There are also two parts that don’t feel right to me. First is the Private Libraries, I think despite licensing issues we should encourage listeners to own their music and store their own archives. Second is the Payments, I think this part gets into the subjective design of music consumption and commodification that I don’t think should be standardized.

Thanks for continuing to share your vision here. Connecting those ideas to the technical side is a huge hurdle. I’m thrilled to see this on paper so we can start talking about it concretely.

1 Like
4

The point to the private libraries is to give people a reason to own their music while still being able to make use of the streaming network for additional discovery. Maybe I haven’t explained it well enough or something because like, the point is to be able to have something like Plex+PlexAmp for complete access to your own privately-owned/downloaded collection rather than having to give it up and be piecemeal about whether you’re listening to “streaming” vs “library” music.

The mental model I had in mind is something like Apple Music + iTunes Match.

And yeah the point to describing payments wasn’t to standardize it, but to explain ways in which it might be encouraged to work. It’s definitely not something I want to bake into the protocol, I only discuss it to encourage people to think about how it might work in a way that encourages direct support of the musicians being streamed.

Ideally at some point the big monolithic README.md gets split up into a bunch of separate documents describing the different aspects, like having one for the feed format, one for how receivers/players work (including things like subscribing to feeds and private libraries), one describing potential mechanisms for encouraging fair/equitable donations to the artists, and so on.

As far as documentation and charts go, I haven’t looked into the tools you mentioned, so I should do so. Or better yet, someone else could make pretty diagrams and contribute them in a PR. :slight_smile: I definitely want what’s there right now to be a starting point, not a final answer.

2 Likes
5

I’ve implemented a preliminary feed on my own site. You can see it at https://sockpuppet.band/releases/canimus.json and it should also be discoverable from https://sockpuppet.band

I haven’t yet implemented pagination so right now it just dumps my entire discography out, but it’d be fairly easy for me to add.

2 Likes
6

Nice nice work! Thank you :folded_hands:

I’d love for @bandwagon to take a look at this, too.

I’m probably a little obsessed with tags (ha), but I’d love to see “tags” as a property on both the album and the track. Track could inherit from album (ala genre) when empty.

Tags would be for information such as “sitar,” “tenor saxophone,” “Spain,” “Esperanto,” etc. Information about the material that isn’t strictly genre or artist. Tags are a great tool for discovery mechanisms.

Also, if individual listeners are eventually given a way to tag artists, albums, tracks and playlists in their own outbound feeds, it could be a powerful tool for social discovery. Tags make it possible for the audience to contribute to the conversation by coining their own terms for flavors of music and artists. And I think that, in turn, drives discovery for artists :slight_smile:

I can picture an early application of tags, for example, on TheIndieBeat. If the curator of our NHAM channel was able to tag tracks, artists and albums with his own take on how to describe them, I think his followers would benefit from being able to follow certain of his tags and be alerted to new music that he has tagged. “Oh, I always like music that NHAM tags as ‘dreamy.’ I’m going to follow his ‘dreamy’ tag.” I bet our independent channel operators would find other creative and pragmatic uses for tags, as well.

OK, I went off on a tangent.

2 Likes
7

Yeah, tags are something I’ve put a lot of work into on my own site, where I have tags for mood, genre, and instruments, and it would be nice to have that as part of the protocol as well. I feel like that’s something that would be trivial to add but difficult to use.

1 Like
8

Expanding on this more, the reason I haven’t just put in an array of tags already is because I actually don’t like having simple unstructured tags on things for reasons of semantic confusion. I’ve found that tags are a lot more useful if they have some sort of a domain applied to them. Sometimes bad things can happen if you just treat all tags as a flat namespace, for example that time I got shadowbanned from Bandcamp.

On my own site I have tag categories:

  • Collections
  • Genres
  • Instruments
  • Moods
  • Topics
  • Music type

and this lets me really dig in on my catalog (it’s particularly useful when I’m trying to find songs that I want to perform live or whatever). But it might be too fine-grained detail for most people.

Also, the tag hierarchical relationship on my site is backwards from what you’d expect; albums inherit tags from tracks, but only for some categories, and I’m still trying to figure out which categories make sense to propagate. Genre and instrument, definitely, but mood? Maybe not so much.

Tags are also super-subjective, and difficult to keep consistent.

I do definitely want to support them at some point, but I think it takes a bit more thinking about what problem they’re trying to solve, and it needs to be more than just “throw an array of strings at it.”

2 Likes
9

Hey, sorry it’s taken me a bit to respond here. Some day I’ll be as caught up as I’d like to :sweat_smile:

To double check my understanding, this looks like RSS + WebSub + some custom fields, yes? Which, should work perfectly well… and I agree about not using ActivityPub, mostly because it’s just a ton of work to set up to get real-time notifications.

I do want to verify one other requirement – @fluffy, could you give more clarity on how we would allow artists to choose where their music is syndicated? This was championed by RadioFreeFedi, and I think it’s a good one to keep.

Just for comparison, we’re currently using Webhooks (in roughly ActivityPub + Funkwhale format) to notify specific websites (now, only TheIndieBeat) when someone has opted-in.

The specific mechanism isn’t so important to me, and I’m happy to rebuild the Webhooks that we’re currently using to be something like Canimus if that works better for everyone – if we can continue giving artists some point where they “consent” to being included.

Perhaps callers could include an API key with their requests, and then servers could provide different responses based on the API keys presented?

2 Likes
10

There’s no RSS, it’s just RSS-inspired in the sense that it’s a feed people can subscribe to in order to retrieve content. I purposefully did not use RSS as a basis for the format.

This feed format is meant to be something that allows anyone to access the music stored in it, and if someone doesn’t want their music to be visible to the feed, then it shouldn’t be put into it. That said, there’s no reason a provider can’t put some sort of higiher-level access control in place (such as using an API key or a bearer token to affect a permission mask or whatever), just like how some folks have implemented private posts in their RSS feeds or whatever.

From Bandwagon’s point of view, if you want to provide people the option of whether it should be visible to the public, or only to known consumers, then you could certainly allow people to check boxes for specific opt-ins and then you negotiate how the interface looks with those consumers of the feed.

As far as the update mechanism goes, you can also certainly set up peer-specific webhooks to notify others of an update. The point to suggesting WebSub as a common standard is to make it so that anyone can subscribe to updates without any specific peering agreement. WebSub is basically a simple protocol that allows anyone to register a webhook unattended.

11

By the way, there’s another IndieWeb protocol, Ticket Auth, that could also be used as a basis for an unattended peering agreement. It could be used for someone to register as a known subscriber to a feed, and then the provider of the feed could then use that to choose which content can be shown to them.

I don’t think that needs to go into the feed protocol itself, although eventually we could formalize a standard for “known subscribers” and then add the appropriate rel to the feed links.

1 Like
12

I do feel like this might be worth thinking a bit more about, cause I think in our ecosystem some artists might have a strong preference for this kind of control (related: So You Want to Remove Your Music From Spotify).

I’m not super jazzed about delivering the music to another service because I feel like that’s releasing control of the music (unless that’s changed about how IndieBeat works?). I also wary about putting more of the onus on the client on playing the different types of music, but I do think it’s better for energy use if the client is thinner (ie only gets the music if it’s requested by the player? Maybe it’s better to spread out the bandwidth, but that spread out feels like it’s better to do it by being spread out across music servers, rather than clients, anyways, side ramble).

I like the idea of maybe including something in the standard that allows some form of “hey, if you want to actually play this music, this is what you need to do”. Keeping track of clients that have permission for a specific track seems a bit like a headache. Especially if we’re thinking of clients lots of services keeping track of those clients. It feels like it grows pretty quickly.

13

Yes. Clients should never be trusted, because someone will come along and make one that doesn’t follow the rules.

And to clarify, we’re currently tracking “permissions” in two separate places:

  1. When someone buys an album, they get one set of permissions tied to their email or Fediverse handle. Im assuming Mirlo does something similar. This could become some permission for streaming it on another station, but we’re not using this now.

  2. when an artist publishes an album, they can choose streaming stations to share it with. This is sort of a blanket permission for the station to play this album however they want. But, it’s not tied to individual listeners.

14

Okay, so, I feel like a lot of folks are missing the forest for the trees here. There’s no reason there can’t be any specific peering agreements required for a data interchange, but the point to this is that centralized and quasi-centralized platforms are what I’m trying to get away from to begin with.

Sure, poorly-behaving clients can happen. People can also already steal the preview versions of music from Bandcamp and Mirlo. People who are insistent on pirating music are going to do so, and technological solutions to social problems are never a long-term solution. Even if there’s a direct peering agreement between producers and receivers, people at the listening end will still be able to copy the music they listen to from the service.

My goal here is to reduce the amount of friction that it takes for peoples’ music to be heard in a way that makes it easy for listeners to support them. I’m not interested in trying to solve every problem with capitalism and piracy.

I want people to be able to own their own experience by self-hosting their own receiver, and/or self-hosting their own paid collections that are available to whatever receiver they’re using. I want to encourage people to buy their music first and foremost, and to give them the ability to interact with their purchased music the same way that they would with any streaming service.

I also want to support listeners who are just trying to listen to everything and find new stuff that they didn’t know about before.

I want to encourage thoughts along those lines: people are going to acquire their music in whatever way suits them and their morals, and we should do what we can to make it easy for them to make the right choices.

For those reasons I do not want to bake peering agreements into the feed format itself. If you want to build a peering agreement that restricts access to the feed, fine, but I also feel like that’s missing the entire point.

EDITED TO ADD: Also, as a musician, I’ve always found that it costs me more money to put my music on streaming than I’ve ever gotten back from it, and if I’m going to be not paid for my music, it might as well not cost me extra money, and ideally be in a situation where people can be encouraged towards direct support.

2 Likes
15

I agree about this. The intention is that it’s only metadata being interchanged between publisher and receiver, and the client is retrieving the audio stream directly from the publisher. Also in the original HTML+mf2 idea of this system (which I still have available at Sockpuppet Radio), the idea was that people would just be adding items directly from the web into their collections and getting the data from the individual item, with it not necessarily having a complete sum-total feed of all of the output of an artist. This would have relied much more on discovery feeds being a thing.

16

For the access control conversation I started a discussion on the github repo: Access control · PlaidWeb/Canimus · Discussion #6 · GitHub

2 Likes