Notices by Dave (dave@podcastindex.social)

https://x.com/US_Stormwatch/status/1814268813879206397

12-hour timelapse of American Airlines, Delta, and United plane traffic after what was likely the biggest IT outage in history forced a nationwide ground stop of the three airlines.

#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 is going to be pretty necessary.

That would allow bringing in the properties needed for both podcast apps and Fediverse apps to treat them the same way.

An example would be the transcript uri. Where does that go? It doesn’t fit into a Document or any of its sub-types cleanly. There will be many such properties.

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.

@silverpill Yay!!

I do MIT license on everything. Thanks for the heads up. I’ll add it to that repo.

@silverpill Awesome!

I'm guessing that code will get pushed to public.mitra.social also once it's tested?

@silverpill Yep, you nailed it. Attachment struct was too strict. Fixed now.

@silverpill The 520 is happening here. I have added a response body log on that call so I can troubleshoot that deserialize issue if you can un-follow/follow one more time.

I'm zero'ing in. Lol.

@silverpill I see your testing and I'm adding more logging to help diagnose.

@silverpill I have more logging in place now if you'd like to try following again when you get a chance.

@silverpill I guess if it’s not a violation of the spec then it makes sense to allow it on your side.

I’m finishing up the instance actor on my side since it wasn’t complete. I’m treating a missing id query param as the same as id=0, meaning instance actor.

@silverpill Returning a proper Actor document for missing id param now, but still getting a 401 invalid signature on the Follow Accept. Here is the bridge's instance Actor url:

https://ap.podcastindex.org/podcasts (Mitra compatible)

Also, https://ap.podcastindex.org/podcasts?id=0 works.

@silverpill Thanks for that explanation. Will work on getting this handled tonight. 🙏

@silverpill I'm looking at it now to make adjustments. I'm seeing some confusing things out there about where/how an actor instance is actually discovered. If you have found your discovery method to be reliable then I think I should adapt to it.

@silverpill What is the actor instance url for public.mitra.social?

@silverpill Ty for reporting. I’ll grab a Mitra account and test.

@silverpill I'm getting an "invalid signature" back from Mitra when sending the Follow Accept request. Sending the Accept seems to generate a pingback from Mitra to the Accept'ing Actor's url but missing the url parameters to identify it.

I'm struggling to understand the flow that's happening which results in the invalid signature 401.

Log attached:

@alex Good point. If I start adding the LUD-16 to the actor profile would that be a solution? It doesn’t solve splits but I don’t think Nostr has real splits yet anyway.

I wonder what is the best way to handle following an ap actor from the podcastindex.org website. I'd love to have an easy way to follow a podcast in your AP feed (whatever that is) from the podcast's PI page, but not sure how to accomplish that since there is no such thing as an #ActivityPub follow protocol scheme.

Seems very similar to what @nathan has been fighting for years with podcast protocol schemes.

#activitypub #fedicasts The Podcast Index to ActivityPub bridge code is public now:

https://github.com/Podcastindex-org/pi-activitypub-server

This is still alpha software with much to do, but it's stable and working.

Episode and Live monitoring threads should now resurrect themselves if they panic, and it's way more tolerant of deserializing wonky AP JSON.