Things I Can't Build: Podcasting on ActivityPub

EDIT: 2019 --> 🎉 I'm reviving this project. My work on Quirk is hitting a much more stable point which lets me come back to this. Feel free to read it though. 🎉

---

I normally like to write stories that teach some technical subject; if you like those as much as I do, then this article may not be for you. It's not particularly polished and not meant to be anything more than a call for maintainers. 📺 Regularly scheduled programming will return shortly.

Over the last year, I realized that there's plenty of things that I would like to build, but I probably won't get to.

In order to better maintain balance in my life, I limit myself to two types of programming attire:

• A single core project (currently Segment)
• Individual learning

Although a side project can fit into individual learning, the purpose is self growth, not the product itself. At the moment, becoming a better writer and researcher is my current individual learning theme.

But some stuff should be built

There's a number of projects I would love to see built, both because I think they're insanely valuable for the world and also because I think they'd be fun to work on.

If you're looking for a large meaty project, will these into existence for me, wontcha?

---

ActivityPub should Save Podcasting

Podcasts are having a bit of a moment. Listenership is way up as better and better podcasts are released and more folks learn that they too can fill every waking moment of their life with two dudes talking.

At the same time, the technology that podcasts are built off of, RSS, is slowly dying. The death of RSS in a single graph at andrewchen

Many larger players have noticed this, mainly Spotify and have swooped in to try and fill this need. Within the next 5 years, Spotify could take it’s place as the “YouTube of Podcasts.”

But that begs the question, why, after many years of podcasting success, has there not already been a YouTube of Podcasts?

Podcasters will lose control

However, it’s very easy to predict a future in which a larger player like Spotify comes in to give Podcasters both more features than RSS can provide but also less control; potentially for the detriment of the medium.

We’ve actually already seen this exact situation play out with blogs. As RSS readers died out, bloggers had a harder and harder time connecting with an audience and were forced to either implement their own subscription service or hop on an existing platform like Medium.

Yet, this now means that Medium is in charge of who sees what. Their algorithms are the ones deciding what’s popular and seen rather than a user’s individual choices. We left Medium. Here’s why. – Latterly – Medium

At the same time, YouTubers suffer from a similar problem because they have no real way to connect with their audience in a world where youtube shows you what it thinks you want instead of what people actually want.

But wait, wait, wait RSS isn’t dead yet, why would podcasters switch over?

Because as it stands now, a centralized system can offer podcasters significantly better tooling and features than RSS.

Spotify can offer you up to date, accurate metrics on who listens to your podcasts. They likely could offer you exactly when people stop listening and metrics about your audience. These are all serious business concerns for podcasters who survive off advertising. A lack of knowledge puts them at a disadvantage as having a bigger audience and not knowing it will lose you leverage in a sponsorship negotiation.

Plus, Spotify can give a more clear and understandable rating system for listeners, unlike the existing one that’s “somehow” based on Apple iTunes ratings.

And Spotify has a huge network and can pitch new listeners on shows they might not already know about. For podcasters, this means a whole new audience!

These advantages come at the cost of losing ownership over your audience though. Yet, once podcasts move to Spotify, it’s hard to go back. Spotify has the money and influence to advertise itself to a growing podcasting market as THE place for podcasts.

It’s likely that in 5 years, many lay people will associate podcasting with Spotify.

A solution and path forward

What we need is a new, open and distributed standard. RSS succeeded because anyone could setup something.

However, it’s very difficult to create a new standard and instantly acquire adoption.

So instead, let’s look to standards that already exist.

Mastodon and ActivityPub

At the moment, there exists a federated twitter clone that’s gaining steam. It’s got roughly a million and a half active users.

Mastodon is based on a network protocol called ActivityPub. ActivityPub lets several different websites talk to each other.

That’s how a single mastodon instance can talk to another mastodon instance.

But also, it’s how Mastodon can talk to other sites based on ActivityPub. A weird quirk of this system is that someone on Mastodon can subscribe to the feed of someone on PeerTube, a youtube clone based on ActivityPub.

That provides a ridiculous advantage.

We’ll put the podcasts on the ActivityPub

We need to put the pub in public radio. (Sorry Laugantias).

