I’m somewhat active in the Podcasting 2.0 community. This community works on the Podcast Namespace, which extends the RSS standard with new tags for podcasts. For example the podcast:person tag (to identify individuals heard in the podcast, both presenters and guests), or the podcast:funding tag (to indicate ways to financially support the podcaster). Podcast hosts should support them; podcast apps should use them.
The loose group is now also discussing comments (via a podcast:comments tag), and one venue that is being explored is ActivityPub.
The goal here is a YouTube-comment-like-experience. But then in some decentralised fashion. I see some open questions regarding
hosting (where are the comments hosted; by podcast host, podcaster, podcast client app, or another specialised comment entity)
moderation (should probably be the responsibility of the podcaster, but this depends on who hosts the comments)
inclusion (should comments be gathered through a hashtag of some sorts, or is there a single thread that is displayed)
initiation (who gets to ‘start’ a comment thread, and who has control over this (client app, podcaster, no-one))
technology (should we rely on Mastodon, or create a ‘new’ ActivityPub-based standard specific to comments? If something new, in which ways should it federate?)
Adam & Dave (who basically initiated the Podcasting 2.0 community) are discussing the comments concept here - I would recommend listening to it because it probably gives a better idea than my summary above:
It would be great if the ActivityPub community could chip in. Every 1,5 week or so there’s a community developer meeting, and the first next one is Wednesday 7 July at 20:00 CEST. I’m pretty sure that Podcast Comments will be on the agenda for that meeting.
If you prefer to chip in on Mastodon, there’s a discussion thread here:
Sounds like you know way more than I do, but just to be sure: It sounds like what you want to do for podcasts is what Indieweb does for blog posts. https://indieweb.org
ActivityPub requires a degree of dynamic behaviors (delivery, processing incoming peer data, etc) that is far above and beyond what RSS requires, so there’s some sunk cost to adoption that may act as a barrier.
Where ActivityPub starts to shine is when you have to come up with the next thing to implement, after solving comments, plus how you want such software to interact with the greater web. If you need the flexibility that ActivityPub provides and have already paid the sunk cost and want other app writers to potentially integrate, then it starts to pay off dividends. If you just want a quick win for a one-off feature and less engineering work and don’t care about wider ecosystem interactions, it’s less appealing.
In my humble opinion, the choice of whether to adopt AP is more philosophically about how one views growing an ecosystem – a question I can’t answer for others.
Note, at the time of this writing I haven’t listened to the Podcast in the OP.
The way commenting works in ActivityPub is that someone creates an object, for example a Note, and others reply to it by referencing it in the inReplyTo field in their notes. So it makes sense that each podcast is an actor, and each episode is an object created by that actor that people can comment on.
You do need a server application of some sort for ActivityPub — no getting around that. It could be very barebones, but it at the very least needs to support other actors following yours and then sending activities out to followers. In your case it would also need to store the list of comments (replies) and return them in the replies collections.
Hey, all, comments for podcasts are already live in an experimental form and we have at least two supporting podcast players, Podfriend and Podverse, that can show comments (but not yet reply to them).
The requirement for podcasts is that the <item> tag contains a podcast:socialInteract tag as in the following example (taken from the Podcasting 2.0 feed):
I did some research on my own before I got to know John’s document - this research is intended to support the implementation of this feature in podStation in the future: https://github.com/podStation/podStation/issues/304
For podcast client developers that do not want to run an ActivityPub server, the main challenges (from my perspective) currently are:
Lack of widespread Client 2 Server (C2S) ActivityPub support
Lack of standards for authentication with servers (closest to a standard is the Matodon app registration API + OAuth)
Doesn’t work for me. I’m trying Podcastindex.org – the URL in your screenshot. Do I have to be logged in or something? oh nevermind, had to click the show link… didn’t see that at first.
Sorry for my long absence here, I think my email notifications are not working well, I need to check that.
According to the my own notes in the PR where I implemented it, I tested Mastondon and Akkoma, which I think is a fork of Pleroma.
