#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.
It occurred to my today that I have been coding for 40 years, starting with ZX Spectrum BASIC and currently enjoying #dart and #flutter. I still love #coding, it still excites me and I am always learning. I can't image a time when I don't code.
@amugofjava Very cool. The first code I ever wrote was BASIC on a Commodore 64. That was probably 1987 or 88 I guess. Those were the good old days when they would ship a BASIC language manual with the computer, in the box.
Producers, investors, app builders, hosting parties, hosts, listeners, everybody: spread the word of Podcasting 2.0 among your professional peers. Boost this meeting of the board #168 with @adam, @dave and guest @benjaminbellamy .
@caseyliss@Penultimate I’m proud of the work we’ve done around tags like <podcast:transcript> (which Apple Podcasts just adopted), <podcast:liveItem>, <podcast:socialInteract>, <podcast:medium>, <podcast:chat>, etc. Those are features RSS didn’t have natively and were worth the few years of effort we put into them.
The biggest knock against RSS podcasting is that closed systems (it was Spotify, now it’s YouTube) have more/better features. Our entire goal is to make that argument moot.
It seems like a mistake that you can't pass an LNURL (or LUD-16 identifier) straight into WebLN to pay an invoice. The client should not have to connect to remote servers and do the whole back-and-forth just to zap someone. This makes it impossible to implement Lightning donations in Soapbox as a purely client-side feature without completely removing the CSP.
@alex@ChadF The simple answer is that Lightning Labs never liked keysend because it was a sender generated nonce instead of receiver. They did it sort of begrudgingly. The initial Lightning spec worked purely on invoices and there has been a weird hesitancy towards keysend ever since. It baffles me.
@alex@ChadF The true solution is BOLT12, which obviates the need of all of this by allowing for open invoices to live forever and accept any amount. LND is just now starting to build this with v0.18.
Tapbots trusted Twitter and it wrecked their company. Apollo trusted Reddit and it wrecked their company. Many podcasters trusted Spotify with their shows and it wrecked their shows.
If/when Apple and Spotify join up and started lending a hand with things, they'll have an equal voice to everyone else and I'll appreciate it. But, I will not chase them. They have a track record of hurting people and projects.
@alex@silverpill@errhead Podcasting 2.0 doesn’t use LNurl. It uses “keysend” because it eliminates the need for round-robin to get an invoice and thus makes things simpler/faster for podcast apps sending payments sometimes multiple times per minute.
A custom URI format is probably needed here in order to bring all of that payment information over intact. It can include a key/value pair for routing the payment.