SocialInteract - a proposal to both significantly simplify it, and also to extend it

[jamescridland]

Changelog

• This is v2.1 of this idea; taking comment from Stephen Bell, and reformatting the comments file away from JSON and into RSS. I am editing the root post here with the latest ideas.
• This includes the <source> tag

The podcast:socialInteract tag seems to have failed to achieve critical takeup. I wonder whether we can both make it simpler for app developers to display comments, and more extendable for those who wish to accept comments.

I believe we can do this by splitting the content of the comments from the protocol to post them.

Where I think we are going wrong

Here's what the spec says, to both retrieve and post comments:

<podcast:socialInteract priority="1"
  uri="https://podcastindex.social/web/@dave/108013847520053258"
  protocol="activitypub"
  accountId="@dave"
  accountUrl="https://podcastindex.social/web/@dave"
/>
<podcast:socialInteract
  priority="2"
  uri="https://twitter.com/PodcastindexOrg/status/1507120226361647115"
  protocol="twitter"
  accountId="@podcastindexorg"
  accountUrl="https://twitter.com/PodcastindexOrg"
/>

In order for the app to display both these comments, the app would need to:
a) write an activitypub client to read the comments from the "priority=1" section's URL, which is a complex piece of programming, and requires significant HTTP traffic (multiple to-and-fro hops) to achieve this.
b) apply for a Twitter/X API key. Pay for one. Write the raw code to read the comments from a tweet and lay out responses in a cogent way so that they make sense when read back
c) also write an activitypub client to allow an ActivityPub user to OAuth into their chosen fediverse server, and then post a message directly from the app, otherwise it won't appear
d) apply for a Twitter/X API key (and pay) in order to allow a user to leave a comment there, otherwise it won't appear

And the spec is being simple - because the spec apparently supports not just activitypub and twitter, but lightning, bluesky, hive, matrix and nostr.

No wonder nobody is doing this.

A suggestion

We retain, unchanged, the podcast:socialInteract tag. This is used (optionally) for the app to post comments, if required. But it is no longer used to retrieve the comments. Instead, we just link to an RSS feed of the comments.

Within the RSS feed <item>, we use the existing RSS 2.0 comments element.

This links to an RSS feed of the comments for this episode.

<comments>https://mypodcasthost.example.com/podcast24352345/episode354879324/comments.xml</comments>

(Gotcha: The RSS 2.0 specification does not specify what format the comments should be in. My proposal here is that for podcasting, we commit to always link to a comments RSS feed.)

The RSS feed would look (something) like this.

<rss>
	<channel>
		<title>MyPodcast comments for EpisodeTitle</title>
		<link>https://mypodcasthost.example.com/podcast24352345/episode354879324/</link>
		<pubDate>Tue, 10 Jun 2003 04:00:00 GMT</pubDate>
		<lastBuildDate>Fri, 21 Jul 2023 09:04 EDT</lastBuildDate>
		<item>
			<author>Adam Curry</author>
			<link>https://adamcurry.example.com</link>
			<image>https://adamcurry.example.com/avatar.jpeg</image>
			<description>Go podcasting! This podcast is excellent.</description>
			<source url="https://castamatic.com/">Castamatic</source>
			<pubDate>Fri, 21 Jul 2023 09:04 EDT</pubDate>
		</item>
		<item>
			<author>Dave Jones</author>
			<link>https://davejones.example.com</link>
			<image>https://davejones.example.com/avatar.jpeg</image>
			<description>This podcast is so good it made my computer reboot spontaneously!</description>
			<pubDate>Sat, 22 Jul 2023 14:04 EDT</pubDate>
		</item>
	</channel>
</rss>

