-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cross-app comments: a crazy idea for easier uptake #327
Comments
I like this idea.
I think this, too, should be as simple as adding a tag in your feed. |
Great |
I think this sounds good. My biggest concern is how PI's sponsorship will scale because I can foresee these costs growing exponentially, and faster than the index costs. Would ActivityPub support all the things (especially moderation) in my list on #326? |
I like the idea of a fallback Mastodon server that new apps could point to by default, if nothing is specified in the feed. UX could indicate at the top of the displayed comments that the app will only show comments from this fallback (or development, or bootstrap) server, until the podcaster indicates that another official comment place exists for this episode. Presuming some trusted 3p like PI (or podnews???) is willing to host/moderate/admin such a server. I was actually thinking to myself before this whole discussion that let's say I had an popular app out there today and was fired up about comments, I would definitely host an ActivityPub instance just for seeding any threads for episodes my users wanted to talk about while I was waiting podcasters to start marking up their own feeds. Your idea of a shared fallback server is essentially the same thing, but more of a useful development resource for many apps, which is a nice idea. Btw, the idea of a fallback server can stand on its own, without having to narrow down the spec. It's just an indication that people are wanting to do fediverse/ap today, which may not be the case in the future. I still think twitter is another attractive option, and am planning to implement this in addition to fediverse/ap. Also my vote would not be to limit it to feeds that support podping, but simply allocate a new thread on first request by PI episode id or feed-url+episode-guid or something along those lines. |
Let me digest this and provide feedback once I have my head around it… |
If only a root toot (:D) would be created, PI doesn't need to care (and cannot do anything about) moderation. This proposal is not saying that podcastcomments.org should allow app users to create an account there, and reply with such account. The responsability for enabling users to create comments I would say should fall with the app - either hosting their own mastodon (where their users can register), or suggesting other instances to their users. It would be cool if for each podcast a new account were created automatically (e.g. with PI ID as username, title as display name). That way, should a podcaster decide that they want to host their own root toots, there is a way for them to migrate the existing root toots to their own new instance. (No idea how it works, but in Mastodon it's possible to move your toots & followers to another instance.) |
Exactly! But as the "root toot" holder, and host of the mastodon UI for the presumably public thread, it is on them to decide who to block federation from, or which specific Notes to remove (if pressured etc). It's not much moderation but it's still moderation of a kind. They'll still get emails : ) This is why this idea is so great. The shared instance is really not much to do at all, and it would be a great bootstapping instance to start testing the incoming federation from the apps (charting this out is what I'm working on right now, and should have something to say about it in the next few days). |
PI would certainly not be able to 'remove' individual toots, and I don't know if individual toots can be blocked. Whole instances yes indeed, individual users I don't know.
Since PI only hosts automated messages, such emails could even be directed automatically to the bin. If a podcast app wants to control what is visible in their app, they should host their own instance and organise moderation. Or maybe instances could even be blocked on app-level without having to host an instance?
I'm not that technically versed. What will you have in the next few days? |
Admins of an instance can perform actions (disable/silence/suspend) on users they've sucked in via federation. These users have internal mastodon account ids just like local accounts https://docs.joinmastodon.org/methods/admin/ I presume admins are also able to call "delete status" on the local copy of the incoming federated statuses as well, although I haven't tried that yet https://docs.joinmastodon.org/methods/statuses/ ("status" = "tweet" in the underlying mastodon data model) As far I can tell so far, federation basically just validates and creates a copy of the status from the incoming server. Once there, it's a normal local Mastodon data structure alongside the locally-generated ones. This is nice for example in case the incoming server goes down etc. Kind of like email in this respect. |
Glad this appears to be well received. The moderation thing is an issue. I think: a. People can already comment on my podcast in many different podcast apps, and I have no visibility around those comments nor can I moderate them. But with this proposal, if I want to be able to moderate comments, I can - by setting my own Mastodon instance (or a third party one which I have more control over). b. What if I don't want comments? There's no easy way to achieve that, but perhaps that involves a small change to the spec to be able to turn them off. Again, I can't turn off comments in other apps anyway. c. The requirement for podping is, to be honest, a cheeky kludge. It's there because a) I think we should be promoting podping wherever we can and this is a simple way of doing so, and b) this is an artificial gate that lowers the number of new episodes treated in this way. Of course there is a question about legal liability for comments made, which I don't quite know what to do with. I don't understand ActivityPub fully, and don't know what costs are involved. But if we have so many comments that costs become an issue, wouldn't that be an amazing problem to have? |
Why are we so dead set on Activity Pub? It seems so unnecessarily hard. I've yet to see anyone provide any examples of how any app can allow a user to log in from the app and post a comment. @johnspurlock has provided a great resource, and I still can't figure out how to do it, and apparently none of the other devs can either. Being able to view comments without being able to post comments is a bad UX, and so far, all we've been able to accomplish is being able to view comments in a third party app. Until we can figure something out that makes it easy for a user to post comments inside of an app, comments will continue to falter. |
Can speak only for myself, I had no prior affinity for ActivityPub, but after looking into it, it seems tailor made for the problem at hand here. And, crucially, server-to-server federation is actually implemented across popular fediverse hosts that real people actually use. Truly exciting for those that remember the thousands of dead specs that have come and gone that never got off the ground. It solves the problem of podcasters being in charge of their space, while also remaining open to public comments from the outside. In my opinion, we don't want to be in the business of inventing another protocol for this, and associated user UI (take a look at how large the mastodon/pleroma codebases are) when something like this is just lying on the floor waiting to be picked up. Also a trending area of focus for folks (see Twitter's bluesky initiative) working on a more internet-scale no-single-vendor social media system - so it may be the right time to bet on this, certainly aligns with the properties of open rss. It's true that there is no "here is exactly what to do" document page at the moment, I plan on organizing and publishing everything I've got on it once I collect it all properly, in order to be as helpful as possible. Posting comments from an outside app with their own user system is definitely doable today (I've done it), but it takes reading bits and pieces from various places. Again, not impossible, but nothing shrink-wrapped yet (working on that too). Really just takes being excited about and looking at the strategic opportunity here. |
@johnspurlock You've done more looking into this than most, so I value your insight, and all of your documentation has been super helpful. When comments finally get working using Activity Pub, it will be in no small part due to your work. |
@johnspurlock Just out of curiosity, have you reached out to the folks over at https://socialhub.activitypub.rocks? There's some very active folks there :) I had created a thread and the reactions were quite positive overall, but I didn't follow up unfortunately. Would it be an idea to get a couple of them to join a developer meeting so improvement details (aside the ones James proposed here) could be discussed? What I find quite interesting:
Maybe PI doesn't need a full-blown Mastodon server, but something custom that creates the Episode objects, to which people can reply? |
I spent some time reviewing the history over there a few weeks ago, and it actually almost made me completely write off ActivityPub : ) You'll see lots of historical thinking and the work of coming up with ideas for new standards, but little to show for it (e.g. very anemic c2s implementations), and a lot of dead ends. A lot of the current discussion seems to be going on in the bluesky-community discord these days. What caused the 💡 to go off for me was looking at what Mastodon did with it (and therefore every other fediverse server), they basically implement a subset of ActivityPub that makes sense for a microblogging platform. It's so simple, most of it can fit into a single blog post. The exciting thing about this is everything we need for podcast comments (i.e. not much) fits into this existing subset of ActivityPub that the fediverse servers use to talk to each other today. No new standards or development work on the ecosystem's end is required. Sometimes in architecture you have a bunch of puzzle pieces in your hands that don't go together no matter how hard you jam them together, but here we have two things that fit perfectly. |
How would you feel about this, @johnspurlock? I'm not a developer but I'd be very curious to the discussions that would evolve. I feel it'd be a shame if the two communities would work in isolation and talk past each-other (even though for podcast comments an existing subset can be used, and even though there are a few connecting individuals like Benjamin).
|
So going back to @jamescridland's proposal, here's a high-level view of how one might put the pieces together:
No new ActivityPub entities are needed for this functionality, just Notes (posts) and actors. The root-posts could even be blank, or extremely minimal for these default comment posts, as the whole point is the comments underneath, and they will already be displayed in an app under the context of an episode. Could start out slowly by putting that new PI api call behind more restricted access, and/or perhaps only enabling calls to succeed for certain podcasts (popular ones or some other criteria). Any server that starts sending garbage comments over to one of these volunteer servers can be cut off from federation using the existing Mastodon admin UI. Same for federated users. And of course the podcaster is always in the drivers seat on this, presuming they can add the socialInteract tag to their feed. |
I don't like the sound of requiring people to create multiple accounts. A podcast app should require only one account, if any. Or let the listener comment with only some remembered basic information, like normal web comments. I think that enabling comments for an episode should not require any tooting, because that would get lost in the process. It should be there automatically, or not if the podcaster so chooses. Please remember the purpose of this is to make cross-app commenting easy for podcasters and their audiences. I will forever say that integrating with native WordPress comments is mandatory. So please consider whether any technology we're going with could run on a shared hosting server or (better yet) as simply as a WordPress plugin. |
I don't think @johnspurlock is recommending that. On Mastodon, you create one account. Mine's currently @jamescridland@podcastindex.social and that works everywhere on Mastodon. So, https://podcastindex.social/web/public shows me all the discussions going on, and I can comment and interact using my podcastindex.social account. (John's preamble is allowing a number of different volunteers to run Mastodon instances, lessening the load on Dave).
A 'root toot' is just the placeholder to discuss a specific episode, and that's the thing that (currently) goes into socialInteract. My suggestion is that these are automatically created (and held in the Podcast Index). Irrespective of that, you do need somewhere on the internet to act as the root thing you're commenting on.
There are already a number of ActivityPub plugins for Wordpress. I can't think of the last time I left a WordPress comment, though. If there's a genuine user requirement here, I'd love to hear it. |
So that's one more account than the podcast app(s) currently require. Thus, multiple accounts.
Regardless of if anyone adds a comment to the WordPress site, the webpage remains the primary home for the podcast and should display all the comments. There are already plenty of plugins that work to bring in the comments from Twitter and other social networks, too. |
If comments are able to be viewed and created from within a player, then it seems pretty trivial to create the same functionality on the podcaster's website without needing to bake WordPress support into cross-app comments. That seems like something a WordPress plugin author would be able to create pretty easily once we get everything working. |
(I much prefer constructive discussions, if I can whine a bit, rather than ones that just contain a list of Things That Are Wrong With A Suggestion But No Plans To Help Make Them Right, but...) OK, so... how's this work... cross-app commenting requires the podcast app to run its own Mastodon instance? In Fountain, I make an account for my podcast app. That automatically makes an account for me on Fountain's Mastodon. With Fountain's Mastodon, I can comment, via the federated commenting system, on the "root toot" held on podcastcomments.org Mastodon. So the Mastodon/ActivityPub individual account remains with the podcast app. That's quite a neat solution. That means that each podcast app needs to run its own Mastodon instance in order to enable commenting; but that then makes it simple for people to leave comments since there are no additional accounts to remember. It also potentially means that you'd be @thedanieljlewis@fountain.fm on all those comments, so that's some nice marketing for Fountain. And possibly means that if you start being a nuisance, the podcast app can suspend your account (and we know who to contact to report your nuisanceness). Perhaps that also allows other ActivityPub operations - being able to (with your permission) see the podcasts you listen to, for example? |
Apart from lessening the load on Dave, would there be any other arguments for such distribution of root objects? I'm thinking that if it's centralised it might be easier to implement a system where podcasters can 'take over' the account creating root notes (both from a tech & legal point). And it'd be possible to take load off of Dave's shoulders by working together with him on a shared task (rather than creating multiple smaller tasks). Increases the responsibility, but reduces the bus factor. All hypothetically speaking ofc.
I wouldn't require this as such. Some apps might not want the burden of it and prefer to redirect their users to one of the many public instances. Also, as a user I'd want to create my existing account rather than create a new one on the app's instance. But yeah, apps offering this would be grand. |
Is single sign-on (SSO) possible with Mastodon? That could solve the login/account complication if the apps could SSO onto the main Mastodon instance. |
I don't think there's such a thing as SSO like in a browser, for such distributed network. But there's nothing preventing apps from enabling users to log in with their existing credentials of whatever Mastodon server. E.g. I could log in with @keunes@mastodon.social, James with @jamescridland@podcastindex.social. |
The user creates zero accounts in this world, they just use podcast apps. The user opens an episode in their native or web-based podcast player, reads the comments without leaving the podcast app (app pulls the comment data by enumerating the thread below the root post specified in the "get-or-create-comment-thread" PI api call for that episode). The user, already logged into their podcast app, wants to post a comment. The user hits reply to the root comment or a subcomment in the app's UI. When the user hits "send", the app ensures this user has an identity set up on the app's underlying ActivityPub server automatically, creates and saves the local comment on the app's server automatically, and then federates that reply over to the target comment server. When other apps see that federated comment, it will have an identity like You might be thinking to yourself: "Self, if I'm an app developer, it seems kind of overkill to host my own Mastodon server simply to hold actors for my accounts, and a few comments generated by my own users, especially since my users will only ever interact with comments from my app's UI" You'd be right, but it turns out apps don't need a full-blown Mastodon server on their side, just a small service that is internet-facing that can speak the small amount of ActivityPub necessary to post/host comments and user profiles for their existing users that have commented. App developers with lots of free time on their hands could piece together how to do this today - again those posts from the Mastodon creator are helpful here. I'm also going to open source a service that does it as well, for app devs that want just want to use something off the shelf, or use as a reference point for their own service. |
Alright, I've put together a service that implements the podcast app side of podcasting comments, in other words the implementation side of one of the "podcast app" boxes on the left in the above diagram. It's able to create local users/comments/federate to Mastodon/Pleroma via a single admin rpc api. Meant to be called by your existing app's backend when one of your existing users wants to post a comment. I plan on using it myself, but I've made it a small standalone service that any dev can run on their own box. It's called Minipub, and I've started fleshing out the documentation over at minipub.dev Btw you can also host the server completely in a Cloudflare Worker, if you want to let Cloudflare worry about keeping the server running! It's still very early on, but the basics work - I plan on fleshing out more of the needed functionality like disabling users, supporting images in comments etc over the coming weeks. The source repo also has example call flows found from Mastodon / Pleroma that might be useful for others creating their own implementations. My announcement on Twitter Hope it helps! |
I just went through the process of setting up a small Mastodon on EC2 just for fun, and published my notes for anyone to steal: https://gist.github.com/johnspurlock-skymethod/da09c82e2ed8fabd5f5e164d942ce37c A Mastodon instance of this type should be able to serve as a "volunteer target comment server" if anyone's interested in hosting one themselves. e.g. the "podcastcomments1.org" server on the right in the diagram above It has open registrations disabled, since it'll only need a small number of local users (possibly even one) to post the volunteer root posts for the episodes. All of the replies will be coming in as federated replies from other servers. |
Pulling in something from PodcastIndex.social, it seems while ActivityPub itself allows users to edit their posts, Mastodon does not. For that reason alone, I think we should use the core technology, not the Mastodon stack. |
As the person who looked into that on PodcastIndex.social 😃 I think perhaps you're missing out on how important Mastodon is in the model. It's an excellent out of the box ActivityPub implementation with a great UI and it supports incoming post edits from other servers (like ones incoming from apps) just fine. Mastodon is a great choice for basically anyone on the right-hand side of my diagram above:
Mastodon is not a great choice for:
But it's unlikely any app would have chosen to do this anyway. Way overkill, and duplicate UI, etc. This is why Minipub exists, an ActivityPub implementation that supports sending edits of existing posts, as an example of how to do it, or as a microservice apps can use themselves. Also, it's the not the end of the world if let's say someone with an existing Mastodon account ("any federverse server" in the diagram above) can also send comments over. They will be in the minority, and can always delete and re-draft. Hope that helps! |
Would the podcaster have the ability to moderate the comments on either Minipub or Mastodon? |
Yes, another reason why Mastodon is a good choice, it has user roles: admins (server owners), moderators, and users. Admins/moderators can perform account or post-level moderation actions on the server. Either in the UI, or via the api. They can delete individual posts, or block entire incoming servers if necessary. Since all apps in this future world will be finding the root post host via the rss feed, the podcaster always has the final say on this. So the podcaster has choices:
I could see apps performing an additional level of hiding/blocking in their upstream apps (Minipub has/will have delete actions for helping apps with this), but that's always upstream of the root post host, which is the source of truth. |
🙁 So what you're saying is, "Yes, they have their own moderation control if they run their own server. Otherwise, they're at someone else's mercy." Here's a practical example. A family-friendly podcast gets a comment with profanity, so the podcaster wants to remove it. But they can't because they don't have the resources to run their own server. So they report the comment to Mastodon.social, who does nothing because they have no problem with profanity. And now the podcaster has no moderation ability over the comments displaying with their podcast in (someday) every Podcasting 2.0 app. |
It's true there is no free lunch on the internet - if you want full control over something, you have to either run it yourself, or be granted access to moderate on a thing someone else runs. Think WordPress vs Twitter. At least in Mastodon's case, again you wouldn't need to run it (admin it) necessarily, just be granted as a moderator on a server somewhere (say a friend's server). I encourage you to kick the tires on it using your own instance and see for yourself, since you won't see any of the moderation UI as a non-moderator user on podcastindex.social. But at the end of the day, the PC2.0 socialInteract tag specifies ActivityPub, not Mastodon - so you can find an implementation with pre-emptive comment approval if that's your thing. Actually may want to look at WordPress itself, which has an ActivityPub plugin. And you can always choose to opt out of comments entirely, by specifying Moderation is kind of off-topic for this thread though, which is more about bootstrapping the chicken/egg problem here, not the problem of so much activity that we can't control it : ) |
🚀 Just launched a hype site to get this idea going a bit more. It's actually three different things:
(I realized Dave is pretty swamped these days, so I thought I'd get a zero-dave-work solution going for folks to use in the meantime - with the goal of eventually moving these two API calls over into the main podcastindex.org API)
So now, any app can not only read and post comments, they can enable this feature for any podcast episode. |
@johnspurlock, I have podcaster.social. Want that domain instead? |
Wow, this is awesome, @johnspurlock - congrats. Suggestion - the API for
If it's a) or c) in the list above, it would be awesome if it responded with the existing root post, so that an app could then add the reply. Use case might be that there was no SocialInteract when the app first got the data, but between then and now, one was added, perhaps? This is really good work, well done |
Thanks, that's generous! I think I'll stick with the .org, since to me it still connotes a non-profit community sort of thing, which this is. It's possible that my site could even retire entirely once things get going on their own. I just noticed that podcast.social is a thing, anyone know who is behind that? |
You're right, that would be more useful, I'll do this as part of the next update |
Agree with @jamescridland. This is stellar John. |
Ok, the new behavior and docs on this are live |
If ActivityPub can be used for different data formats (we were just discussing using it for reviews), I wonder if we could add some kind of "moderator" tag to all replies to the root post, and that moderator tag would give the "owner" of the root post the ability to moderate, or at least hide, the replies via API calls, and without having to give any roles on the server. |
Yes, totally agree Reviews would be a slam dunk. They are basically comments (ActivityPub Note entities) + two extension properties:
And we'd need a comments endpoint (podcast:socialInteract) at the podcast-level as well as the episode level. I've been meaning to do a PR for the social tag, I'll do it today, including this, and an explicit opt out (platform="none"). Not sure how the moderator tag would work, might need to sketch it out a bit more. The model is for most fediverse servers today is that moderation access happens on a server-wide basis, not on an indiv post. And if it's just an extra field, not sure what that would do? Apps could just ignore it. Podcasters can simply point to a server they have moderator access on (or in the future their awesome host, which gives them this access for their posts 👀) If you're referring to the fallback root posts that we can use in the meantime, I assume a responsible volunteer server owner would respond to reports/etc especially when coming from the podcaster for that episode. I certainly would. But again this is only provisional, the podcaster can take the wheel whenever they want, as soon as they can stick the tag in their feed. |
I think there should be the option to leave a rating without a review, but all reviews must contain ratings (like Apple Podcasts does it). And the rating could simply be 1–5; it doesn't need "outOf." And I think it would be very helpful if the ratings also contained a two-letter country code and a platform identifier. Then, I could see that I have (for example) 4 ratings/reviews on Podverse from Australia. |
I think this can probably be closed now. If anyone disagrees please say so. |
On CastGarden, every podcast has cross-app comments. Users can "Like" a comment, and that commenter earns $HIVE coins (Hive network is used for Podping as well). Hive coins are accepted at all major exchanges and can be easily converted to local fiat currencies. Their network is growing fast, with a current market cap now of over $130M. Since 2016, transactions are free and your payments are received in under 3 seconds. When leaving a comment on a podcast, or a reply to someone else's comment on a podcast, the Likes that you get on your comment also have monetary value attached. Leave a nice comment on someone's podcast and yes, the audience earns too. CastGarden comments and replies are not just cross-app, but also cross-site and cross-community since the comments are all stored on the publicly accessible Hive ledger. See: |
@Agorise, how are you making them cross-app? |
Any time you leave a comment on a podcast, that comment is stored on the public, distributed Hive blockchain (just like Podping transactions). That public data is now accessible from supporting Fediverse instances, dApps, and multiple Hive front-ends, ie: |
CastGarden now supports Aggregated, Cross-network, Cross-app comments: |
Crazy idea, but let's see if this might help us think about how to get this working:
1. We amend this specification to only support ActivityPub (Mastodon or similar) for now.
Our aim should be that it's easy to support comments (both reading and writing), and we do that by having one supported commenting system. We remove all other services from the specification.
This allows us to potentially work on sample code (or to reheat sample code from others) and greatly simplify auth.
2. PodcastIndex sponsors a new Mastodon instance, podcastcomments.org (or something).
This Mastodon instance helps podcasters with a ready-made place for comments. It's free and available to everyone.
Don't want to use it? Don't use it. Any ActivityPub server works. But if you don't have one: use ours, it's free.
3. On a successful new episode via podping, PodcastIndex opens a new thread on podcastcomments.org and adds that address automatically to a socialInteract field.
This works the same way as podcasterwallet: if you can't/won't change your RSS feed to add a socialInteract field, then we can do that for you (as long as you submit via podping).
You automatically get a new thread on podcastcomments.org per episode, if your podcast host supports podping. It's automatically generated, and contains details of your episode and links to listen. It's there for every socialInteract-enabled podcast app. You need to do nothing (if you podcast host supports podping). Just post your show and go!
Don't want that? That's cool. Just write your own socialInteract field into your RSS feed, and we'll always use that address instead of podcastcomments.org. Just like value4value works.
(Don't want comments at all? Perhaps we might want to think about this, and how you opt-out. Maybe there's some form of admin view for podcastcomments.org that turns it off, in the same way as podcastwallet claims shows. But there are plenty of social apps with auto comments already).
So...
In this way,
Crazy idea, but is there something/anything in it?
The text was updated successfully, but these errors were encountered: