Standards-based cross-app podcast comments (2024)

[johnspurlock]

Given the renewed interest in this topic, I thought it might be worthwhile to publish a quick public perspective on the current state of things, building on a few conversations I've had recently. This will not be new to folks that have been following this topic for a while (e.g. back when I made the podcastsocial.org site), but we now have a few more apps wanting to get started, and more fediverse folks in general.

Most of the hard work has already been done (by folks like Benjamin Bellamy/Yassine Doghri at Castopod, Alecks Gates, & Dave Jones), but some amount of the easy/fun work remains. There is no free lunch in an open system, particularly one that deals in user-generated content.

My bias is for pragmatism, so I'm going to focus on the opportunity as it exists today (and short-term) in the world as it is, there are enough gold nuggets just sitting on the ground waiting to be picked up by podcast apps/services that are willing to roll up their sleeves, without boiling the ocean or waiting for a far-off future system or an off-the-shelf solution.

Indeed, one of the reasons to be bullish about ActivityPub is that it is less about client→server conformance to a single platform, but more about independent, standalone systems with different goals & release schedules publishing a subset of their functionality for server→server interactions without losing a sense of what differentiates their own app/community in the first place.

The immediate goal

At a high level, the initial idea is that although existing podcast apps may have a robust commenting system within their own app, it would be better if:

• comments about the same episode could appear in other podcast apps
• these discussions could leverage existing social accounts for basic interactions like replies/follows/likes
• interested podcasters could express a venue preference for comments about their shows, and thus a level of moderation over the "canonical" federated view of the discussion for respecting apps to display
• we had an integrated view of "comments with payments attached", unforgeable and available to all apps, not just the publishing app

While this overview talks about ActivityPub as the protocol, one can map the same concepts to other systems providing similar identity systems and similar extensible payloads. Also other public systems can be bridged.

The Note-iverse and ActivityPub

With the formalization of the podcast:socialInteract tag in the podcast namespace we now have a way for podcasters (or their proxies, the podcast hosting companies) to clearly express the venue for federated commenting around a single episode, an item-level tag in the RSS feed that specifies the protocol + uri.

One might think we are done here, we can throw a Mastodon link in there, and that's it, right? The magic of ActivityPub!

I'm finding that although folks have some idea about what Mastodon is, terms like ActivityPub & ActivityStreams [1] [2] are thrown around loosely without knowing exactly where they fit in. Perhaps Evan's book later this year will bring a more detailed look at the system that for now you kind of need to piece together from various places and a bunch of trial and error.

Also, there are podcast apps that seem to want a free lunch, the ability to ride on top of an existing API to other servers, and delegate all social interactions to other systems.

There are two major issues with this approach, one is that although the Mastodon world is larger than it was the first time we looked into this, not all podcast commenters are existing Mastodon users, nor will this ever likely be the case. We are looking to build a podcasting-wide system here, not a Mastodon-constrained one.

The second issue is that when you delegate all interaction via someone's existing Mastodon account, you are not using ActivityPub at all for posting! You are just using the Mastodon API. The ActivityPub "client-to-server" (C2S) api is underspecified (e.g. it says nothing about auth) and no existing servers support it.

What this means is that you lose any ability to provide custom podcast-specific properties or podcast-specific object types, and you lose the ability to use any other system in the fediverse that does not also happen to mimic the subset of the Mastodon API that you call. You are trapped in the Note-iverse (the basic object type used for microblogging posts), and whatever basic fields the Mastodon posting API supports. You also lose out on server push of federated replies, since you are not a peer in the system, just a client of whatever server the user happens to use. If you want to support other non-Mastodon servers, you have to implement this code multiple times!

