Sockpuppet Blog.

Silos

In IndieWeb terminology, a “silo” is a website that operates basically in isolation from others, or where it’s a single site that is not under the control of its users, that attempts to be the single source of truth for everything. In social media parlance, this would be sites like Twitter X, Facebook, Tumblr, that sort of thing — a single dashboard that people sign into and can only see stuff from that site (or things posted directly to it), where the data is formatted based on that site’s requirements and are subject to that site’s moderation whims. Any interoperability with other sites is generally done through a special-cased partnership or API-based agreement.

Note that something being a “silo” isn’t a value judgement; it’s just a statement of the way in which the site or service operates.

In the music space, here are some of the better-known silos, which I present mostly as a point of reference when discussing the independent alternatives:

• Streaming providers, such as Spotify, Apple Music, Tidal, Pandora, Amazon Music and so on:

  These are places where where you pay a monthly subscription fee (sometimes in the form of ad revenue) to get access to their libraries, and presumably some amount of this subscription cost goes to pay for the music that they host in some way (although the people receiving that music are usually not the musicians, but that’s a whole other rant).

  The streaming silos tend to get their content through partnership agreements with distributors such as DistroKid, TooLost, TuneCore, CDBaby, amuse, and many others. While distributors handle the annoying parts of submitting musicians' content to the streaming providers and managing the payments in return, these partnerships are still formed directly and not available to the general public, and they, too, are silos.

• Storefronts, such as Bandcamp, Mirlo, Gumroad, Ko-Fi Shops, itch, etc.:

  These serve as places where people can make their music available for sale, and sell it, often with other value-add tools such as mailing lists, blogs, merch stores, and so on.

  These are often silos out of necessity, as handling payments is actually super tricky for a whole bunch of legal and business reasons. However, none of them work as just payment providers, and instead they’re all all-in-one does-everything things, often with the expectation that a musician will use that site as their one and only place to actually make their music available for discovery.

  Mirlo is an interesting case in that it’s run using a co-op governance model and strives to be as fair and equitable to the musicians as possible, but it is still a silo. There is only one instance of Mirlo, you cannot subscribe to a musician on another site from Mirlo (or vice-versa), and if you want to sell stuff on Mirlo, you have to adapt it to the specific capabilities that Mirlo puts in place.

• Discography and discovery services, such as Last.fm, MusicBrainz/ListenBrainz:

  These sites attempt to catalog all known music and help people to discover more of it. Often this is through a combination of user submissions and through so-called “scrobbling” software, where someone installs a bit of software to track the music they’re listening to and provide it as structured data back to the site, usually with varying levels of fidelity.

  One of the intended purposes of all this is to find relationships between music, such as “these bands have these members in common,” or “this recording had this guest performer on it,” or also recommendations such as, “If you like this song, you’ll probably also like this song.”

• Media hosting sites, such as YouTube and SoundCloud:

  These sorts of sites are basically fancy file hosting, where people can upload a piece of media and then others can watch/listen to them, usually for free (via ad revenue), and there’s often discovery and recommendations as well.

• Licensing clearinghouses, such as Songtradr, PlusMusic, or the late great Magnatune:

  Music gets used in way more ways than simply being listened to on its own. It’s often used as background music for commercials, video games, films and TV shows, Twitch streams, YouTube videos, and so on. Licensing agencies allegedly help with the difficult parts of getting one’s music heard and getting those fat stacks of royalties. Allegedly.

• Livestreaming platforms, such as Twitch, Picarto, Floatplane, YouTube Live, etc.:

  Sometimes musicians like to perform live for an audience. These platforms provide that ability, as well as a modicum of discoverability based on popularity and stream content. However, they tend to be problematic for live music, due to rights-related issues, bogus copyright claims, and overly-aggressive copyright enforcement in general. They also tend to be ad-supported and the ad breaks are often not in exactly the best place when it comes to music.

Federated services

A so-called “federated” service is one where it’s designed such that there’s multiple instances of the software running independently, but there is interoperable communication between them, so that, for example, a person on instance A can subscribe to updates posted to instance B. Think of it as being like email, where someone with a gmail.com address can still send a message to someone on beesbuzz.biz and vice-versa; there’s no central authority on who is able to send what to whom, there is just an agreement in the form of an open protocol that allows anyone to join in, and no need to form a particular partnership for two things to talk to each other.

In the music space we have a number of things like this:

• Mastodon: This isn’t technically a music thing, but a lot of musicians are on it. Its basically a federated version of Twitter, where people can post about stuff they like or are listening to, or can share clips of what they’re working on, and it’s just basically a free-form discussion microblogging thing. Mastodon is often what people think of when they hear about ActivityPub, which is the main underlying protocol it uses for instances to talk to each other. There are also other things that speak the Mastodon protocol suite and interoperate with it, including Akkoma, GoToSocial, and a bunch of others. The collection of systems that interoperate in this way are generally referred to as “the Fediverse.”

• Funkwhale: This is basically an ActivityPub-based implementation of SoundCloud, more or less.

• PeerTube: And this is an ActivityPub YouTube-like.

