It’s described in full here;
That question is a bit above my paygrade. Maybe @bandwagon could answer it from the POV of a dev working on an AP-enabled music platform?
Just out of curiosity, could a search portal like unstream.stream make use of Caninus? If so, what might that look like?
I got bored in the right way and added a Canimus feed to Song Fight!, so if anyone wants another source of data, there you go. It’s supported on both the main archive and on individual artist pages (e.g. my page → https://songfight.org/canimus/sockpuppet.json)
hi, quick review from Funkwhale dev here.
The proposition is missing a two very central feature :
- multiples artist. At funkwhale we use the concept of Artist Credit from MusicBrainz Making sure you're not a bot!.
- tags : genre is a specific kind of tag. Tag is more open. Musicbrianz allow free tags while genre are build by the collective (this allow to build a genre taxonomy, which is impossible with tags)
I also want to say that there is a loooot of software that support RSS. What is missing from my pov is a proper way of using it for music content. I don’t see the interest of creating more protocols to a world where there is already so much of them.
If you’re interested in working on music through rss you can have a look at Making sure you're not a bot!
I’m certainly interested in adding any missing features to the protocol spec. By multiple artists do you mean multiple artists per track? I have modeled the protocol after how music collections work in e.g. iTunes, where there’s a per-track artist as well as an album artist, but I hadn’t considered how to do multiple artists on a track beyond the usual “Title ft. Collaborator” thing.
As far as just using RSS, the problem I keep running into is that there are so many different ways that people try to express music via RSS, and also RSS is not a suitable thing for handling things like backfilling and syndicating entire collections. It was specifically seeing Funkwhale’s RSS support (and trying to see how to syndicate a collection from a website into Funkwhale) that led me to the path of trying to propose a new format that would cover the cases of syndicating a collection.
That said I would absolutely prefer to support whatever standard is already being supported. The problem I see is that RSS-for-audio has been completely taken over by podcasting at this point and there’s very little agreement on how music collections should work by RSS.
The main thing I’m working towards is a means of artists to be able to publish their music to a website in a way that players can consume it. If that’s RSS-based, fine, but I’ve yet to see any RSS-based system which actually preserves album structures and provides all the other useful metadata in a clear and consistent manner.
Also I don’t know why it took so long for me to get the email notification of these replies from the forum.
1 Like
Oh, and another issue with trying to overload RSS is that since it’s used for so many different things, you run into confusion issues. For example, website has an Atom feed that includes both music and things like blog posts and live concert announcements, and by its nature it’s paginated. If there were a music-specific RSS feed as well, then there needs to be an extra protocol to indicate which one’s for music and which one’s for everything else. Given how poor most clients are about feed discovery in the first place (especially in a multi-feed context) there needs to be something that distinguishes them, even if it’s just declaring the content-type as, say, musicrss+xml vs atom+xml or the like.
Or if you have a single combined feed, there needs to be a mechanism for declaring which posts are of which type, and that’s also not standardized.
I’m no expert with FEPs, but I have done one, so I have some pointers 
“Fediverse Enhancement Proposals” - or FEPs - are just additional documents that layer on top of the existing ActivityPub specs. You can propose anything you want, then work with different developers to get it implemented.
The starting point is here: fediverse/fep: Fediverse Enhancement Proposals - Codeberg.org where all FEPs are hosted. The main page is pretty thorough, and includes a simple (for techies) way to generate your own FEP number, then publish it to the Codeberg repository.
A lot of the publishing is automated, so they’re very specific about following certain formatting rules. I needed help on my first several tries, but fortunately silverpill is very willing to work with you to to get things right.
I’m guessing your FEP should probably include: 1) specs for generating a Canimus feed, and 2) discovery mechanisms for linking and finding this data. It would also help to include a discussion of the use cases and example implementations.
FEPs are kind of like a patchwork. Every project picks and chooses which ones they will implement. But, this is a good starting point for getting developers to agree on the problem and the solution to it.
One warning, this is also a slow process. Just anecdotally, I published FEP-3b86 nearly two years ago. I lobbied with a lot of projects, but it sat for about a year and a half. Eventually, consistently banging the drum has started to work and it’s finally getting traction with some larger projects. Obviously, your mileage may vary, but it’s good to set realistic expectations on how quickly devs will jump to add more to their backlogs.
I hope this helps. Please let me know if I’ve left anything out, or if I can help in other ways.
1 Like
I still don’t really see what ActivityPub brings to the table. I’m just trying to describe a collection of collections, essentially. Tracks and albums that contain those tracks. It’s not a realtime feed for updates, and it’s not meant to be at all related to a social feed or the like.
This is just a data interchange format.
I guess a different question I should ask is: where is the Bandwagon FEP documented, and is it something that could be supported by anyone in a publish-only way, e.g. with static publishing?
Canimus and Bandwagon are both touching the same points (and Bandwagon was one of the direct inspirations to begin with) so if there’s a means of interoperating without having to run the Bandwagon software stack or eschewing the notion of static publishing, I’d be in favor of discontinuing my project and endorsing Bandwagon instead.
You may have missed;
Again, this is not about you implementing AP or adding any AP stuff to Canimus. This is about standardising a way of using Canimus with music-related AP projects like FunkWhale (@petitminion) and @Bandwagon, @mirlo once they start federating over AP, and any others that might comes along in future (how about it @jam .coop? SubJam/@jordan)
What AP brings to the table is a few million people using a growing social network, which has included music publishing platforms for some time, and will hopefully include many more. A social network developed by people who are passionate about open protocols, and keen to use any new ones that solve unsolved problems. A lot of IndieWeb people are active in the fediverse too, and they’re also super keen on documenting and building network effects for such protocols.
You may have missed;
There is. It’s called writing an FEP! Describing how an AP software like BandWagon or FunkWhale would ingest data from your static site (or potentially FairCamp sites), and make it discoverable in the federated search space that spans them. Or whatever else you want to be able to do.
I did not miss either of those points! What I’m getting at is I’m not building a social network. I am building an interchange format for content ingestion.
The part of Bandwagon I would be referencing is how they deliver audio to TheIndieBeat. Is that even done via ActivityPub?
I think this statement isn’t true. There isn’t anything right now remotely looking like an exploitable widely adopted interoperated music streaming ecosystem either built on AP or built on anything at all.
It’s important to realize we’re not trying to build a new music listening paradigm off of existing social networks. On the mainstream side, people don’t go to Twitter or Instagram or whatever to listen to their music (or movies, or videogames). They might discover that some music exists through those (much like they can discover that movies and videogames exist through those) but these tools are fundamentally not built to manage the complex states of music metadata and listener relationships.
Like, I feel so far, the AP integration of any music related services is pretty limited and not particularly speaking for itself in terms of how much it has acheived. I view it as an interesting side “good to have” feature to help with discovery in some marginal cases, but clearly not as the de facto obvious basis to create interoperated music stores networks.
2 Likes
Yes, this. Also, Canimus isn’t replacing ActivityPub. It’s not a social network, it’s a content ingest format that lives alongside other things.
Different protocols are useful for different things. I’m not saying that ActivityPub is a bad protocol, it’s just not applicable to what Canimus is meant for.
Like, the old saying, “If all you have is a hammer, everything looks like a nail” applies here.
I could see a case for maybe building Canimus on JSON-LD instead of being plain JSON, but it also adds a lot of complexity that doesn’t seem to serve the purpose of the format.
1 Like
I’m sorry I’ve failed to communicate clearly in this thread. Despite my enthusiasm for trying to help, I seem to be doing more harm than good 
I’m going to leave this to folks like @bandwagon @mirlo and maybe @kidlightbulbs, who are actively working on music-related software, and can get into the nuts and bolts of what you want Canimus to do in ways that are over my head. But if I may be of help, in any way, please feel free to @me 
1 Like
yes. The other questions have answer in the proposed spec.
you can use the `category` attribute or you can rely on the api you uses to get the feed. for example I i an album api endpoint returning a feed, i now the feed represents an album, so items are tracks.
Could you please provide an example of what this looks like in a feed? Also what do you mean by API in this context, and how does that relate to the static hosting goal?
there is various examples in the proposition, is something missing ? Since musicbrainz has a namespace very well defined you could do whatever you want.
forget about the api, in any case we can get the content type by using musicbrainz ns