In the above <item> elements, "link" goes to the user; "image" is a square avatar; "description" is the comment content; "pubDate" is when the comment was last edited. The optional "source" tag allows identification of the app being used (and yes, that's also a RSS 2.0 tag). The "author" tag in RSS 2.0 is supposed to be an email address, of the form [email protected] (My Name) however where this construction is used, it's often also possible to just place a name in there.

Benefits are:

For podcasters

1. A podcaster can use whatever moderation they wish to use, to remove comments if they wish, or only include certain comments.
2. A low-traffic podcast can elect to, for example, place all comments in all episodes if they want, so that there are always comments to read. Or, perhaps, they may wish to display comments that are about "the show" in all indivudual episodes UNLESS there are comments about that specific episode. It's up to the podcaster what comments appear.
3. It's likely that there will either be a podcast host who wishes to implement this themselves; or a third-party provider who could do similar.
4. Podcasters could even restrict comments to those who are donating to the show, or boosting, or whatever.

For podcast hosting companies

1. You could use your own commenting system, if you already have one - no need to install and maintain unfamiliar software like Mastodon (at some stage we need to work out how to link and/or post to this)
2. You can outsource this to a different provider

For listeners

1. Comments will load instantly
2. Leaving comments (could) be done using the app of the listener's choice, if it's installed, under their own username
3. Comments can also be read in RSS readers

For app developers

1. Comments will load instantly - it's just one HTTP call, rather than complex handshaking of bearer headers and following threads
2. There is no requirement to write any specific client interfaces into Twitter, the fediverse, etc. A user can leave a message just by following a URL which could open their social media app, or a website.
3. However, an app developer can certainly write specific client interfaces to post to Twitter, the fediverse, etc, should they wish to. This removes no advanced power from a developer, but makes it much easier.
4. Use of RSS could mean reusing a parser library already in the app

[redimongo]

Fully support this, could we please add two optional fields?

• appName (where comment came from - this will be good for podcast apps sending boostagrams)
• appIcon (a 500x500 square logo of the appName)

These are just optional fields that boostagramLive supports.

Just about to push out the Boostagram Live update with according to the example above

Disregard this section of code,

It was old code with @jamescridland first idea for v2 see James update as we now conform to that standard.

{
  "comments": [
    {
      "from": "russell",
      "uri": "https://truefans.fm/fans/russell",
      "avatar": "https://podfans.s3.eu-west-2.amazonaws.com/users-665d85a27a5b479bafd0949b%2F59a1b9fc1804347d68a44359.png",
      "appname": "Truefans.fm",
      "appicon": "https://truefans.fm/icon.png",
      "comment": "Great episode, really enjoyed it",
      "episodeGUID":"25bb767d-c129-53f9-9732-a284a8a92f77", //We can drop that one 
      "datePosted": "Thu, 12 Dec 2024 06:00:57 GMT"
    }
  ]
 }

so the searches can be for Boostagram live app are the following (maybe too many options?)

• https://(installed domain)/comments/[walletname]/[podcastGUID]/[episodeGUID]
• https://(installed domain)/comments/[episodeGUID]
• https://(installed domain)/comments/[podcastGUID]
• https://(installed domain)/comments/[podcastGUID]/[episodeGUID] // This is what PodToo uses by default for items
• https://(installed domain)/comments/[walletname]/[podcastGUID]

But these will it will be clear in the URL of the socialInteract

<podcast:socialInteract
version="2"
comments="https://(installed domain)/comments/[walletname]/[podcastGUID]"
</podcast:socialInteract>

<podcast:socialInteract
version="2"
comments="https://(installed domain)/comments/[episodeGUID]"
</podcast:socialInteract>

<podcast:socialInteract
version="2"
comments="https://(installed domain)/comments/[podcastGUID]"
</podcast:socialInteract>

<podcast:socialInteract
version="2"
comments="https://(installed domain)/comments/[walletname]/[podcastGUID]/[episodeGUID]"
</podcast:socialInteract>

It might be a little overkill of options for a creator but I'll make it super easy in the settings that allows a user to select one, and we will have it so it auto alerts you if an episode doesn't have the socialInteract in the RSS feed for you to copy and paste into your rss feed.

PodToo will automatically insert these into your RSS if you use it with PodToo.

UPDATE

Based on RSS 2.0 we now have the option for JSON or XML
https://boostagram.live/comments/1249e592-9942-51f3-a526-aa1538c3349f/25bb767d-c129-53f9-9732-a284a8a92f77?type=json

https://boostagram.live/comments/1249e592-9942-51f3-a526-aa1538c3349f/25bb767d-c129-53f9-9732-a284a8a92f77?type=xml

[jamescridland]

Thanks for this. The EpisodeGUID field isn't required in this - the JSON file is already for an episode.

I'm not entirely sold on additional cruft for identifying apps. I'd ask a) what is the user benefit? I can't think of one; b) what is the benefit for app developers? It seems not ideal to be promoting competing apps.

[redimongo]

So DRN1 produces a number of shows we have them on podcast Apps for us and maybe other creators they have their own website. We would like to show where the comment came from so we can be nice and say you can see our show on these apps.

I see that podcast players may hide those fields on their own player.

As I have said to some by showing comments from other apps you make your own app look like it has a larger user base which is always something as a user of an app I look for.

The more users the more I'll be persuaded to use an app (just who I am)

