Dave

@dave@podcastindex.social
2.2K Followers
407 Following
311 Posts
Running systems at podcastindex.org
lud16dave@getalby.com
nostrnpub1pvdw7mm7k20t9dn9gful8n5xua5yv8rmgd9wul88qq5dxj80lpxqd39r3u
Show threadDaveJun 24
Oops. Forgot to insert the screenshot:
DaveJun 19
Welcome to the party.
DaveJun 12

Has this always been at the bottom of Apple's podcaster's guide to RSS or was it added recently?

https://help.apple.com/itc/podcasts_connect/#/itcb54353390

DaveJun 6
This is just flat wrong:
DaveJun 5

Live works in Castamatic beta!

Great work @francosolerio !

DaveMay 20
Any idea why Apple Podcasts Connect would give this message?
DaveMay 14
If this is as good as AI assisted speech to text can get after all these years then I wouldn’t worry about losing your job yet.
DaveMay 8
😐
DaveMay 7

CashApp turned on lightning receive. Just tested and it works. Your lightning address is: “<cashappname>@cash.app”

Game changer.

×
Show threadDaveJun 24
Oops. Forgot to insert the screenshot:
Show threadDaniel J. LewisJun 24

@dave Why only a width? That tells nothing conclusive about an image. 4,320 could be landscape, square, or portrait.

Weren't we discussing an aspect ratio indicator instead of a single dimension?

Show threadDaveJun 24
@theDanielJLewis Did you read the spec?
Show threadDaveJun 24
@theDanielJLewis The purpose being set to "apple/hero" tells you what the aspect ratio is (4:1 according to their docs) so including it in the tag isn't necessary. Including the width isn't necessary either, but could be useful for UI hinting.
Show threadJames CridlandJun 25
@dave @theDanielJLewis I think it's not useful to show the width in an example here - the apple/showhero (its proper name) has a set height/width, so I think we can usefully not include either in any spec examples. That'll remove questions like Daniel's.
Show threadJames CridlandJun 25
@dave @theDanielJLewis It seems Apple has now named this Showcase Hero, and I'd recommend apple/showcase-hero as the "purpose" tag.
Show threadDaveJun 25
@james @theDanielJLewis 👍
Show threadruisanJun 28
@james @dave @theDanielJLewis why using names defined by a company? Why not using something agnostic? What if any company disappears in the future?
Show threadruisanJun 28
@james @dave @theDanielJLewis or decides to change a name, like this
Show threadJames CridlandJun 29
@ruisan @dave @theDanielJLewis Because the literal definition of the image size and layout is also defined by that company. I do not see any issue in doing that - it’s not the only image, but this particular image specification is authored by Apple.
Show threadDaniel J. LewisJun 29
@james @ruisan @dave Makes sense. I can see both sides.
Show threadDaveJul 1
@theDanielJLewis @james @ruisan Think of it as a pass-through value. You're saying, "there is an image spec defined by this certain app, and I want to provide it the thing it wants without having to go do a bunch of proprietary stuff on their portal".
Show threadDaveJul 1
@theDanielJLewis @james @ruisan And, as a side benefit, others can see it publicly and might decide it's a nice format and pick it up as well - directly from the creator instead of having to scrape the proprietary platform's website.
Show threadDaniel J. LewisJun 29
@james @dave I think "hero" is fine unless Apple will be asking for different hero-image sizes.
Show threadDaveJul 3
@james @theDanielJLewis Change made.
Show threadDaveJun 25
@james @theDanielJLewis 10-4. Will change.
Show threadDaniel J. LewisJun 25

@dave Spec looks good!

I noticed an unforeseen potential edge case. How should the tag be treated if it includes only href and it's pointing to a video?

It can't then be assumed to be 1:1 aspect ratio, and it probably shouldn't be assumed to be the cover art.

So maybe the solution is to say that href-only should be _only_ for 1:1 images. If the href is to _anything_ other than a 1:1 image (even if it's a 1:1 video), that it should use additional attributes.

Show threadDaveJun 25
@theDanielJLewis This is good feedback. 👍👍
Show threadNathan GathrightJun 25

@theDanielJLewis @dave Adding implicit default values for aspect ratio and purpose to the spec can’t hurt.

That said, I can’t imagine app developers would trust an href-only tag of *any* media type enough to display it w/o additional validation. Their default UX will presume that the vast majority of shows won’t provide any special assets, and then progressively enhance when available. If podcasters want to take advantage of that, the burden is on them to opt-in to the necessary attributes.

Show threadDaniel J. LewisJun 25

@nathan @dave They do it with <itunes:image>.

<podcast:image> could be assumed to be a drop-in replacement (like many Podcast Namespace tags are), but also with optional progressive enhancements (like many Podcast Namespace tags are).

Show threadNathan GathrightJun 25

@theDanielJLewis So? <itunes:image> has universal support, existing norms, and guardrails built into most hosts to prevent most edge cases. That makes all the difference in the world when it comes to reasonable assumptions.

Besides defining implicit default values, which I agree with, are you bringing this up to argue a new point?

Show threadDaniel J. LewisJun 25
@nathan I'm saying the implicit default value should be that <podcast:image> works exactly the same as <itunes:image>—until you add on additional attributes.
Show threadNathan GathrightJun 25
@theDanielJLewis Agreed!