@wjmaggos@liberal.city @fabio@manganiello.eu @fluffy@plush.city this is actually very interesting, and it's insightful to read how another project approached issues very similar to those I found.
Reading the specs however, I can't help asking myself "why another protocol?" 🙂
The analysis the authors make about existing protocols are very spot on, but I still couldn't see why those protocols can't be supported from day one (or perhaps two) to enable existing actors to speak similar languages.
RSS feeds aren't truly made for audio collections (audio attachments used for podcasts are an addition that doesn't change the "feedy" nature of the technology), but it doesn't mean that they can't be used by someone to e.g. subscribe to updates to a library or a playlist using any feed reader (or even podcast app) - which is what Songhive does.
ActivityPub isn't indeed geared towards collections, but it doesn't mean that it can't be integrated as a first-class citizen to manage all the "social" part, leaving the catalog management side to more appropriate pieces - which is what Songhive does, fully embracing ActivityPub for all the social+sharing aspect while having a different API to manage music collections. Initially I also thought of embracing the Emby/Jellyfin API as an existing open standard to manage the catalog, which would also make any implementation compatible for free with all the Jellyfin apps out there, but it proved to be tricky from an API consistency perspective (but I still believe it could be a good idea, especially when comparing to re-creating all the ecosystem).
Microformats are great but, as rightly said, not really an option in a world of React SPA. Still, it doesn't mean that routes can't have static microformats tags inserted at server rendering time before hitting the SPA rendering (which is what Songhive does). Microformats are actually great because they also enable rich Webmentions support for free (something that Songhive embraces).
Subsonic is definitely not made for catalog management, and it's mostly geared towards the end-user music player side, but it doesn't mean that it can't be supported as an API layer that would unlock for free a lot of apps and speakers.
You get my point - I'm not necessarily against a new protocol (even though the xkcd 927 risk is always behind the corner), but I don't see a new protocol necessarily mutual exclusive with existing open solutions - especially when it comes to fostering adoption without the initial high integration costs.
Still, I will definitely add that link to my favorites and once the solution is mature enough I'd be very glad to support it 🙂