• Bandwagon: This is a (currently early development) ActivityPub-based thing that’s essentially a federated version of Bandcamp or Mirlo. The overall goal for it is to have federated discovery and perhaps the ability to purchase in a cross-instance manner as well.

Self-hosted things

Self-hosting a music website is a bit of a challenge; while you certainly can use pretty much any website publishing platform for that (this site, for example, uses Publ¹, and many musicians use things like WordPress and the like), there’s only a handful of things that are tailor-made specifically for making self-hosted music sites.

• Faircamp is a static site generator that is geared specifically towards allowing people to have a one-and-done thing for encoding all your files, generating nice HTML, and providing an interlinked discography, on any website that allows for static hosting. It also has a mechanism for “soft” payment gateways, where you can set up an external payment provider in order to sell a hidden link to a .zip download. It’s quite nice if your needs are specifically what Faircamp was designed for (which is basically a self-hosted Bandcamp analog).

• Bandcrash is a tool meant to encode albums and generate standalone HTML players that can then be embedded on another website. I wrote this specifically to make it easier to publish albums to my itch.io page, although I also use it in places on this site (such as the client work section), and at some point I will switch to using it for the embedded player on all of my album pages (I just need to get around to supporting a couple of things first).

• Blamscamp and Scritch are, similarly, player embed generators, although they require you to do your own audio encoding.

  Bandcrash originally used Blamscamp as its player, incidentally, and at one point I was considering switching to Scritch before I ended up just writing my own, Camptown. I do intend to eventually make Blamscamp and Scritch options for the player for those who prefer it, though.

• Owncast: This is an ActivityPub-enabled live streaming platform. It’s what I use for my own streaming setup.

  I list this as being “self-hosted” rather than “federated” because it isn’t really federated in the general sense. An instance can only host a single stream at a time and there’s no real login (aside from chat names), but you can subscribe to stream notifications via pretty much any Fediverse account, there’s a limited amount of chat identity management using IndieAuth, and there’s plenty of bots which will happily share stream discovery events to the greater Fediverse. It’s a publish-only sort of federation, similar to providing an RSS/Atom feed on a blog.

• Plex and PlexAmp: Self-hosted music streaming (á la Spotify/Pandora/Apple Music/etc.).

  This is a bit different than the other things here in terms of it being for simplifying your own consumption of music, rather than publishing it, but it’s an important part of the ecosystem in this modern, connected era. If you buy your music from people instead of just renting it, this is a perfectly good way to get access to it everywhere. It also has a discovery and recommendation mechanism, although that part is a paid add-on to Plex itself and my understanding is it only helps to recommend things you already own for having a semi-curated continuous music listening experience.

Protocols

The goal of interoperability is to make it so that musicians don’t have to redo work in a lot of places. Right now, when a musician wants to release some music, they have to upload it to a bunch of different places: music distributors, social media, every site they want to sell it on, and so on. This is a lot of work, and it gets increased every time someone needs to make a change to something (such as correcting a typo in the lyrics).

In my dream scenario, I’d be able to just post an album once to a site I control (be it this one or something like Bandcamp or Mirlo), and then have it picked up by all of the other places I want my music to appear.

One of the most important things about interoperability is having a protocol through which things can interoperate.

Most of the things listed above use ActivityPub with various ad-hoc data standards for the actual data exchange.

Another approach to interop is adopting composable protocols such as RSS/Atom and mf2 (preferred by the IndieWeb community) to provide the data in ways that can be parsed by external tooling. Any piece of software that publishes music to the web should also provide some common format that can be discovered from the page and then used to provide the data in a more computer-digestible way.

On this site I have attempted to provide some amount of mf2 and atom data; for example, the main page provides a feed of albums and blog posts in mf2 (which you can parse using pin13.net), and each of my album and track pages try to provide structured information about their content as well (for example, you can see the structured data for Transitions and for Behind a Mask). And of course for subscribing to updates you can point a feed reader at pretty much any page on this site.

There is no current widely-agreed-to standard for music interchange, however; I’ve been working with the developer of Bandwagon to try to establish some common ground (which I will attempt to support both on this site and in Camptown).

There do exist some protocols already, such as schema.org’s CreativeWork types, and OpenGraph’s “Music” namespace. These protocols are not widely-supported either, and leave a lot to be desired, as they are designed in the interest of search engines and social media companies, not so much individual creators.

What’s the point, anyway?

Imagine a world where you can post a release to your website and have it show up on social media, in discovery and recommendation feeds, or on genre-specific streaming radio stations that actively promote the artists (given appropriate permissions, of course), or any number of other things I haven’t imagined just yet.

And with a little more work in terms of payment- and license-related information, imagine being able to have things like automated sync licensing for placements in video games and short films and podcasts.

And imagine being in complete control of how your stuff is presented to the world to begin with! Even if you don’t want to build your own website from the ground up, imagine being able to choose your favorite existing software and use that to run your web presence, and if you don’t like something about it, being able to switch to something else without having to redo everything from scratch!

This website is the fourth time I’ve completely rebuilt my web presence from the ground up, and I hope that it can be the last.