Fabio Manganiello

View original page

@fabio@manganiello.music · Joined ⁨Sep⁩ ⁨2026⁩

🛠️ Creator of #Songhive
⚙️ Chronic tinkerer
🎸 Pretends to be a musician
📢 Social
manganiello.eu
🛠️ Development
git.fabiomanganiello.com

I was unhappy with most of the #music tech products out there.

So I built Songhive as a self-hosted music platform that had everything I wanted:

  • 💿 Standard music library management. Playlists, albums, tags, genres etc., plus automatic deduplication and audio metadata management over MusicBrainz

  • 📂 Support for music from external cloud storage. Plug your S3 bucket, Dropbox account, Google Drive or Nextcloud folder loaded of MP3 files, and manage them under one roof

  • ☁ ️Integration with external music providers (only TIDAL and YouTube for now), so you can import your playlists and favourite songs onto your own server

  • 💰 Support for payments. Are you a tech enthusiast who would like to host a small music server for their family and friends, and would like them to contribute to the costs for hosting their music collections? You can activate subscriptions with custom amounts and custom billing periods on your platform. Are you a musician tired of being ripped off by traditional centralized music streaming platforms, labels and other middlemen, while having no control over your catalog and distribution? You can upload your tracks to a #Songhive instance, or host your own (ideal if run a small music label), connect your Stripe payout account, put individual tracks or albums on sale, and generate direct download links

  • 🗣️ Full social integration over #ActivityPub. Songhive is basically a Mastodon instance with a music library around, or a Jellyfin instance with a Mastodon server around. Publish your tracks and albums, and they'll automatically appear on your followers' timelines. You can also share content with other Songhive or Funkwhale instances, follow Mastodon accounts and interact with them

  • 📊 Listening stats and support for scrobbling to last.fm / libre.fm

  • 🔊 #Subsonic API, so you can stream music from your local instance over any Subsonic-compatible app or speaker

  • 🔁 Ability to #share your private tracks, playlists or collections with others through retractable share links

  • 📻 Live radios! Create your playlists or listening queue, and stream it over Icecast, Snapcast, or native HTTP music streams. Build your radio station and share it as a simple link. It also supports live recording. Ideal for live podcasts, for streaming concerts or jams, or add some DJ-style talk between the tracks on your radio. Check out the streams available on my instance or directly tune into a radio through a direct URL

  • 🛜 Podcasts, with support for synchronization over any gPodder-compatible app

🔗 Links

🏠 My own instance: manganiello.music 📻 My own 24/7 live radio (I may occasionally perform some guitar + loop station live jams on it too): manganiello.music/streams/fabio.mp3 🛠️ Codebase: git.fabiomanganiello.com/songhive (includes documentation to run your own Docker stack) 🛠️ Github mirror: github.com/blacklight/songhive

Fabio's Music#music

Replying to @⁨fluffy@plush.city⁩

@fluffy@plush.city @wjmaggos@liberal.city @fabio@manganiello.eu the social network side makes sense to have a single well-tested interface for collaboration . It's not only about publishing a link - copying the link and pasting it on your Mastodon instance would suffice for that.

Once you start treating ActivityPub as a first-class citizen things like mapping music tags and genres to "social" tags, or mapping private shares of tracks or albums to mention-only activities with freshly minted access tokens, all come for free.

I think I understand your approach better now. The concern of Chorus is not to build a full end-to-end solution, but just to provide a consistent as-small-as-possible protocol that covers all the needs of catalog management and distribution, rather than stiching together existing solutions that cover only part of the problem.

And I believe that the idea is genuinely promising, especially if it also manages to provide a scalable and decentralized solution to the payments issue (I had a lot of thoughts about that in my head, but for now I just slapped a standard Stripe integration in Songhive).

I will definitely keep an eye on it. I don't see much of an overlap with Songhive to be honest (Chorus is a protocol, Songhive is an end-to-end implementation that supports multiple interfaces), and actually if Chorus picks up momentum it may totally make sense for Songhive to also provide adapters for it.

Replying to @⁨wjmaggos@liberal.city⁩

@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 🙂

xkcdStandards

🎵 #RadioFabio 🔴 is live (well, at least until the next restart of the container).

#Songhive (https://git.fabiomanganiello.com/songhive) now supports live stream over HTTP.

You can spin up your instance, upload your tracks, create a stream mount point, play your tracks to that output in loop, and all you need to do to get people to tune on your radio is share a link.

The streaming session will stay active also if you close your browser tab, until another Web client takes over the output.

Fabio's Music#radiofabio