A rough proposal for cross-app comments
Closed this issue · 4 comments
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:
- 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.
- The podcaster needs moderation abilities to remove spam and abuse.
- Commenters need editing abilities.
- 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.
- IMO, the important fields should be name, email, URL (optional), date and time, and comment.
- Basic HTML formatting (bold, italics, links, blockquotes, code) would be nice to have for comment content.
- Any app or system should be able to add comments, but there should be some protections or auth.
- Commenters will probably use apps that can remember their personal information, so no need to have user logins.
- Comments should be episode-level with a new thread for every episode. Top-level commenting should be considered reviews, IMO, and with different fields.
- Commenters should have a way to get notified of replies to their comments.
- 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.
- Moderation role should be shareable in the case of cohosts or teams.
- Comments could benefit from including some other data, such as general geography, and source.
- Would be great to integrate with pre-existing systems, like native WordPress comments.
- 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.
I've thought of an idea I'm going to post elsewhere!
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.
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.
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.