# Private feed addresses with path secrets

Research only, 13 October 2026. Recommend **(c), narrow known-host detection plus an explicit "Keep this feed's address private" action** in the planned Add podcast work. Do not infer privacy from an arbitrary long URL path.

PodNotes currently recognizes HTTP userinfo and selected auth query names. An unrecognized subscriber URL can therefore reach data.json, notes, and the feed cache. `T` below is a synthetic token placeholder. These are feed-address patterns, not a claim that every address under a listed host is private.

| Host | Published format or pattern | Evidence and current handling |
| --- | --- | --- |
| Supercast | `supercast.com/feeds/...`, also `.tech` and show subdomains | Supercast's contributor says all its feeds are individualized and supplies these patterns in [Podcast Index PR 2](https://github.com/Podcastindex-org/private-feed-blocklist/pull/2). Missed today. |
| Substack | Host matches `substack.com`, path contains `/private/` and ends in `.rss` | [Substack support](https://support.substack.com/hc/en-us/articles/4519588148244-How-do-I-listen-to-episodes-on-my-podcast-app) documents each subscriber's unique private RSS feed and where to copy it. The path pattern comes from the [Podcast Index blocklist](https://github.com/Podcastindex-org/private-feed-blocklist/blob/master/patterns.txt), not the support text. Exact segment layout is unconfirmed. Missed today. |
| Supporting Cast | `https://<network>.supportingcast.fm/content/T.rss` | The [official API schema](https://developers.supportingcast.fm/api/docs-v2-source) publishes this `UserFeed.url` shape as the user-specific feed URL. `.co` and `.cc` variants appear in [PR 3](https://github.com/Podcastindex-org/private-feed-blocklist/pull/3), without current official confirmation. Missed today. |
| Memberful | `memberfulcontent.com/...auth=T` | [Memberful support](https://memberful.com/docs/member-interface/subscription/access-member-benefits) directs members to their account's Podcasts tab at `/account/feeds`. The feed pattern is blocklist evidence only. Its `auth` query is already detected; the evidence does not support calling Memberful a path-only miss. |
| Transistor | `https://subscribers.transistor.fm/T` | The [official API reference](https://developers.transistor.fm/) documents `feed_url` as the subscriber's unique RSS feed and gives this format. Missed today. |
| Pinecast | `https://pinecast.com/feed/<show>/sub/<subscriber-id>` | The [official support article](https://help.pinecast.com/article/61-subscribing-to-a-private-rss-feed) gives a complete synthetic example. Missed today. |
| Patreon | `https://www.patreon.com/rss/<show>?auth=T` | [Pocket Casts support](https://support.pocketcasts.com/knowledge-base/private-or-members-only-feeds/) documents the template. Already detected. |
| Captivate | `private.captivate.fm/...` | [Captivate support](https://help.captivate.fm/en/article/private-podcasts-faqs-13p02ng/) documents per-subscriber links. Host pattern is from the blocklist. Missed today. |
| RedCircle, Acast Access | `feeds.redcircle.com/<id>/pf/...` or `api.podcache.net/shows/<id>/pf/...`; `access.acast.com/<show>/<non-default>...` | Publisher contributions [PR 5](https://github.com/Podcastindex-org/private-feed-blocklist/pull/5) and [PR 7](https://github.com/Podcastindex-org/private-feed-blocklist/pull/7). Missed today. |
| Castos, NPR | `<sub>.castos.com/feed?uuid=T`; `feeds.npr.org/...uid=T` | Castos [PR 4](https://github.com/Podcastindex-org/private-feed-blocklist/pull/4) and blocklist. These are query-name misses, not path secrets. Scope any added query rules to those hosts. |

The host docs establish the private-feed behavior; they do not all publish URL grammars. The blocklist's last change was in 2024. Treat its third-party-only patterns as candidates to verify, not current provider contracts. No real subscriber credential was tested. Buzzsprout's [support page](https://www.buzzsprout.com/help/186-personal-rss) confirms personal RSS feeds but did not establish a format.

The options are:

- **(a) Known-host patterns.** Recognize verified host and path combinations at the existing privacy boundary. Most users need make no privacy decision. Unlisted hosts, custom domains, and format changes still leak. False positives unnecessarily require address setup on every device, so exact hostname boundaries and public-feed counterexamples matter.
- **(b) Explicit privacy action.** Covers an unfamiliar host without guessing. The action must exist before the first save and apply consistently to imports. Users must know that their address grants access, and those who overlook the action remain exposed.
- **(c) Both.** Automatically protect verified cases and let users protect any other feed. This adds a small product decision and an explicit privacy state to maintain, but avoids presenting a finite host list as complete protection.
- **(d) Leave it.** Keeps seamless URL sync and no extra setup, but copies subscriber access into synced, backed-up, or committed data.json and potentially shared notes. Rotation cannot erase those copies.

A protected feed needs one address paste per device, and another if the provider rotates it. Substack and Memberful document where subscribers retrieve it. This cost can be substantial for a large private library; it is still preferable to silently distributing access credentials. The explicit action gives unsupported hosts the same protection without waiting for another plugin update. Start automatic detection with publisher-documented or publisher-submitted rules and verify ambiguous patterns before adding them. Enclosure URLs need a separate playback-preserving design; this proposal does not authorize it. A bounded review of these hosts **did not establish reuse of the durable feed token in enclosures**. Supercast documents [subscriber-specific media URLs](https://supercast.readme.io/reference/listepisodes) and a [secret feed key](https://supercast.readme.io/reference/getsubscriber), but no relationship proving equality. This leaves token reuse open, not disproved. Re-resolving media from the feed on restore remains a useful separate unit for both credential persistence and expired signed URLs.