#activitypub It seems like we will need to define a Podcast ActivityStreams object type. I’ve been trying to see if we can just transmute a podcast into an Audio or Video object type. But the loss of fidelity is so high. I think a dedicated object type...

Dave

The existing types are probably fine for most of the subclasses we need. So, the transcript property can just reference an Attachment object or set of Attachments if multiple.

The Podcast object itself can subclass Object of course, and then perhaps things like Podroll can just be a collection of Podcast objects since each will contain a guid and feedUrl.

John Spurlock

@dave why would this be necessary? we already have rss feeds for podcasts, and canonical pointers (feed urls, guids, apple ids)

imo activitypub is the social layer, not some sort of alternate view of the same data - it's not a one to one sort of exercise

wakest ⁂

@dave cc'ing @evan @julian @AntennaPod folks in this. Seems we really need a activitypub podcast working group as these days as well.

Dave

@js Right, but the objects being socialized need to be represented in some way as objects first. If we’re adding ratings to AP for the purpose of rating a podcast, the podcast has to exist as an object to rate. Right now that would have to be rating some Note version of the episode’s data which seems unfaithful to the original data.

John Spurlock

@dave I'm not sure custom objects are the way to go, only hosts like Castopod really have the publishing side + social hub in one place. If you're thinking about what the namespace might need to standardardize, I think for max interop, custom _properties_ are the best way forward, that way all of the existing note-based systems work with full fidelity (for liking, following, reposting) and newer podcast clients can also know the subject

e.g. the podcast Actor could declare podcast:guid etc

John Spurlock

@dave once you start creating custom objects, most of the existing clients peace out - and while our new stuff is primarily for podcast apps, we don't want to lose the ability for existing fediverse folks to do the things their apps can already do

I _think_ the Castopod folks hit this very early on - I believe they tried going down the custom object route (since they "own" the model there), but ended up creating Note endpoints so others could actually interact

Sam Sethi :pc2red: ⁂

@dave Trying to understand this. We have actors which are primarily listeners/fans. We have verbs (play,boost, follow etc.)and we have objects (podcasts, episodes, books, artists, publishers) e.g sam follows Joe Martin Music

I would love to organise a call with you and @js and @benjaminbellamy to hash this out.

John Spurlock

@samsethi @dave @benjaminbellamy sure sounds good, I'm up for a call sometime next week

From the client side (you are way ahead), your side is relatively straightforward: syndicate standard AP actions like/repost/reply to the socialInteract endpoint defined in the feed, and also send custom verbs for the podcast-only things (like plays etc) which will fall on the floor right now

I'm working on a thingie that podcasters can put in their socialInteract tag as a receiver (instead of Mastodon etc)

Guy Martin (Dwev) :pc2red:

@js @dave yes, I was thinking “are we trying to replace RSS here?” Why do we need to bring in the PC2.0 features into the object? Don’t we just point to the RSS feed or the base url to get all this info?
The only stuff needed in the object would be how to find the podcast, and anything needed for promotion like images, clips, etc.
It needs to almost be AP native, so it can interact with any AP client without them doing any extra work, right?

John Spurlock

@dwev @dave yes, what's cool about the podcast:socialInteract in the feed, is that we don't really _need_ any custom podcast: json-ld context to get the majority of cool stuff working - ie no one is blocked on any PI standards work to integrate with existing fediverse apps

the cherry on the sundae would be a common set of properties in a podcast: json ld context defined for certain already-known things to tack on to existing Actors and Notes

ie the ones mentioned here: https://github.com/Podcastindex-org/podcast-namespace/discussions/623#discussioncomment-8973851