DEV Community

Discussion on: Things I Can't Build: Podcasting on ActivityPub

flaque profile image
Evan Author

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:

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

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: ""
  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 profile image

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.