A rough proposal for cross-app comments

[theDanielJLewis]

For context, I'll repost a slightly edited version what I shared on PodcastIndex.social:

Without knowing anything about ActivityPub, here's how I would like to see CACs work:

1. There's a "central" authoritative source for the comments. That could be powered by a WordPress plugin, a podcast-hosting provider, or a blockchain. It just needs to be accessible from anything and portable.
2. The podcaster needs moderation abilities to remove spam and abuse.
3. Commenters need editing abilities.
4. Podcasters need a way to be notified of new comments. That could either be native with the system hosting the comments, or a third-party tool like My Podcast Reviews.
5. IMO, the important fields should be name, email, URL (optional), date and time, and comment.
6. Basic HTML formatting (bold, italics, links, blockquotes, code) would be nice to have for comment content.
7. Any app or system should be able to add comments, but there should be some protections or auth.
8. Commenters will probably use apps that can remember their personal information, so no need to have user logins.
9. Comments should be episode-level with a new thread for every episode. Top-level commenting should be considered reviews, IMO, and with different fields.
10. Commenters should have a way to get notified of replies to their comments.
11. Podcasters should be able to set a comment policy. E.g., a family-friend podcast might want to forbid profanity. Policies would be manually enforced by the podcaster's moderation. The podcaster might even want to make all comments require moderation.
12. Moderation role should be shareable in the case of cohosts or teams.
13. Comments could benefit from including some other data, such as general geography, and source.
14. Would be great to integrate with pre-existing systems, like native WordPress comments.
15. There should be a way to connect comments with boosts, maybe with a simple field. This would enable some comments to be featured like the "super comments" in streaming platforms.