ActivityPub would allow anyone to spin up a podcast without ownership by a centralized authority, but with all the benefits of one.

ActivityPub is extensible enough that we can make our own features on top of it, just like how mastodon does, but interoperable enough that we can instantly plug-in to a large audience of people (the fediverse).

We should build a Mastodon for Podcasts.

There's 💸 money 💸 here to support development

If open source doesn't get funding it can die due to burnout.

ActivityPub servers have to be hosted and someone's gotta pay for it. Many podcasters already pay for media hosting; they might as well pay for one where they get better insights into their audience.

Comments

[chenge]

Sounds great, I'd like to know more about AP of W3C and Activity Stream data format in JSON.

Decentralized should be a player in the Net.

[rhymes]

Hi Evan, I like the framework of your idea and the principles it stands on but I have to play the devil's advocate here and try to poke holes.

Given that the premise of a decentralized network has next to no appeal to the common person (it's an implementation detail, a big one but still...), where you lose me a little bit is in what's not present in the post. The three main selling aspects of podcasts on Spotify (regardless of the very real danger of creating yet another wall garden) are search, analytics and the already existing user base.

The user base factor might be mitigated by the counter offer of a free and borderless community far from the whims of a single corporation known by underpaying the content creators. This part is huge and a well crafted message will sway some, especially due to the fact that Facebook, YouTube and Spotify have essentially the same business model and various degrees of shady tactics when it comes to content.

What I'm not so sure about (here comes the poking) are the other two key features and how they would be implemented on top of activity pub / mastodon: search/discoverability and analytics.

Can you shed some light on these two features? Thank you

[Evan]

a decentralized network has next to no appeal to the common person

I think it does have appeal to podcasters though since it gives them control over their business.

The user base factor might be mitigated by the counter offer of a free and borderless community far from the whims of a single corporation known by underpaying the content creators.

The cool thing about ActivityPub is you don't need a new user base. As long as Mastodon can convince people to sign up, there's an existing network. Plus, people go where the podcasters are. If you can convince the podcasters to go to ActivityPub, you can convince the listeners.

What I'm not so sure about (here comes the poking) are the other two key features and how they would be implemented on top of activity pub / mastodon: search/discoverability and analytics.

Let's start with the first one: Search. For sanity's sake, let's call our ActivityPub podcasting "Pubcast."

With ActivityPub, anyone can spin up a new instance of Pubcast. That means we'd probably see two types of instances.

The first one would be owned by the person who makes the podcast. In the same way that I might want a private email server. So we might see a show like:

[e-mail]

The second would be a "hub" much in the same way something like gmail is. Anyone can make an account, though they may pay the server owner for the hosting costs.

So soft skills engineering might put something on the hub named pubber.audio:

[e-mail]

So this begs the question: how do we facilitate search? Answer: aggregators. This is how podcasting apps do it nowadays. There's a couple "main" lists that someone can throw their RSS feed on, namly Apple podcasts. Then the rest of the podcasting apps either build their own lists or listen to an existing one.

This actually can allow for much more interesting search since it means server owners could be curators as well hosters.

Next topic: analytics

ActivityPub lets you send messages to and from the client. It also lets you build a spec on top of it. That means we can create a "Pubcast" spec that predefines sending analytics back.

Here's how it might work:

1. Client is following the podcast: "[e-mail]"
2. Client starts listening to the podcast. Client then sends an "ListenStarted" activity to the podcast's Inbox.
3. Client stops listening to podcast. Client then sends a "ListenStopped" activity to the podcast's inbox.

Note that these are nonstandard Activities in the ActivityPub spec; which we'd probably do as to not accidentally introduce weird behaviors when interopping in other services.

[rhymes]

I think it does have appeal to podcasters though since it gives them control over their business.

Sorry, I meant the users. I don't think people care about how the technology works behind the scenes

Regarding search and analytics: I got how search works. Not unlike any other aggregator, basically a hub with a list of all the cool podcasts that can be listed, searched, fed to third party apps and so on.

I'm still unsure how analytics would work. Yeah you can have an event source type of thing where the single podcaster knows which one of their own streams is the most popular one but what about analytics for the end user?

Let's put it this way: if it's decentralized, how can I answer the question: I listened to 10 different podcasts about crime, 5 about tech, 2 about self help, 1 about gardening.

A big selling point of Spotify are playlists derived by the user's tastes. A derivation of analytics if you will.

If, by being decentralized (this is the part I'm not sure I understood), I can't collect aggregated analytics among separate hubs or providers, I can't use analytics to give value to the user, right?

It's basically email plus a search engine, right?

I'm not saying this is necessarily wrong (it's not) but it might be hard to move users away if they are used to auto generated suggestions coming from analytics.

[Gaffen]

As an avid proponent of RSS, Podcasts and decentralisation, I think this is something quite important to be talking about.

This is something I would legitimately be interested in donating my time to if the right solution was found.

With regard to audio and the ActivityPub protocol, Have you heard of FunkWhale? It's essentially an ActivityPud Spotify clone. There's an open issue to support Podcasting:

dev.funkwhale.audio/funkwhale/funk...

It also looks like Funk Whale supports the Subsonic API. I've never heard of this before, but there are apparently a few clients out there already that can consume it:
subsonic.org/pages/api.jsp

It definitely appears that RSS is dying, there needs to be an alternative ready; the answer can't be to hand over these fantastic tools to centralisation imo.

Unfortunately I think this is the biggest barrier to entry; people like to have one place to go for their needs. If you can pay a neat monthly fee (or nothing) and get everything you want in one place, competition is already fighting an uphill battle.

I don't know how you fight this, though I think the sell needs to be something along the lines of emphasising that you're not consuming what a computer algorithm thinks you're going to be interested in, but rather you are being your own content filter. If you can make it apparent that these big monetised systems are limiting the scope of what you're exposed to/able to see then I think you might be able to get some people to pay attention. I think some people will understand that the internet has changed... That it's become harder to find something truly interesting. If you can show people that centralisation is powering this race to the middle they might start trying new things.

Just a few thoughts really - interested to know your take.

[Phil Ashby]

Going to dig this one up from the past as AP and Dev.to has had some attention (from me at least) following the Twitter exodus of the last few weeks. I know we are considering podcasting here, but I think the discussion probably applies to a wider social media context, my random thoughts follow:

So, centralization..

• why?
  • convenience for both creators and consumers of content
  • rapid development of new features for both
  • discoverability due to volume of both in 'one place'
  • discoverability due to algorithms
• bad
  • you are the product (marketing databases, privacy risks)
  • algorithm typically opaque and manipulable (cf: Facebook and voting scandals)
  • all eggs in one basket (cf: Twitter getting bought by Elon)

Decentralization via standard protocols will struggle due to:

• the consensus required to change the protocol (cf: RSS dying out as it has not changed to support new features)
• discoverability by not having all the data in one place for an algorithm (or two) to operate on (as @rhymes notes hereabouts)
• the concept of 'one place' for people to go.

In my opinion these are addressable:

• protocol change via the model used in W3C that permits evolution and promotes extensible design, and is a respected authority that developers rely on
• discoverability
  • algorithms don't have to run centrally, particularly those that operate on what you do locally (creator or consumer focused), neither do they need to 'see everything' (this is typically only required for generating that marketing database!), often metadata is enough to pick out new listening ideas or summarise activity around your content, and metadata is exactly what AP deals in. This creates an open market for algorithms that can operate independently on the AP metadata, providing a choice of local processing, trusting a small developer or a larger org, without being locked in.
• all 'in one place'
  • federation provides the equivalent of this, but some education may be required before people 'get it'. They have to trust whomever is providing their 'instance' and associated policies/filters. Humans have a tendancy to congregate, what seems to go wrong is thinking that the whole planet can co-exist in one space, that often results in chaos. What's needed IMO is a more localized approach, based on interests (tags perhaps), trust and mobility (you can run your own if you really want, you can group together with like-minded people, you can take your trust elsewhere), this is what ActivityPub supports.

I can envision the public 'buying in' to a small number of client applications (much like email?), behind which AP does the work to connect them to a number of content providers, discover new content through either local or aggregate algorithm providers, and evolve new features for both consumers and providers.