Nathan Gathright

Building https://pod.link ✦ Sr. Product Designer at Linktree ✦ Full of information. Some of it’s actually useful.

Blog: https://nathangathright.com/blog
Twitter: https://twitter.com/nathang
Pronouns: he/him

Public Key

npub137cyy0undngcnc9r2gctwfgtu9xhqj79m63uznkmp46h9wtwj7usugy0lh

NIP-05 Address

nathan_at_xoxo.zone@momostr.pink

Profile Code

nprofile1qqsglvzz87fke5vfuz34yv9hy597zntsf0zaag7pfmds6atjh9hf0wgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds3ahn85

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub137cyy0undngcnc9r2gctwfgtu9xhqj79m63uznkmp46h9wtwj7usugy0lh

Show more details

Last Notes

2026-04-15 15:26:38 UTC

brb just updating the firmware on my water bottle
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/116/409/420/771/308/562/original/61092569bc06b1f3.png

2026-03-20 15:12:58 UTC

- reply

I have a half-finished blog post trying to explain that it's not enough to propose a hypothetical end state with universal adoption. New tags have to convince developers that it'll be worthwhile to be one of the first to adopt it, long before a tag reaches that point.

2026-03-17 16:32:08 UTC

- reply

My recommendation is that app developers who want to support more theming in their app should document some new purpose tokens for the `podcast:image` tag, and encourage podcasters to provide the assets that would enable that richer experience in their app. That's basically how Apple does it. Just not in the feed.
https://podcasters.apple.com/support/5515-full-page-show-art-template
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/116/245/468/640/276/795/original/8df2494c95aac647.png

2026-03-17 16:20:26 UTC

- reply

Ehh, it's the kind of tag that only works with universal adoption, but the climb from 0% has so many incentives working against it. Any developer who wants a UX like the screenshots below will build a fallback for shows without the tag. Just vibe-code a dominant color extraction and derive your theme from that. At that point, a `<podcast:themeColor hex="#FFA32A"/>` tag would actually be a less trustworthy source of data than the fallback code. (Updated artwork, forgot the tag.)
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/116/245/376/958/111/671/original/de10d68c1d68af02.png

2026-03-02 17:51:42 UTC

- reply

https://github.com/Podcastindex-org/helipad

2026-02-25 19:46:31 UTC

- reply

ugh 😅

2026-02-22 14:20:20 UTC

- reply

And to chime in before a certain talking point rears its head: There's a persistent mischaracterization that `contentLink` would require apps to display outbound links that send users away from the app. This is false and needs to be corrected. Supporting `contentLink` doesn't mean showing outbound links. It means parsing URLs that describe where content exists and each app choosing for itself how to present them, if at all.

2026-02-18 01:57:28 UTC

- reply

I would hope everyone would build excellent search regardless of the amount of AI slop out there!
But poking around a few different apps for the top news story of the day would lead me to believe that it's not a priority worth investing in unless you're a behemoth.
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/116/089/131/045/853/114/original/abc0c83f2cda19b5.png

2026-02-17 22:39:55 UTC

- reply

(From slop monetization side, they're exploiting the ad networks that don't care where the downloads come from.)

2026-02-17 22:38:19 UTC

- reply

From the app side, AI slop is specifically exploiting the podcast industry’s lack of investment in search rankings. If that wasn't worth investing in before, it'll be even costlier now, and aside from minimizing db costs, how would that investment benefit the apps?

2026-02-17 21:50:24 UTC

- reply

Apologies if this was discussed on an episode I missed, but I was thinking about the flood of slop, and how the index/hosts/apps aren't incentivized to maintain the commons.
Imagine a world where you didn't host the index, you just maintained the open-source project for other people to self-host it. Feed parsing, database ingestion, etc. and the burden of slop fell on each party's growing number of database rows. Much more motivation for contributors to find a solution.

2026-01-16 17:18:22 UTC

- reply

We discussed this a year and a half ago back when we were talking about live events! Are more apps interested in either use case these days?
https://github.com/Podcastindex-org/podcast-namespace/discussions/644

2026-01-02 20:05:55 UTC

- reply

Dave, talking about music:
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/115/827/299/686/517/451/original/d958e00e97ffa09f.png

2025-12-26 18:52:30 UTC

- reply