That said, I think what could be best is to develop an open format that can be hosted somewhere trustworthy (either by the podcaster themselves, their podcast-hosting provider, or a third-party service), posted to from anywhere, and that could maybe have watchers to include non-conforming comments (there is, however, a big problem with these, and I'll address that further down).

The easiest format for developers to support would be JSON. There would be a separate comments file for each episode, and maybe a central sitemap-like JSON file that connects the comment files of all episodes.

Here's what that could look like:

{"comments": [
    {
        "date": "…",
        "status": "pending",
        "author": "…",
        "email": "…",
        "content": "…",
        "source": "overcast",
        "geo": "…",
        "boosted": {
            "type": "sats",
            "value": 10000
        }
    },
    {
        "date": "…",
        "status": "published",
        "author": "…",
        "email": "…",
        "content": "…",
        "source": "podverse",
        "geo": "…",
        "replies": [
            {
                "date": "…",
                "status": "published",
                "author": "…",
                "email": "…",
                "content": "…",
                "source": "https://mywebsite.com/episode-33/",
                "geo": "…"
            },
            {
                "date": "…",
                "status": "published",
                "author": "…",
                "email": "…",
                "content": "…",
                "source": "castomatic",
                "geo": "…",
                "boosted": {
                    "type": "usd",
                    "value": "333.33"
                },
                "replies": [
                    {
                        "date": "…",
                        "status": "pending",
                        "author": "…",
                        "email": "…",
                        "content": "…",
                        "source": "…",
                        "geo": "…"
                    }                
                ]
            }
        ]
    }
]}

(These comments could and maybe even should live alongside the chapters in the episode metadata files!)

This allows for ownership and portability. If a podcaster wants to switch comment-hosting solutions, they could export this all as a zip and easily import it into their new solution.

With a little work, this could easily be synchronized with native WordPress comments and maybe even third-party website commenting systems (like Disqus).

Living inside the episode metadata file, the comments would be loaded as frequently as the cloud chapters.

What happens if a new comment is posted after a listener already loaded the comments? It could wait to refresh until whenever the app would normally refresh the chapters, wait for pull to refresh (PTR), and/or refresh whenever that listener posts their own comment. However, the experience of seeing comments show up immediately is not only extremely engaging, but also a huge bridge to live commenting on live streams.

I'm not sure PodPing could handle this. It's one thing for PodPing to handle thousands of episodes being posted in the same hour, but maybe (and I really don't know for sure) a completely different and impossible thing for PodPing to handle thousands of comments being posted in the same second. So real-time refresh is a definite issue, but something that could be set aside for now.

The next problem would be authentication. How do you let only approved apps publish to the comment stream in a way that's portable and doesn't require much maintenance? There could be a central repo of verified public keys, and any commenting system would need to stay up-to-date with that repo. But then that leaves things open to breaking if not updated. For example, a WordPress plugin could include the latest list of trusted public keys, but then if someone doesn't update the plugin installed on their site, comments won't work for them. So maybe the commenting system would need to reference the public repo whenever an unrecognized key is used. In other words, first check if the public key exists in the cached/local list of trusted keys, fallback to the hosted list of trusted keys, and then block if not in either list. The list could be managed similarly to how I've seen Cardano NFT policy IDs verified with exchanges like CNFT.io.

The third problem is off-system comments, and it has two sides. One side is where/how to monitor. For example, can any third-party system monitor threaded comments in a private Facebook group? Probably not. Even if it could, the system would have to monitor Facebook, Twitter, Instagram, Reddit, YouTube, Mastodon, LinkedIn, and more.

The second side of this third problem further complicates things. The conversation may happen in reply to multiple posts.

As a simple example, imagine you tweet a new episode one when it's released, and then again 2 years later because it's still relevant or it's relevant again. Both tweets receive comments, so both would need to be monitored. But this problem gets even worse when you consider a more effective social-media strategy of using different messages or highlights to promote the same episode. For example, a weekly podcast could have two posts for every day of the week, resulting in 14 unique posts promoting the same episode, and each of those posts have their own comment threads.

And then what happens if someone else shares the episode (not retweeting), and their tweet generates a whole new conversation thread.

So I think we should just exclude social comments from cross-app comments. Besides, it would be impossible for the podcast app to cross-post the comment to all the other networks.

Thus, I think the best approach should be to centralize the storage, but decentralize the interaction.

[mitchdowney]

I think a JSON standard for comments output could potentially be valuable, since right now app developers have parse out comment data differently from every socialInteract platform...but the centralized service layers that are a part of this proposal (especially for authentication and monitoring) sound like a huge undertaking with no guarantee of adoption.

This isn't something you can just create a centralized service for and let it ride. These comment platforms can change their data formats, their authentication strategies, the accessibility of their threads for monitoring...the centralized service would need constant maintenance to operate.

It's an interesting and potentially valuable service if you can pull it off, but I have a hard time seeing how (beyond the JSON comments standard) a centralized service like this makes sense within the Podcasting 2.0 namespaces.

[thebells1111]

Why couldn't comments be as simple as chapters? Attach a link to the comments JSON file, let the podcaster host it. If they don't want comments, they don't have a link, just like chapters. Then all we have to work on is the protocol for how the comments file is structured.

[theDanielJLewis]

Why couldn't comments be as simple as chapters?

@thebells1111, because comments are, by nature, far more complicated. They're 2-way interactive instead of 1-way. And there are much bigger needs for how comments should work (like my 15-item list).

But I'm going to close this and suggest that, instead, we build on @jamescridland's suggestion in #327.

[theDanielJLewis]

Here's a demonstration and Node.js code for a working cross-app comments model!

https://github.com/theDanielJLewis/cross-app-comments-engine

I had a lightbulb moment this week. I realized that everything that currently makes a podcast—RSS feed, media files, transcripts, episode metadata (including chapters), and images—are all usable as static files that can be hosted anywhere and migrated to anywhere. Why not make cross-app comments the same?

I revisited this post and still believe in everything I said in my original post. Only this time, I wanted to build a proof of concept that would showcase how simple it would be to support and implement.

You can view my source and my initial demo video on my GitHub repo, but here's a quick overview:

1. Podcaster runs a comment listener service (self-hosted, third-party, or on podcast-hosting provider).
2. Each different podcast app holds an encrypted secret key and submits the public key to a central, community-verified repo.
3. Audience member posts a comment or boostagram through their Podcasting 2.0 podcast app.
4. App sends the comment payload and the app's public key to the listener service.
5. The listener service validates the key with the verified keys in the repo.
6. The podcaster can choose how their listener service behaves:

• Everything goes into a pending queue for moderation.
• Only verified apps can skip moderation, everything else goes into a pending queue for moderation.
• Anything without a public key is automatically rejected.
• Anything with an unverified key can be held for moderation with an additional flag, or discarded automatically.

7. The podcaster uses the listener service to view and moderate pending comments.
8. On approval, comments go into the episode metadata files (where chapters are also stored) for their respective episodes.
9. Any app can read the simple JSON comments from the episode metadata file, which can be hosted as a static file anywhere.

This approach gives the podcaster full moderation control and full data portability.

The listener service can use a podcast-level JSON metadata file for pending comments, or it can store them in a database until they're published.

This approach would be extremely easy for apps to implement: both reading and writing comments. It's also open and simple enough that the listener service could be a WordPress plugin, a standalone script, part of a third-party service, or included with the podcast-hosting provider.

And I think this is the best approach for us, especially since it respects the nature of podcasting and doesn't depend on ActivityPub or any specific software.

[theDanielJLewis]

Here's how I think this needs to work in the RSS.

We use @johnspurlock's webhook proposal on the channel level to indicate the comment-listener endpoint. For example:

<podcast:webhook type="comments" url="cross-app-comments-listener-URL" encrypt="true">

type marks that only comment events should be sent to this webhook.

encrypt (or maybe auth?) indicates that it should contain an encrypted authorization field or header using the app's internal private key.

Since recording my demo video and making my proof of concept, I've come to understand how key pairs work. But instead of encrypting the whole payload (and thus preventing a listener from being able to process the data at all), I think it payloads should include a single authorization or token field encrypted with the private key and decrypted with the public key (hosted in a public repo) to confirm the request came from a verified app.

Building on my proposal for feature exposure to be in the RSS while metadata is in each episode's JSON metadata file (where chapters already are), the items would include the following tag (with chapters thrown in for example):

<podcast:comments url="https://example.com/episode1/metadata.json" type="application/json" />
<podcast:chapters url="https://example.com/episode1/metadata.json" type="application/json" />

(Is application/json really necessary, since the only format we would support would be JSON?)

If a podcaster or publishing system wanted to overcomplicate things and cause extra HTTP requests, they could make separate files for comments and chapters, but I think it's best to consolidate them into the single episode metadata file.

[jamescridland]

Let's split this proposal into bits.

I like the idea of the comments being hosted in a single file by the podcaster in some way - that makes the creator responsible for the comments that are published. I also like the idea of the comments for "whatever is being commented on" being in one file. That's a much better system than what appears possible with the activitypub solution. One JSON file (or whatever) containing all the comments for the object being commented on. This is good.

As a separate file - completely separate, not part of a chapters file - it allows a podcast hosting company to do this work; or an enterprising self-hoster to do it; or a "podcast comments company". This is why I'd caution on incorporating this data with any other data from other sources. If we do that, this is good.

Comment moderation isn't necessary to complicate this specification with: that's up to the creator. Some might want proactive moderation by approval; some might want reactive moderation. The only thing I'd suggest is to build in some form of "report this comment" url as an integral part of the comment; if it's populated, the app should surface that in some way.

The complicated bit is the user authentication and user management - "who is this" and "can I ban them", to put it bluntly. There are privacy implications in this. Some app developers may not want to store anything about their users (Overcast is one example, AntennaPod another). Giving this to the app developers to handle seems a hurdle that we should try to avoid. On the reverse side, some creators might be keen to collect email addresses of the people who are taking part in the chat - and as long as this is optional, I don't see an issue with that being available to creators as a feature.

One reality is that for almost all users, they'll have one of two IDs - either an Apple ID or a Google ID. App developers would need to build in both services, though, to use those: and it's unlikely that some would be keen to do that.

Alternately, and this is relatively imperfect, if an app stores an email address of the user, then we can use that as a method of identifying a user and banning them if necessary. Podcast creators can make the choice as to whether they want to validate a supplied email or not - some might be happy with any comment, others might want to only publish comments from users with validated email addresses. That's all cool. An email address would, at the very least, enable a creator to have that control. "Hey, Daniel, thanks for your comment! Just before we publish comments from you, it would be great if we can just check this email address is you. Can you click this link and tell us?" - so, essentially, a response to the app that literally says "check your email to continue!"

Perhaps that's a thing in the podcast:comments tag. identity=email might tell the app that a) they need to ask a user for their email address, and b) provide that when sending a comment. That allows this to be open enough to allow other forms of identity in the future.

As mentioned elsewhere, though - I'd like any comments tag to be available on a channel and item basis - i.e. "here is where you can leave comments about the show" and "here's where you can leave comments specifically about this episode". Many/most podcasts won't have enough traffic for episode comments.

In short, then: yes, a separate file; yes, all comments in one place; don't worry about moderation; and it's the user management we need to consider here. Is that helpful?

[theDanielJLewis]

Thanks for the feedback! I especially like the identity attribute suggestion, I just might try implementing it differently so the app can choose how to uniquely (and potentially anonymously) identify users instead of the RSS feed.

As you'll hear me mention in the next episode of The Future of Podcasting, I'm keeping podcast reviews in mind for this, and that's where I see the need for channel-level "comments." Channel-level conversations would be missing episode context. So if someone wrote, "I tried this and it didn't work. I got this error …." The podcaster would have little to no idea what the audience member is referencing because there's no context. But if that comment could be left on only an episode, then the context is there.

Plus, the most ideal time for commenting to happen is when playing an episode, and thus it would take more steps to reach channel comments versus the immediately available item comments.

[theDanielJLewis]

About the comments and chapters data, they can be separate files if they really must, but they can also be the same, since there's no such thing as a chapters file, only a file that holds chapters.

[theDanielJLewis]

I added authorId to my sample script and spec. That ID can be anything unique to that audience member: an email address, a UUID, or anything as long as it sticks across episodes and podcasts.

This further supports @johnspurlock's webhooks proposal, so an audience member's activities can be uniquely grouped without compromising their privacy.

[theDanielJLewis]

I'm working on the app-authentication model, now that I finally understand how key pairs work (I'd never studied that before). It has a few kinks I'm still working out, but it definitely allows for different behavior for a verified source (the app) compared to an unverified source, as long as each app can securely store a private key it will use to encrypt a value in the POST request.

[theDanielJLewis]

I have authentication now working and built an easy keygen and auth-token-maker.

https://github.com/theDanielJLewis/cross-app-comments-engine

[theDanielJLewis]

Small but important aside from another podcaster I talked to: anytime we talk about giving podcasters moderation control, we should ensure that it has the possibility to include delegated people, too. That could be a cohost, an employee, or a volunteer.

Since my approach is open and versatile, it would have no problem supporting such delegation because the core tech doesn't limit it, but it would be on the software/service for the podcaster to let them grant teammate access.

[theDanielJLewis]

I've now added some validation to my sample script, and I'm added podcastGuid to the submission requirements for comments so that a single webhook service endpoint could receive and handle cross-app comments for multiple podcasts.

[theDanielJLewis]

Here's a sample payload for submitting a new comment via a simple POST request from an app.

Headers:

source: [podcast app name]
x-auth-token: [podcast app name encrypted with the app's secret key]

Request body:

{
  "podcastGuid": "GUID string"
  "source": "podcast app name string",
  "events": [
    {
      "type": "comment", // This would be the type so the webhook can properly handle this event
      "episodeGuid": "item GUID string",
      "date": "ISO8601 date format",
      "author": "commenter's name string",
      "authorId": "UUID, email, or any unique identifier string that will _not_ be public",
      "content": "full comment string",
      "reply": "optional comment id string for which this is a reply",
      "geo": "optional geolocation string",
      "boost": "optional boostagram data object for cross-posting boostagrams to cross-app comments"
    }
  ]
}

The listener service will generate its own unique commentId for each submission and will not publish podcastGuid or episodeGuid (because those are redundant for the single episode's metadata), and it won't publish authorId.

With this data, a single listener can route the comment to the correct podcast and the correct episode metadata, while also giving the podcaster the tools and context they need to appropriately moderate or for the system to auto-moderate.

[theDanielJLewis]

I updated the payload example to account for webhooks that would receive multiple types of events.