While not ideal, apps that want to do the minimum amount of work can go this route (prompt for the user's account, oauth via Mastodon, post via the Mastodon API, and enumerate the replies collection e.g. with threadcap) and participate in cross-app comments in a limited way. It's possible we could come up with a simple tunnelling standard for appending podcast-specific properties (like payment claims) to the bottom of the message text.

However, most podcast apps should seamlessly host their own users' identities (Actors) by default and become true peers in the system.

If you think about new podcast apps like Fountain or TrueFans, this is what they already do. They manage user identities, activity, and content to some extent, and are perfectly positioned to start federating basic comments to the podcaster-specified endpoint: the ActivityPub url specified in the podcast:socialInteract tag.

In order to do this, podcast apps need to provide Actor endpoints with stable uris for each user, and stable uris for each comment. Since they own the implementation in this scenario, they'll have full control on attaching podcast-specific properties like payment claims. They'll also be responsible for taking down content if necessary since they are hosting it. They'll be notifying the url specified in the podcast:socialInteract tag on any interactions, and the destination is free to block/ignore it. They can also pull in comments from other systems by enumerating the replies collection.

The other side of the implementation

Now the question: who or what hosts the podcast:socialInteract ActivityPub url for any given podcast episode?

As long as the url supports ActivityPub requests, and supports the replies collection, it really depends on the podcaster or hosting company.

Worst case, the podcaster should have the ability to paste in an external link to an existing Mastodon or other fediverse account they control.

However, podcast hosting companies should provide these endpoint urls by default for each new episode.

Ideally, there should be no need for the podcaster to do anything when publishing a new episode, other than potentially modifying default moderation policy for that episode.

Under the hood, the hosting company could host a Mastodon server, but now there are lighter-weight alternatives that support the limited ActivityPub subset needed for the podcast comments scenarios. Basically you need a server that has the ability to manage the replies collection, since this is the canonical endpoint apps will use to pull in comments from other apps. It's likely the best approach will be to develop this themselves for seamless integration with their existing CMS and UI or partner with a hosted service.

It's worth talking a bit about how replies to an object are expressed in the Activity Streams vocabulary, and how it would look for a podcast episode.

When an episode is published and the podcast:socialInteract url defined, any AP requests to that url should return a top-level object representing that episode. It should roughly follow the fields specified in the Note object (so that it can be rendered in existing microblogging UIs) but it doesn't need to be of type Note. It could be PodcastEpisode, for example (I believe Castopod already does this). It must have a replies property, but the spec is flexible (and indeed existing servers are varied) about how these replies are implementated.

Replies can be as simple as a JSON array of string uris, each uri pointing to an object on a remote server hosting that reply. Or they can be expressed as a collection or page of inline objects. This might seem like a trivial detail, but this is the lever for the podcaster to moderate replies in this cross-app comments system. Not every incoming notification needs to be copied over into this collection. And comments can effectively be disabled by returning an empty array.

Note that this endpoint does not need to host any user-generated content at all, it can simply point to it! Hosting companies should not worry about hosting UGC here (only moderating pointers to it), we want to drive folks to podcast apps for rendering.

The implementation can be as hands-on or hands-off regarding moderation as the podcaster needs, even providing a workflow for privately reviewing every incoming comment for review before returning it in the replies collection.

Services

If a hosting company does not want to implement this system themselves, there exists an opportunity for them to partner with a generic service that provides these endpoints for any podcast episode or set of podcasts, given a podcast guid and item guid. e.g.

<podcast:socialInteract
    uri="https://comments.provider.example/podcast/<podcast-guid>/item/<item-guid>" 
    protocol="activitypub" />

Perhaps Dave could even extend his current service to provide a default implementation? Would need to support the episode level, and ideally allow a podcaster login to moderate.

Crucially these services would need to serve AP objects for the episode, serve Actor AP for each podcast, and respond to ActivityPub Server-to-Server follow/reply actions and handle them accordingly.

The rest

Now to the question of what to do about podcasters that don't care or can't declare podcast:socialInteract tags for episodes in their feed. Otherwise known as 99% of podcasts today. Are we back to square one for these shows? i.e. comments relegated to within a single app only

Ideally, every app could derive the same stable ActivityPub url to use in the meantime for any episode. Again, perhaps Dave's service could handle this? I'm also thinking about standing up something here. Perhaps we could add a new PI api call to get the socialInteract uri for a given episode that would return the one declared in the feed, if present, or the stable fallback. Very similar to the podcast:guid fallback allocation process.

The longer-term goal

Once we have podcast apps as first-class ActivityPub publishers, and podcast hosting companies/services as first-class ActivityPub receivers, we can send other activities down this channel! The tag is called socialInteract after all, not comments.

We could:

• Send user event streams (opt-in) for playback/clip creation/likes
• Send podcast reviews and ratings
• Podcasters could broadcast to these users for important merch/events

It's just a matter of coming up with a shared podcast vocabulary for our noun/verb types, starting with interactions we already know about. We have a truly open and federated model for podcast/episode-level activity while maintaining the RSS feed (ie the podcaster) as the locus of control.

TODO list

• Make sure the podcast:guid list in the index is as stable and free of duplicates/bad data as possible. It's going to be important as we start building more services with this as part of the key. I do think this is the one tag where we should return (guid/timerange) and return matches for old deleted/merged values, as referents often do not change.
• Review the current landscape of lightweight ActivityPub capable servers, both for the sender (podcast app) side, and the receiver (podcast hosting company or service) side (including Wordpress, which has landed their AP implementation!). We many need to create custom servers (like Dave has done), especially when dealing with custom objects and properties. I may resurrect minipub for this on the app side (and thread.land on the service side), but anyone is unblocked to do this today in any language/stack.
• Agree on custom comment-level fields to include in a new podcast JSON-LD context - this is the way to include custom namespaced properties in ActivityPub payloads, basically the ActivityPub equivalent of the podcast xml namespace. The one that immediately comes to mind is a string property that contains a payment claim. I love the idea of using a JWT for this, maybe Alecks could walk through an example manually? I'm not sure how this would work with services like Alby, do they have APIs to sign arbitrary data using the user's private key?

[adamc199]

The No Agenda podcast has an approximate audience of 900k (as per op3.dev). We have been publishing a root post in our social intera t tag since inception of the tag. Thousands of our listeners also have mastodon server accounts. If devs want to experiment it is a good test bed. I am happy to promote any work that includes comments on the show.

You can see comments on all episodes here:

https://podcastindex.org/podcast/41504

[johnspurlock]

yea that's great! now to encourage other self-hosters to do the same!

ideally a few podcast hosting companies could also make this simple to do, ie part of the set of services that makes their paid feature set compelling

[jamescridland]

I'd caution that No Agenda is not a typical podcast - it has around 115,000 downloads per episode, says OP3.

Podnews Daily, as one example, has an average of about 1,400 downloads per episode. It's quite a large podcast, but that doesn't mean it'll get a lot of comments per episode. Assuming that all "modern podcast apps" have a market share of 5%, and then assuming that only 5% bother to leave a comment for an episode, Podnews would get 3 comments.

A typical podcast has just 31 downloads. Any commenting system needs to work for the typical podcast.

I suspect that the right plan here is to enable podcast:socialinteract at the CHANNEL level for most shows, to avoid the "empty pub" phenomenon. Nobody wants to go into an empty pub. If there are a few people already there, that's good.

Then, by all means, have an ITEM level tag for those shows which are large enough to justify per-episode discussions. The client behaviour, I'd suggest, would be: "IF there is an ITEM level discussion, show that, otherwise show the CHANNEL level discussion".

FWIW, Podnews has always supported the socialInteract tag like this:

<podcast:socialInteract uri="https://social.podnews.net/users/podnews/statuses/112177926790210697" protocol="activitypub" accountId="@podnews" accountUrl="https://social.podnews.net/Podnews" />

...and I'm unaware of a day where we've had more than a single comment. Most days we have none.

[johnspurlock]

Careful, then you lose the ability to like/clip/playback/boost an episode. The problem of minimal comments is something that a good app can work around when bringing up the episode (ie aggregate from other episodes/show-level if no comments) - it's a interface concern imo. A good app's UI is more than a simple regurgitation of the item-level feed info.

I do think extending the spec to allow an additional show/channel-level socialInteract tag is a really good idea though. Think show-level ratings/reviews.

[jamescridland]

Interesting! Yes, so perhaps the spec might have an optional channel-level tag but a mandatory item-level one?

[johnspurlock]

I mean this is RSS, nothing is mandatory per-se (I've been looking at particularly horrible xml today), but yes I guess we'd recommend that a full implementation would likely have show-level and episode-level interactions and would support both, and having no distinct episode level tags means you lose out on any episode-level interactions in the future (the engine for new content to surface elsewhere), so would discourage show-level only.

I think of something like the Google Maps UI where there are comments on the restaurant, and comments on the kung pao chicken. If it is a popular restaurant you need to drill into the chicken as a kind of filter/thread, but if it's a new restaurant they all appear in the top-level view (labeled if about a specific item).

I did a quick peek and it looks like Castopod has no socialInteract at the channel level in the rss form, but I wonder @benjaminbellamy if Castopod has show-level interactions at the ActivityPub level? likes/replies/boosts etc. I would assume it does, and (after checking the next day) it appears Castopod shows are actors/accounts, AP type Person (e.g. original show + federated show) and episodes are indeed of type PodcastEpisode (e.g. https://show.tuxbase.com/@nta/episodes/the-year-plasma-desktop), but Castopod also keeps an associated root Note for each episode (e.g. original episosde note + federated episode note)

If I remember correctly a show-level socialInteract almost made it into the formal podcast xml namespace but was one of the things we cut at the end in a desire for simplicity @daveajones

[theDanielJLewis]

Thanks for restarting this conversation!

Replies can be as simple as a JSON array of string uris, each uri pointing to an object on a remote server hosting that reply. Or they can be expressed as a collection or page of inline objects.

I urge us to make the source of truth be what the podcaster owns/controls, not merely by where the feed links to, but where the data exists. So apps pull from the podcast's centralized activity stream, not from all federated responses. This centralized authority would also be far more performant that following a tree of reply URIs and all the HTTP requests that would require.

Now to the question of what to do about podcasters that don't care or can't declare podcast:socialInteract tags for episodes in their feed.

I think this, like all other features, should be opt-in. If a podcast doesn't declare the feature, then it doesn't get the feature. Some podcasts are under legal constraints to moderate the conversation that is displayed with their content. Some podcasters don't want comments on their episodes. I don't think we should be auto-enabling cross-app comments for podcasts that don't want them, just like we don't make Satoshi wallets for all podcasts.

[theDanielJLewis]

It is: the podcaster controls what url they put in their feed, and can point to a system that supports their moderation requirements, including turning comments off entirely (return a static empty array).

I don't see that as ownership or control. But I realize I didn't explain that point well (I'll edit my original post for clarity, too). I mean that what the feed points to should be the source of truth for the interactions, not all the federated responses. In other words, even if a response to the root post exists somewhere out there, if it's not in (not simply linked to) the data the podcaster provides, then it doesn't display in apps.

[johnspurlock]

ActivityPub is a federated system, not a centralized system (can't wait for the O'Reilly book to come out!). A federation of independent systems that work just fine on their own.

The id of every object (every comment) is a uri on the system that created it. When someone comments on your episode, they are commenting in their app, but letting you know. You can include that in your replies collection or not. Podcast apps will look to your system, not theirs, for pointers, but the content of those messages are owned by them, not you. You can't change what people say, or make up stuff for example - you can just include the comment or not.

[theDanielJLewis]

ActivityPub is a federated system, not a centralized system …

This is why I would love for us to focus more on ActivityStream, not ActivityPub.

Podcast apps will look to your system, not theirs, for pointers, but the content of those messages are owned by them, not you.

This will becoming an ever-increasing performance problem as more federated apps come online and will have to crawl all kinds of remote links in order to display the comments.

That's why I think the comments should exist in the podcaster's central activity stream (and they can link out with URIs for reference). Otherwise, you'll get the horribly slow performance that I've seen on Podcast Index's own implementation of the rough ActivityPub method.

[johnspurlock]

The replies collection can be as simple as an array of remote pointers, but definitely can include the entire object contents inline (the ids are still remote uris, but the entire payload can be a copied inline object instead of a string uri in the json array)

I sort of touch on this above:

Replies can be as simple as a JSON array of string uris, each uri pointing to an object on a remote server hosting that reply. Or they can be expressed as a collection or page of inline objects.

You might have fun creating your own example endpoint and trying it out for yourself. Or checking out what other existing fediverse implementation do. The model is flexible (arguably over flexible) in this regard.

[theDanielJLewis]

You might have fun creating your own example endpoint and trying it out for yourself.

Can you point me (and other AP/AS-unaware devs) to a good resource to learn how to do this?

Granted, I'm still a scrappy developer in a JavaScript-focused tech stack, so I know I might struggle with understanding a little more than others. But I am committed to building support for this into Podgagement, when we have a standard to follow.

[theDanielJLewis]

My top five concerns for any solution here:

1. Having a centralized source of authority for consistency and performance (Solving performance for cross-app comments #612).
2. Hosting boostagrams within the social interactions so we don't have to compromise privacy by adding wallet splits (Solving boostagram visibility for cross-app comments #611), and this would also allow visibility of boostagrams in apps that support cross-app comments but not native boostagrams. This would, again, keep the podcast's data as the authority.
3. Ensuring moderation capabilities for the podcaster (Solving moderation for cross-app comments #610), and this must be more granular than completely blocking a user.
4. Upholding data portability. If the ActivityStream data is centrally hosted and the source of authority, the podcast should be able to take that data elsewhere—such as to a different podcast-hosting provider, publishing tool, or to/from a third-party social-interaction provider.
5. Supporting future extensibility, like ratings, reviews, and more.

[johnspurlock]

All good points!

1. see my comments on AppViews above
2. This is purpose of the payment claim mentioned above. The flow is: user sends a "superchat" (message+payment), the app initiates the payment, and mints a corresponding unforgeable payment claim at the same time in the form of a JWT. the app then federates this comment out with the payment claim either in the custom json context as a podcast:paymentclaim custom string property (better) or appended to the bottom of the comment text itself (fallback where you are posting to someone else's Mastodon server etc)
3. Podcaster has complete control to choose where they host their socialInteract url, and services can compete on providing infinite levels of moderation based on the incoming replies
4. Totally agree. One nice thing about open systems like this is that the worst case is that the new provider can literally copy all of the replies collections from the old provider and repoint to the new provider. It's all public. If this sounds familiar, this is exactly like how RSS feeds are "imported" into new podcast hosts when podcasters "move" their show. Nice providers can provide redirects to the new providers, but the podcaster can point to the new provider whenever they are ready to switch over. Blocklists and other service-specific settings would be icing on the cake, but really specific to the type of provider, let's see what that value-added data looks like once we have a few good providers in place.
5. This is what's so great about the model that ActivityPub uses. It supports payload extensibility via custom json ld contexts (named prefixes, very similar to xml namespaces, but in json). I would love to see this group publish a document describing properties likely to be needed for social podcast scenarios not already provided by the base activitystreams object vocabulary. Things like the payment claim property mentioned above podcast:paymentclaim, and perhaps rating values podcast:rating podcast:ratingscale etc. Could even embed the podcast:guid and podcast:itemguid as custom properties inside the message Note objects as well.

[theDanielJLewis]

2. This is purpose of the RFC: JSON Payment Token #490 mentioned above. The flow is: user sends a "superchat" (message+payment), the app initiates the payment, and mints a corresponding unforgeable payment claim at the same time in the form of a JWT. the app then federates this comment out with the payment claim either in the custom json context as a podcast:paymentclaim custom string property (better) or appended to the bottom of the comment text itself (fallback where you are posting to someone else's Mastodon server etc)

I think this sounds good. I'm less concerned about the implementation and more concerned about the actual functionality. I just want to see anytime someone sends a boostagram that the data also goes to the activity stream (where it can then be made public or kept private). Sam Sethi and I talked about this in our discussion on The Future of Podcasting. Imagine someone sending a boostagram saying, "I just want to show my appreciation for you! I was about to kill myself last night because of my addiction to killing puppies, but your podcast stopped me from pulling the trigger." That's probably not the kind of thing that should go out to the public or to third-party wallet providers! (I've discussed separately why I think boostagrams should be private by default and no one in the "fees" split should receive messsages.)

5. … It supports payload extensibility via custom json ld contexts …

Mmmm! JSON! 🤣 (I don't actually have a JSON fetish as some people think. But it's fun to pretend!)

Once we can have a system in place, I have a bunch of ideas what the fields we should support, especially when it comes to ratings and reviews because of my experience with Podgagement (formerly My Podcast Reviews).

[dellagustin]

You are just using the Mastodon API. The ActivityPub "client-to-server" (C2S) api is underspecified (e.g. it says nothing about auth) and no existing servers support it.

A minor correction here, Pleroma, as far as I have tested, actually supports C2S for read and write. There might be some other implementations out there.

If Mastodon supported it for write as well, this would be a big win. Lack of an auth standard is a big deal.

Another issue with C2S for webapps that do not have their own server is CORS. That is an issue even for fetching the comments, I had that issue when implementing support for it on podcastindex.org.

P.S.: I have some words to write about content forgery, but I will leave it for when I have more time.
P.S.2: This are my research notes on this topic - podStation/podStation#304