yeah, we’re running similar stacks. I’m happy to contribute to your fork if you don’t mind some PRs that won’t be especially relevant to Podverse. I was planning to get podcast:follow tag support working soon (example feed: https://feeds.feedburner.com/radiotopia-showcase)

2025-12-26 18:12:27 UTC

- reply

Have you seen the new thing that Dave and Eric have been working on?
https://github.com/Podcastindex-org/feedparser

2025-12-16 00:12:40 UTC

- reply

IMO the right way to draw the threshold is to ask, "If a major app rolled out auto-AI-detection, what listener-facing features would that enable?" and then ask ourselves, "If a tiny app wanted to offer listeners those same features, what new tags would get us there?"
Of course, if the new tags require broad adoption before they reach parity with the auto-AI-detection resource-intensive version, then they will struggle to gain any traction.

2025-12-16 00:04:05 UTC

- reply

Totally fair! To be clear, I’m not convinced any version of this tag will gain traction without an incentive for shows to adopt it.
My fear is that if we don’t roll out *something*, then one day we’ll wake up to a press release from Apple/Spotify/etc. saying they’ve implemented their own resource-intensive auto-AI-detection, and third-party apps will have no budget to compete.

2025-12-15 22:50:50 UTC

- reply

What’s holding you back from implementing this today?

2025-11-14 00:07:17 UTC

- reply

For an episode page, does this feel like the bare minimum to lookup an episode against an API?
The hypothetical use case I’m imagining is podcast apps sniffing links in shows notes and opening the link directly in-app rather than kicking the listener out to the web. Zero change of behavior for the podcaster.
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/115/545/121/033/364/675/original/54f3b308b5a046a9.png

2025-11-13 02:44:15 UTC

Many RSS clients automatically discover a feed by reading a `<link rel="alternate" type="application/rss+xml">` tag in the `<head>` of any provided URL.
With Apple Podcasts new Timed Link feature and Threads new podcast link integration, I want to find a solution to make it easy to detect if any arbitrary URL correlates to a podcast episode. All we would need to do is include the episode GUID somehow.
What solution do you think has the best chance of catching on?

2025-11-07 18:45:47 UTC

- reply

Feel free to send over your API docs!

2025-10-31 19:09:45 UTC

- reply

I’d love for Podlink to send visitors to this page when they tap the TrueFans icon from the Podlink live pages. Is there a way for me to programmatically discover this URL?

2025-10-16 18:22:00 UTC

- reply

I hunted down the feed that Dave presumably found that transcript file in and it was full of them 🤷‍♂️: https://anchor.fm/s/109db86ac/podcast/rss

2025-10-16 17:36:36 UTC

- reply

That’s presumably a migration from Anchor, yeah?

2025-10-10 17:30:59 UTC

In the recent discussions around the future of boostagrams, I think it’s essential to understand the **Technology Adoption Curve**.
If you’ve already jumped through the hoops to set up your own node, you’re an **Innovator** living on the bleeding edge, but **Early Adopters** wait for momentum. That flywheel accelerates by convincing more and more people of the larger opportunity ahead.
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/115/350/913/636/603/043/original/0e3be60e0354ed5f.png

2025-10-10 17:30:59 UTC

- reply

That virtuous cycle requires accelerating growth to maintain belief, but if early adopters lose faith, they can’t justify continued investment in the space. When developers reach the end of their runway, there won’t be new ones to replace them. Innovators who are happy with the way things are today may not realize the degree to which their experience was subsidized by those expecting a larger community to form.

2025-10-02 23:16:53 UTC

- reply

I mentioned this article during last week’s board room, but I think you really like this article’s intro: https://distantprovince.by/posts/its-rude-to-show-ai-output-to-people/
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/115/307/117/382/953/509/original/5bdfda9b3e7a9bcb.png

2025-10-01 00:18:18 UTC

- reply

Will the PodToo/TrueFans implementation be compatible with the RSSBlue/Fountain approach? I’ve been meaning to investigate if I should update TranscribeFM to support these newer 402 specs.

2025-09-26 19:53:07 UTC

- reply

For a while, @npub13cg…ck4q ran a service that provided an email address for your feed, which forwarded emails after spam-checking them.
I imagine hosts could offer that same service pretty affordably, maybe using an LLM to filter out guesting requests.

2025-09-26 04:47:56 UTC

@npub1rcn…dw4h Is there any plans to get the alternate enclosure into the API?

2025-09-23 13:23:52 UTC

- reply

It’s my understanding that putting HTML in your Markdown is perfectly valid. So from the parsing side of things, this could only be more complicated.

2025-09-20 21:48:25 UTC

- reply

I’ve just restructured the proposal to be more explicit that I’m only trying to address that specific scope. If there’s momentum around a more comprehensive solution, I’d be happy to support it.

2025-09-20 17:45:40 UTC

- reply

https://github.com/Podcastindex-org/podcast-namespace/discussions/731

2025-09-20 14:10:55 UTC

- reply

I never revised the proposal after Sam and Todd’s comments, but I like the idea of just extending the person tag to indicate a synthetic voice. I’ll start a new discussion on GitHub

2025-09-20 03:31:46 UTC

- reply

Here’s that proposal: https://github.com/Podcastindex-org/podcast-namespace/discussions/663

2025-09-19 18:39:55 UTC

- reply

I’m not convinced this is a problem that can be solved by a new tag. Advertisers are the aggrieved party here, and I’d expect they would like to opt out of more than just the self-disclosed AI slop.

2025-09-18 13:49:01 UTC

- reply

Thanks! Can you help me understand what’s holding podcasters back from switching to lnaddress in their value blocks?

2025-09-18 13:36:15 UTC

After listening to @npub1cwm…wcs6 last night, I started playing around with pulling boostagram metadata from Fountain’s nostr relay. Pretty straightforward! Gonna try to build something 👀
https://fountain.fm/episode/VE7RAtNKr5ifASa9RP17

2025-09-11 14:11:05 UTC

- reply

As I scope out HLS support for Podlink, is that just something Fountain hasn’t prioritized yet or is there additional complexity unique to liveItem support?

2025-08-25 23:38:07 UTC

- reply

Time to bring back Podclock, now with chapter images!

2025-08-25 23:35:44 UTC

- reply

Sorry if I misunderstood! I didn’t mean only tracking the podcaster’s own chapter artwork. I meant you have more options than just showing a 1x1 transparent gif for a split second.

2025-08-25 20:52:28 UTC

- reply

(Your tracking image URL could respond to the request with the show’s normal artwork)

2025-08-25 15:31:59 UTC

- reply

You can achieve this with the existing spec, just use the "toc:false" attribute to hide these chapters from each app’s table of contents. https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/examples/chapters/jsonChapters.md
btw, the use case you’re describing is exactly why Overcast doesn’t support JSON chapters. He sees this as basically the same as NPR’s RAD.

2025-08-18 04:32:49 UTC

Upgrading to oversized towels at home ruined hotel showers for me. I repeatedly forgot to lower my expectations. Then my first shower of each trip ends with a disappointing reality check.

2025-08-08 16:53:53 UTC

@npub1rcn…dw4h FYI, the podcasting2.org/live link will now redirect to https://pod.link/podcasting2.0/live

2025-08-01 15:46:57 UTC

- reply

paging one Chris or another! @npub1t0w…zgs2 || @npub1pfu…vnas. Any clue why the CodePen Radio feed is missing its channel-level image?

2025-07-25 17:59:26 UTC

PRX has implemented my proposed <podcast:follow> tag in their embedded player and landing pages!
https://github.com/Podcastindex-org/podcast-namespace/discussions/609
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/114/915/169/864/074/131/original/fe6b7506ba7af255.mp4

2025-07-21 19:09:41 UTC

- reply

🫶 I’m really sorry to hear you’re dealing with that. You’re doing good work, and the people who truly appreciate it far outnumber the entitled ones.

2025-07-04 17:13:28 UTC

- reply

https://masto.es/@DavidMarzalC/114084574101824451

2025-07-03 05:01:40 UTC

- reply

Let me know if this hit the mark you were looking for. It doesn’t cover every purpose we’ve discussed, but this was the most concise, self-explanatory, broadly-applicable narrative I could squeeze into a UI like this.
I’m more convinced than ever that the spec doesn’t need to be too prescriptive with purpose tokens. We can’t anticipate every hypothetical asset, but we’ve created a structure for apps and hosts to define their own vocabulary.

2025-07-02 18:59:25 UTC

Finally got around to building a new UI demo showcasing the potential of podcast image tags! Check it out yourself at: https://github.com/nathangathright/podcastimage
or just watch this video walkthrough:
https://www.youtube.com/watch?v=5-ntFwX-u_Y

2025-06-24 15:56:25 UTC

- reply

Apps are welcome to document how they’ll crop an image (e.g. Apple’s Channel Icon spec https://podcasters.apple.com/support/5518-channel-icon-template), but that doesn’t need to be defined at the tag level. A different app should be free to use that same image uncropped. Podcasters don’t get to dictate UI/UX to app developers.

2025-06-19 13:45:30 UTC

- reply

I’m afk for my brother’s wedding this week, but I should have some time next week.

2025-06-17 23:47:20 UTC

- reply

I think the use case with the highest likelihood of adoption by hosts is just `purpose="social" aspect-ratio="16/9"`
Many hosts just throw a show’s square artwork in their og:image tag, and hope for the best. But many preview cards expect a landscape image and display it like this:
https://www.opengraph.xyz/url/https%3A%2F%2Ftbf.fm
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/114/701/364/325/419/400/original/a743d2ecf82f2181.png

2025-06-16 03:34:20 UTC

@npub13cg…ck4q In case you’re interested in covering for Podnews, I believe https://apollopods.com/ has shut down. I believe I received an email announcing that fact, but I must have emptied my trash since then and can’t find it. I assumed it would have been reproduced online, and I was surprised to see no mention of it anywhere. There are all the hallmarks of an abandoned project: Android app no longer in the app store, outdated copyright year in the footer, etc. Just thought you should know!

2025-06-12 15:57:26 UTC

- reply

A publisher feed is essentially our equivalent of an Apple Podcasts channel, yeah? That’s how I was thinking of it for EpisodesFM eventually.
Anyone generating a publisher page could design around a banner area. If there’s `podcast:image purpose=banner` provided in the feed, great, otherwise fallback to an alternate layout.

2025-06-12 01:58:44 UTC

- reply

yeah, we probably need an interactive admin UI for users, which outputs sample XML and previews how a player might incorporate that image.

2025-05-30 16:43:31 UTC

- reply

Thanks!

2025-05-30 16:00:40 UTC

- reply

No worries!

2025-05-28 21:47:56 UTC

- reply

That’d be great! Just need something to develop against!

2025-05-28 21:29:57 UTC

Podcasting 2.0 Folks: Does anyone here have a sample RSS feed using the alternate enclosure tag with an HLS-powered video stream?

2025-05-16 01:10:34 UTC

- reply

I don’t think there’s a self-evident icon for the job, which would lead me to recommend appending a text label like “Updated: May 2025” to the title.

2025-05-12 17:02:38 UTC

@npub1rcn…dw4h Did you wanna regroup on the image tag or my storefront proposal? No worries if you’re still in RSS parser hell!

2025-05-08 18:06:18 UTC

- reply

sounds like my kinda guy 🫠

2025-05-02 20:54:07 UTC

- reply

yeah, not intuitive at all. But it could be just a hidden little QoL progressive enhancement that would otherwise fallback to duplicate "captions" next to a link preview.
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/114/440/219/106/141/539/original/2301b6c81d6f6740.png

2025-05-02 20:37:35 UTC

- reply

```
<podcast:funding url="...">Use this text as the heading</podcast:funding>
```

2025-05-02 20:34:05 UTC

- reply

Even without any modifications to the spec, I think it’d be cool if podcast apps added a tab to display all the funding tags provided in the feed.
Use identical node values as implicit groupings and use that text as headings. Then pull in the links’ own Open Graph titles and images for each link-block.

2025-04-17 15:00:28 UTC

- reply

It can be intermixed, cause z-order is global. The "host" element your shadow DOM is attached to needs to supersede the rest of the page and `position:relative` to set a new stacking context.
https://jsfiddle.net/gack8db6/2/

2025-04-13 19:24:20 UTC

- reply

the goal was basically to achieve parity with the feature available in Spotify and Amazon Music. (Ideally without running afoul of App Reviews’ in-apppurchasing guidelines.)
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/114/332/286/952/148/315/original/f79655a0ac631aa9.png
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/114/332/287/322/273/436/original/6052dd5705811a94.png

2025-04-13 19:15:49 UTC

- reply

are you thinking of my storefront proposal? https://github.com/Podcastindex-org/podcast-namespace/discussions/644

2025-04-07 20:33:22 UTC

- reply

bumping this in case you forgot. What kind of examples are you looking for?

2025-04-04 16:20:32 UTC

- reply

Happy to help however! Are you looking for mockups of usage in a listening app or building a sample admin UI (like https://update-frequency.vercel.app/)?

2025-03-28 20:19:15 UTC

After 3.5 years in Printer’s Row, it’s time for a new view 😍
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/114/241/906/429/807/384/original/94672456d7a1a9c7.jpeg

2025-03-26 17:22:59 UTC

- reply

You can assign a keyboard shortcut to open Raycast directly to any feature, so I’d really recommend using your existing muscle memory to give it a fair shot at replacing some of your existing apps.
The absolute quickest win would be reassigning macOSs emoji shortcut to their emoji picker even if you use nothing else.

2025-03-26 17:17:55 UTC

- reply

💯 I used to write my own Alfred Workflows and didn’t get the Raycast hype, but it won me over eventually with their built-in extension store. It’s just so easy to go from a thought like, “has someone made an extension that does ___?” to installed and completed. It’s genuinely easier than Googling for a single-purpose web app that does the same task.

2025-03-06 06:34:29 UTC

- reply

Fine by me! btw, feel free to draft a whole new tag proposal if you want. I’m not precious about getting credit or whatever.
I could imagine stripping the attributes down to href, purpose, and maybe type.

2025-02-28 20:07:14 UTC

- reply

March will be pretty hectic for me, but I’ll see if I can squeeze some time in for this.

2025-02-28 19:01:38 UTC

- reply

I generate a 1200×630 `og:image` for each show/episode. I pull the dominant color from the artwork to fill the space, but I’d love to progressively enhance this for shows willing to provide their own landscape image asset.
https://xoxo-media.sfo2.cdn.digitaloceanspaces.com/media_attachments/files/114/083/052/173/035/157/original/4357d5e74f6e119a.png

2025-02-28 18:45:53 UTC

- reply

I appreciate all the time you’ve put into this more than anyone. I take your feedback seriously. I barely have a dog in this race beyond Social Preview images for EpisodesFM.
If the complexity will kill it, it needs to be revised. IMO, no app will adopt any version of it without a good fallback UX for the vast majority of shows without it.

2025-02-28 18:28:47 UTC

- reply

I 100% agree with that. I really think of myself as listener first, more than anything, which requires that my ideas have a viable path towards significant adoption. I’m happy to rewrite my proposal a dozen times if it means we find something that listeners/hosts/apps will actually adopt.
The drum that I keep beating on is "well-written tags should provide marginal utility even without widespread adoption."

2025-02-28 18:12:02 UTC

- reply

The burden is on apps to incentivize hosts and podcasters to adopt new tags. I created StenoFM partly to incentivize more podcasters to support word-by-word JSON transcripts. Before I built Stenofm, I don’t think any app supported JSON transcripts. Until boostagram-in-chapters, most didn’t support the toc=false attribute.

2025-02-28 18:11:56 UTC

- reply

In contrast, I asked myself, “How might app devs improve the listener experience with images?” They have to design the default experience with the assumption of 0% tag adoption and progressively enhance it for the shows that put in the effort.

2025-02-28 18:11:41 UTC

- reply

It seems like your POV is, “podcasters should be certain the assets they provide will be displayed well in all the apps,” and the strategy to achieve that is to rally podcasters behind a small number of purposes. Then, focus on convincing apps to support those use cases. IMO, this strategy is doomed because it requires widespread adoption before the apps become interested.

2025-02-27 23:49:22 UTC

- reply

> I won’t be supporting anything but the very basics like “banner” at whatever the suggested aspect ratio is.
Good, you’d be using this proposal as intended. No one should overbuild for hypothetical use cases.

2025-02-27 23:14:27 UTC

- reply

Or maybe it looks more like `purpose="truefans-hero fountain-hero episodesfm-social podlink-social` with no aspect-ratio attribute.

2025-02-27 23:11:59 UTC

- reply

Yes, imagine app1 says, "We support landscape show artwork. We’ll look for `purpose="artwork" aspect-ratio="16/9"`. App2 says, "We support landscape social open graph images. We’ll look for `purpose="social" aspect-ratio="16/9"`.
A host could say, We don’t need two fields for that. Our users will just get a ‘Landscape Artwork’ field and we’ll put one image tag in the feed with `purpose="artwork social" aspect-ratio="16/9"`.

2025-02-27 21:38:52 UTC

- reply

Pretty much! Although, purposes are space separated, so maybe it should be more like "apple-channel-logo".

2025-02-27 19:42:09 UTC

- reply

yes. I looked through all of theirs when drafting my list of suggested purposes. (See the prior art column in my proposal)

2025-02-26 21:47:10 UTC

- reply

Yeah, I’d love to. I was just maintaining backwards-compatibility with the original spec.

2025-02-25 23:01:23 UTC

- reply

I 100% agree.
My intention was to avoid a multitude of media-related tags in the spec by creating the "ONE IMAGE TAG TO RULE THEM ALL", which essentially just gives apps/feeds the toolkit to define their own image standards without needing the namespace to "bless" each and every one.
I think my biggest failing here is not providing a sample podcaster-facing UI for hosts like I did for UpdateFrequency. https://update-frequency.vercel.app/.

2025-02-25 22:30:55 UTC

- reply

As I see it, app devs are in the business of designing the best experience for their listeners, and how they achieve that is up to them.
Maybe another dev would choose to take the "most similar" aspect ratio available and display it cropped. Or hell, adapt the whole UI to fit the provided assets.

2025-02-25 22:18:38 UTC

- reply

I’d display the image for the one that matches my documented aspect ratio, and treat the rest as if they hadn’t provided a hero image at all, which is the experience the vast majority of feeds will look like anyway.
And I wouldn’t even trust the one that gave the correct aspect ratio. I’d use `object-fit:cover;` or equivalent to force it into that size even if the provided asset happen to be wrong.

2025-02-25 21:58:25 UTC

- reply

If a second app wants to support that exact same purpose, they just copy app1’s implementation and can immediately support the existing feeds.
If App2 want to have looser restrictions, like allowing video files, but still use the same purpose token, then they just have to document their usage and requirements of that purpose. Hosts could add an additional file uploader labeled "Hero Video."
Nothing changes for App1 because they were only accepting image assets to begin with.

2025-02-25 21:58:20 UTC

- reply

As I was imagining it, an app would indicate they support a specific purpose, such as a hero image. They’re free to define the name of the purpose and specify any additional requirements regarding dimensions, aspect ratios, file formats, etc. As always, apps aren’t beholden to bend over backwards to support whatever’s thrown at them. Participating hosts could implement a "Hero image" UI with just a file uploader, no other user-facing inputs.

2025-02-25 16:39:36 UTC

- reply

Any tag proposal needs to answer the questions:
1. Who will be the first app to adopt this tag?
2. How easy is it to provide a fallback when this tag isn’t present?
3. If they’ve gone to the trouble of implementing the fallback, does supporting the new tag provide a meaningful improvement over the fallback?

2025-02-25 16:32:58 UTC

My stance has always been that well-written tags should provide marginal utility even without widespread adoption, and in fact, that’s their only chance of finding any traction in an open ecosystem.
That’s the underpinnings of progressive enhancement, which indie podcast apps have embraced. But the behemoths like Apple Podcasts have a higher bar for their UX. Instead of merely support the transcript tag as-is, they they built an sophisticated transcription pipeline that elegantly handles DAI.

2025-02-25 16:32:26 UTC

- reply

Thanks. I’m always happy to adapt to encourage wider adoption.
Regardless of the final tag(s), each use case for images will be it’s own chicken/egg challenge of adoption. My stance has always been that well-written tags should provide marginal utility even without widespread adoption, and in fact, that’s their only chance of finding any traction in an open ecosystem.

2025-02-25 15:49:12 UTC

- reply

Would you say Transistor shouldn’t claim to support Social Interact if the only platform they support is Bluesky? I expect there’s a range of opinions in this community.
I appreciate that Sovereign Feeds takes a more comprehensive approach to supporting tags. If you ever find yourself stuck, I’m happy to help with UX support.

2025-02-25 15:43:59 UTC

- reply

EpisodesFM generates landscape social preview images for every show/episode. I could choose to prioritize feed-provided social media images when present.
The bare minimum a host would need to participate would be an image upload field labeled "Social Preview Image" that appends an image with purpose="social" no need to handle aspect-ratios, srcset, type.

2025-02-25 15:43:50 UTC

- reply

I think I need to start providing sample UX implementations for my proposals because bc they’re written with the assumption that app/host devs will only implement the parts that serve their interests.
In my mind, each "use case" warrants its own UI, and doesn’t require some some complex ~image tag builder wizard~.