[jamescridland]

Having now rewritten the comments in raw RSS... the source element would work well here within each comment if the podcaster wishes to support this.

<source url="https://castamatic.com/">Castamatic</source>

Logos are best left to the client to produce locally.

[redimongo]

i am not a fan of XML for comments, seem that we should let the app developers tell us what they want - like I'll support the XML layout but I'll also support JSON output as some developers (including me) like to work in JSON for iOS apps and other technologies.

[redimongo]

Ok we now have JSON and XML

https://boostagram.live/comments/1249e592-9942-51f3-a526-aa1538c3349f/25bb767d-c129-53f9-9732-a284a8a92f77?type=json

https://boostagram.live/comments/1249e592-9942-51f3-a526-aa1538c3349f/25bb767d-c129-53f9-9732-a284a8a92f77?type=xml

and if people agree that the default is XML I will make that change but atm it's JSON.

[thebells1111]

I've always thought this is how comments should be handled, and found socialInteract to be a confusing tag. So, I am 100% on board with this.

My only suggestion is we don't need to make it a breaking change. I have the philosophy that we can extend tags, but we can't break them. Once they're finalized, they must remain backwards compatible. If we're going to make a breaking change, we're better off just creating a new tag. <podcast:json-comments url="xyz.com" />. (I don't care what it's called, this is an example)

However, I think we can use socialInteract without breaking it.

<podcast:socialInteract
      uri="https://(installed domain)/comments/[episodeGUID]"
      protocol="json-comments"
</podcast:socialInteract>

As an app dev, I would simply filter out all protocols but json-comments. With version 2, I'd still have to filter out version 1 socialInteracts, so I think we can just add it as a new protocol and accomplish the same goal.

[jamescridland]

Nice thought. We'd leave the protocols and endpoints for comments in the socialInteract tags, therefore, but just link to a JSON-comments file. I like the idea of not breaking things. The only thing I'd say is that keeping all the data about comments in one file makes it much easier to maintain that data, instead of having to also republish the podcast RSS feed. Typically, posting a seed URL for comments to a podcast episode can only happen after the podcast episode has been published; so the current plan necessitates a lot of re-republishing.

[thebells1111]

I think Adam posts a dummy file for his chapters and transcripts when he publishes his feed. Then he doesn't have to republish the feed, he just updates the file the feed point to. I wonder if comments can work the same way. Fundamentally, I'm not sure why comments can't be just like a chapters file in it's execution.

On the app side, I can see using POST to the url to add to the comments, and GET to fetch the file. The podcaster could do something as simple as appending to a text file or as complicated as having a database and the GET request fetches everything from the DB and builds a comments file on the fly.

We can even later add other features to the implementation, like a ?flag=2 so a listener is able to flag problematic comments (in this example the second one) and the podcaster's server can quarantine them or review them or whatever. There's a lot the podcaster can do with his own server. I really like how simple this tag is, and it's always been important to me that podcasters were able to make sure the comments were in keeping in the brand of their podcast, so being able to edit the file makes a lot of sense to me. I think this one has a chance to be a real winner, and is simple enough to see wide adoption.

[jamescridland]

On the app side, I can see using POST to the url to add to the comments, and GET to fetch the file.

I'd like to suggest that this is out of scope for this change. All I'm trying to do here is make it easier for an app developer to grab comments (from wherever) and display them. I like the idea of adding comments from apps, but it's very complicated to get right, especially with the possibility of spam, so I think it's worthwhile being cautious and slow with this bit.

"Flagging" shouldn't be required here - if the podcaster is producing their own JSON comments file, their own tool should be able to handle moderation and things. But yes, all this can certainly come.

Let me rewrite the suggestion at the top with your thoughts in mind.

[thebells1111]

Okay, that makes sense. So your idea is just a simple way for an app to GET a comments file, just like they do with the chapters file. How a listener creates those comments is a separate issue. I agree, adding anything like 'flagging' needlessly complicates, and that's a future problem we can address later if we choose to. I'm all in favor of solving smaller chunks of an overall problem instead of solving them all in one shot, so totally on board with this being limited to simply fetching comments from a podcaster's comments file to be displayed across all apps.

[jamescridland]

Absolutely! :)

I've rewritten the OP, with two changes...

1. Using the RSS 2.0 <comments> tag to link. I don't like reinventing wheels. This seems like a wheel we don't need to reinvent.

2. Formatting the comments in RSS themselves - an open format, not a closed one. We can always add a podcastComments namespace extension later, to add things that raw RSS misses.