├── .gitignore
├── .vs
├── ProjectSettings.json
├── VSWorkspaceState.json
├── podcast-namespace
│ └── v16
│ │ └── .suo
└── slnx.sqlite
├── COPYING.txt
├── README.md
├── apgtrss1.png
├── apgtrss2.png
├── categories.json
├── chapters
├── example.json
├── exampleComplex.json
└── jsonChapters.md
├── contributors.txt
├── docs
├── 1.0.md
├── chatprotocols.txt
├── element-support.md
├── other-recommendations.md
├── schema
│ ├── attribute-hover.png
│ ├── first-child-tag.png
│ ├── podcast-example.xml
│ ├── podcast-schema.md
│ ├── podcast-wrapper.xsd
│ ├── podcast.xsd
│ ├── start-tag-completion.png
│ ├── strip-annotation.xslt
│ ├── tag-hover.png
│ └── tag-inserted.png
└── tags
│ ├── alternateEnclosure.md
│ ├── block.md
│ ├── chapters.md
│ ├── chat.md
│ ├── contentLink.md
│ ├── episode.md
│ ├── funding.md
│ ├── guid.md
│ ├── images.md
│ ├── integrity.md
│ ├── license.md
│ ├── liveItem.md
│ ├── location.md
│ ├── locked.md
│ ├── medium.md
│ ├── person.md
│ ├── podping.md
│ ├── podroll.md
│ ├── publisher.md
│ ├── remoteItem.md
│ ├── season.md
│ ├── socialInteract.md
│ ├── soundbite.md
│ ├── source.md
│ ├── trailer.md
│ ├── transcript.md
│ ├── txt.md
│ ├── updateFrequency.md
│ ├── value.md
│ ├── valueRecipient.md
│ └── valueTimeSplit.md
├── example.xml
├── existing-namespaces.txt
├── images
├── pc20badgered.svg
└── podcastindex-namespace-final.svg
├── itunes_reference.md
├── letters
└── letter-to-apple.md
├── license
├── license.md
├── licenses.json
├── licenseslugs.txt
└── v4v-4.0.md
├── location
└── location.md
├── podcast.xsd
├── podcasting2.0.md
├── proposal-docs
├── API
│ └── Chapters.md
├── alternateEnclosure
│ └── alternateEnclosure.md
├── bonusItem
│ └── bonusItem.md
├── chat
│ ├── chat.md
│ └── chatprotocols.txt
├── hive-account-name
│ └── hive-account-name.md
├── license
│ └── license.md
├── opensubscribe
│ └── opensubscribe.md
├── podping
│ └── podping.md
├── recommendations
│ └── recommendations.md
├── sharedsoundbites.md
├── social
│ ├── platforms.md
│ └── social.md
├── updateFrequency
│ └── updateFrequency.md
├── value-webmonetization
│ └── value-webmonetization.md
└── verify
│ └── verify.md
├── publishers
└── publishers.md
├── serviceslugs.txt
├── socialprotocols.txt
├── taxonomy-de.json
├── taxonomy-en.json
├── taxonomy-fr.json
├── taxonomy.json
├── transcripts
├── example.html
├── example.json
├── example.srt
├── example.vtt
└── transcripts.md
└── value
├── blip-0010.md
├── lnaddress.md
├── value.md
└── valueslugs.txt
/.gitignore:
--------------------------------------------------------------------------------
1 | /.vs/
2 | .vscode/settings.json
3 |
--------------------------------------------------------------------------------
/.vs/ProjectSettings.json:
--------------------------------------------------------------------------------
1 | {
2 | "CurrentProjectSetting": null
3 | }
--------------------------------------------------------------------------------
/.vs/VSWorkspaceState.json:
--------------------------------------------------------------------------------
1 | {
2 | "ExpandedNodes": [
3 | "",
4 | "\\proposal-docs"
5 | ],
6 | "SelectedNode": "\\proposal-docs\\recommendations",
7 | "PreviewInSolutionExplorer": false
8 | }
--------------------------------------------------------------------------------
/.vs/podcast-namespace/v16/.suo:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Podcastindex-org/podcast-namespace/91e3baa0f9a356e8ac58df2c63cbe889bb5011da/.vs/podcast-namespace/v16/.suo
--------------------------------------------------------------------------------
/.vs/slnx.sqlite:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Podcastindex-org/podcast-namespace/91e3baa0f9a356e8ac58df2c63cbe889bb5011da/.vs/slnx.sqlite
--------------------------------------------------------------------------------
/COPYING.txt:
--------------------------------------------------------------------------------
1 | Creative Commons Legal Code
2 |
3 | CC0 1.0 Universal
4 |
5 | CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
6 | LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
7 | ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
8 | INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
9 | REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
10 | PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
11 | THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
12 | HEREUNDER.
13 |
14 | Statement of Purpose
15 |
16 | The laws of most jurisdictions throughout the world automatically confer
17 | exclusive Copyright and Related Rights (defined below) upon the creator
18 | and subsequent owner(s) (each and all, an "owner") of an original work of
19 | authorship and/or a database (each, a "Work").
20 |
21 | Certain owners wish to permanently relinquish those rights to a Work for
22 | the purpose of contributing to a commons of creative, cultural and
23 | scientific works ("Commons") that the public can reliably and without fear
24 | of later claims of infringement build upon, modify, incorporate in other
25 | works, reuse and redistribute as freely as possible in any form whatsoever
26 | and for any purposes, including without limitation commercial purposes.
27 | These owners may contribute to the Commons to promote the ideal of a free
28 | culture and the further production of creative, cultural and scientific
29 | works, or to gain reputation or greater distribution for their Work in
30 | part through the use and efforts of others.
31 |
32 | For these and/or other purposes and motivations, and without any
33 | expectation of additional consideration or compensation, the person
34 | associating CC0 with a Work (the "Affirmer"), to the extent that he or she
35 | is an owner of Copyright and Related Rights in the Work, voluntarily
36 | elects to apply CC0 to the Work and publicly distribute the Work under its
37 | terms, with knowledge of his or her Copyright and Related Rights in the
38 | Work and the meaning and intended legal effect of CC0 on those rights.
39 |
40 | 1. Copyright and Related Rights. A Work made available under CC0 may be
41 | protected by copyright and related or neighboring rights ("Copyright and
42 | Related Rights"). Copyright and Related Rights include, but are not
43 | limited to, the following:
44 |
45 | i. the right to reproduce, adapt, distribute, perform, display,
46 | communicate, and translate a Work;
47 | ii. moral rights retained by the original author(s) and/or performer(s);
48 | iii. publicity and privacy rights pertaining to a person's image or
49 | likeness depicted in a Work;
50 | iv. rights protecting against unfair competition in regards to a Work,
51 | subject to the limitations in paragraph 4(a), below;
52 | v. rights protecting the extraction, dissemination, use and reuse of data
53 | in a Work;
54 | vi. database rights (such as those arising under Directive 96/9/EC of the
55 | European Parliament and of the Council of 11 March 1996 on the legal
56 | protection of databases, and under any national implementation
57 | thereof, including any amended or successor version of such
58 | directive); and
59 | vii. other similar, equivalent or corresponding rights throughout the
60 | world based on applicable law or treaty, and any national
61 | implementations thereof.
62 |
63 | 2. Waiver. To the greatest extent permitted by, but not in contravention
64 | of, applicable law, Affirmer hereby overtly, fully, permanently,
65 | irrevocably and unconditionally waives, abandons, and surrenders all of
66 | Affirmer's Copyright and Related Rights and associated claims and causes
67 | of action, whether now known or unknown (including existing as well as
68 | future claims and causes of action), in the Work (i) in all territories
69 | worldwide, (ii) for the maximum duration provided by applicable law or
70 | treaty (including future time extensions), (iii) in any current or future
71 | medium and for any number of copies, and (iv) for any purpose whatsoever,
72 | including without limitation commercial, advertising or promotional
73 | purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
74 | member of the public at large and to the detriment of Affirmer's heirs and
75 | successors, fully intending that such Waiver shall not be subject to
76 | revocation, rescission, cancellation, termination, or any other legal or
77 | equitable action to disrupt the quiet enjoyment of the Work by the public
78 | as contemplated by Affirmer's express Statement of Purpose.
79 |
80 | 3. Public License Fallback. Should any part of the Waiver for any reason
81 | be judged legally invalid or ineffective under applicable law, then the
82 | Waiver shall be preserved to the maximum extent permitted taking into
83 | account Affirmer's express Statement of Purpose. In addition, to the
84 | extent the Waiver is so judged Affirmer hereby grants to each affected
85 | person a royalty-free, non transferable, non sublicensable, non exclusive,
86 | irrevocable and unconditional license to exercise Affirmer's Copyright and
87 | Related Rights in the Work (i) in all territories worldwide, (ii) for the
88 | maximum duration provided by applicable law or treaty (including future
89 | time extensions), (iii) in any current or future medium and for any number
90 | of copies, and (iv) for any purpose whatsoever, including without
91 | limitation commercial, advertising or promotional purposes (the
92 | "License"). The License shall be deemed effective as of the date CC0 was
93 | applied by Affirmer to the Work. Should any part of the License for any
94 | reason be judged legally invalid or ineffective under applicable law, such
95 | partial invalidity or ineffectiveness shall not invalidate the remainder
96 | of the License, and in such case Affirmer hereby affirms that he or she
97 | will not (i) exercise any of his or her remaining Copyright and Related
98 | Rights in the Work or (ii) assert any associated claims and causes of
99 | action with respect to the Work, in either case contrary to Affirmer's
100 | express Statement of Purpose.
101 |
102 | 4. Limitations and Disclaimers.
103 |
104 | a. No trademark or patent rights held by Affirmer are waived, abandoned,
105 | surrendered, licensed or otherwise affected by this document.
106 | b. Affirmer offers the Work as-is and makes no representations or
107 | warranties of any kind concerning the Work, express, implied,
108 | statutory or otherwise, including without limitation warranties of
109 | title, merchantability, fitness for a particular purpose, non
110 | infringement, or the absence of latent or other defects, accuracy, or
111 | the present or absence of errors, whether or not discoverable, all to
112 | the greatest extent permissible under applicable law.
113 | c. Affirmer disclaims responsibility for clearing rights of other persons
114 | that may apply to the Work or any use thereof, including without
115 | limitation any person's Copyright and Related Rights in the Work.
116 | Further, Affirmer disclaims responsibility for obtaining any necessary
117 | consents, permissions or other rights required for any use of the
118 | Work.
119 | d. Affirmer understands and acknowledges that Creative Commons is not a
120 | party to this document and has no duty or obligation with respect to
121 | this CC0 or use of the Work.
122 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # The "podcast" Namespace
2 |
3 | A wholistic rss namespace for podcasting that is meant to synthesize the fragmented world of podcast namespaces. The
4 | broad goal is to create a single, compact, efficient namespace that is easily extensible, community
5 | controlled/authored and addresses the needs of the independent podcast industry now and in the future. Our hope is
6 | that this namespace will become the framework that the independent podcast community needs to deliver new
7 | functionality to apps and aggregators.
8 |
9 |
10 | Our guiding principles for development of this namespace are the
11 | "[Rules for Standards Makers](http://scripting.com/2017/05/09/rulesForStandardsmakers.html)" by Dave Winer. Please
12 | read it before contributing if you aren't familiar with it.
13 |
14 | The podcast namespace is part of the larger "Podcasting 2.0" project which exists to bring control of podcasting's
15 | protocols back into the hands of the open podcasting community. A good overview can be found here:
16 | [Podcasting 2.0](podcasting2.0.md)
17 |
18 | * [Official XMLNS Definition](docs/1.0.md) the official definition of all formalized tags.
19 | * List of platforms and apps that currently implement some or all of these
20 | tags: [Supporting Platforms and Apps](docs/element-support.md).
21 | * Example Feed: There is an example feed [example.xml](example.xml) in this repository showing the podcastindex
22 | namespace side by side with the Apple itunes namespace. * [Other recommendations](docs/other-recommendations.md)
23 | when creating RSS podcast feeds.
24 |
25 |
26 |
27 |
28 |
29 | ## Current Roadmap
30 |
31 | **Phase 1** - [Closed] Comment period closed on `11/15/2020` and [5 tags](#phase-1-closed-on-111520) were
32 | **formalized**.
33 |
34 | **Phase 2** - [Closed] Comment period closed on `1/31/2021` and [4 tags](#phase-2-closed-on-13121) were **formalized**.
35 |
36 | **Phase 3** - [Closed] Comment period closed on `6/1/2021` and [5 tags](#phase-3-closed-on-6121) were **formalized**.
37 |
38 | **Phase 4** - [Closed] Comment period closed on `12/1/2021` and [3 tags](#phase-4-closed-on-1212021) were
39 | **formalized**.
40 |
41 | **Phase 5** - [Closed] Comment period closed on `7/15/2022` and [2 tags](#phase-5-closed-as-of-7152022) were
42 | **formalized**.
43 |
44 | **Phase 6** - [Closed] Comment period closed on `6/1/2023` and [6 tags](#phase-6-closed-as-of-612023) were
45 | **formalized**.
46 |
47 | **Phase 7** - [Closed] Comment period closed on `7/1/2023` and
48 | [the following](https://github.com/Podcastindex-org/podcast-namespace/discussions/554) adoptions are being
49 | considered for formalization. Two tags
50 | [have already been](https://github.com/Podcastindex-org/podcast-namespace/discussions/categories/announcements-changes-made)
51 | formalized.
52 |
53 |
54 |
55 |
56 | ## Legend
57 |
58 | **Formalized** - This tag is frozen and listed in the XMLNS document. Any future changes to it's definition must
59 | maintain backwards compatibility.
60 |
61 | **Finalized** - The tag is structurally stable and implementation testing should be considered safe. Any breaking
62 | changes will be widely communicated.
63 |
64 | **Open** - The tag/phase is open for discussion and collaboration.
65 |
66 | **Required** - This tag or attribute must be present.
67 |
68 | **Optional** - This tag or attribute may be left out.
69 |
70 | **Recommended** - This tag or attribute is technically optional, but is strongly recommended to be present for the
71 | tag to function as fully intended.
72 |
73 |
74 |
75 |
76 |
77 | ## Tag Adoption Process
78 |
79 | To be adopted as an official part of the namespace, there must be consensus around a tag's usefulness and either
80 | commitment to adoption by at least 1 host and 1 app, or a recognition that the tag is already being used in the wild.
81 |
82 | It is ALWAYS ok to delay a tag to a future Phase if there is any concern about it. That is to be expected and
83 | encouraged.
84 |
85 | When a Phase comes to a close, there will be a full review of any tags currently open for comment and questions will
86 | be asked to gather consensus before final adoption. No tags will be adopted by fiat, or if there are unresolved
87 | questions. They will just be moved to the next Phase for further comment and refinement.
88 |
89 | Tags that are proposals or rough ideas should be expected to have syntax problems or typos. Those should be refined
90 | away as they are worked on. If they are not, that is a good idea that the tag in question isn't being seen as
91 | useful and should be considered for dropping.
92 |
93 | We are not a "standards body". It is a community driven project where all stake holders are encouraged to
94 | participate, so that many voices are heard. This is an open-source project to be built fully in the open.
95 | Discussions also take place on [podcastindex.social](https://podcastindex.social) where anyone is free to register
96 | and participate.
97 |
98 |
99 |
100 |
101 |
102 | ### Goal #1 - Eliminate Redundancy
103 |
104 | There is significant overlap amongst the many existing podcast namespaces. Each platform and publisher has created
105 | their own namespace to give their respective system and audience the metadata they need in the way they want it
106 | delivered.
107 |
108 |
109 | ### Goal #2 - Keep "required" tags and attributes minimal
110 |
111 | The only required tags should be those that solve an overwhelming need in the industry. Requiring tags is a
112 | roadblock to adoption and should be avoided. Attributes should also only be required when they are key to the
113 | functionality of the tag.
114 |
115 |
116 | ### Goal #3 - Keep Exisiting Conventions
117 |
118 | Reinventing the wheel helps nobody. When at all possible, existing conventions should be maintained. For example,
119 | it would make sense to turn **\** into a unary element, where it's existence is taken as a "yes"
120 | and it's absence as a "no". But, that has never been the standard. And, given as how this namespace will probably
121 | sit alongside at least one other namespace, it makes sense to keep existing conventions in place.
122 |
123 |
124 | ### Goal #4 - Be General... to a point
125 |
126 | There is no way to address every possible metadata point that each platform would want. That is not the aim.
127 | Instead we focus on defining the elements that would be useful to the broadest set of apps, publishers, platforms
128 | and aggregators. Individual parties can keep their respective supplemental namespaces small and targeted as an
129 | adjunct to this larger namespace. But, we don't want to be so general that the spec becomes overly complicated. A
130 | beautiful, "perfect" spec is not important. Solving real problems is.
131 |
132 |
133 |
134 |
135 |
136 | ## Copying information
137 |
138 | The "podcast" namespace is [dedicated to the public domain using CC0 v1.0](COPYING.txt) so as to remove all barriers
139 | to adoption, development and contribution.
140 |
141 |
142 |
143 |
144 |
145 | ## Element List
146 |
147 | ### Phase 1 (Closed on 11/15/20)
148 |
149 |
150 |
151 | The following tags have been formally adopted into the namespace. They are fully documented in the XMLNS document
152 | located [here](docs/1.0.md). Please see that file for full implementation details.
153 |
154 | - **\**
155 | - **\**
156 | - **\**
157 | - **\**
158 | - **\**
159 |
160 |
161 |
162 | ### Phase 2 (Closed on 1/31/21)
163 |
164 |
165 |
166 | The following tags have been formally adopted into the namespace. They are fully documented in the XMLNS document
167 | located [here](docs/1.0.md). Please see that file for full implementation details.
168 |
169 | - **\**
170 | - **\**
171 | - **\**
172 | - **\**
173 |
174 |
175 |
176 |
177 | ### Phase 3 (Closed on 6/1/21)
178 |
179 |
180 |
181 | The following tags have been formally adopted into the namespace. They are fully documented in the XMLNS document
182 | located [here](docs/1.0.md). Please see that file for full implementation details.
183 |
184 | - **\**
185 | - **\**
186 | - **\**
187 | - **\**
188 | - **\**
189 | - **\**
190 |
191 |
192 |
193 |
194 | ## Phase 4 (Closed on 12/1/2021)
195 |
196 |
197 |
198 | The following tags have been formally adopted into the namespace. They are fully documented in the XMLNS document
199 | located [here](docs/1.0.md). Please see that file for full implementation details.
200 |
201 | - **\**
202 | - **\**
203 | - **\**
204 |
205 |
206 |
207 |
208 | ## Phase 5 (Closed as of 7/15/2022)
209 |
210 |
211 |
212 | The following tags have been formally adopted into the namespace. They are fully documented in the XMLNS document
213 | located [here](docs/1.0.md). Please see that file for full implementation details.
214 |
215 | - **\**
216 | - **\**
217 |
218 |
219 |
220 | ## Phase 6 (Closed as of 6/1/2023)
221 |
222 |
223 |
224 | The following tags have been formally adopted into the namespace. They are fully documented in the XMLNS document
225 | located [here](docs/1.0.md). Please see that file for full implementation details.
226 |
227 | - **\**
228 | - **\**
229 | - **\**
230 | - **\**
231 | - **\**
232 | - **\**
233 |
234 |
235 |
236 | ## Phase 7 (Closed as of 6/1/2024)
237 |
238 |
239 |
240 | The following tags have been formally adopted into the namespace. They are fully documented in the XMLNS document
241 | located [here](docs/1.0.md). Please see that file for full implementation details.
242 |
243 | - **\**
244 | - **\**
245 |
246 |
247 |
248 |
249 | ## Other Proposals
250 |
251 | A list of the current and past proposals can be found in the Discussions
252 | section [here](https://github.com/Podcastindex-org/podcast-namespace/discussions).
253 |
254 |
5 |
6 | This is the initial spec for a json chapters format that can be referenced in an RSS feed using the `` tag of
7 | the "podcast" namespace. This file can reside on any publicly accessible url. See the podcast namespace documentation for
8 | details on the format of the tag.
9 |
10 | This type of file should be served with a Content-type of 'application/json+chapters'. Chapter order is assumed to be
11 | in ascending order based on the `startTime`.
12 |
13 |
14 |
15 | ## "Chapters" Object
16 |
17 | The chapters object is a simple JSON object with only 2 required properties:
18 |
19 | - `version` (required - string) The version number of the format being used
20 | - `chapters` (required - array) An array of chapter objects defined below
21 |
22 | #### Optional Attributes:
23 |
24 | - `author` (optional - string) The name of the author of this podcast episode.
25 | - `title` (optional - string) The title of this podcast episode.
26 | - `podcastName` (optional - string) The name of the podcast this episode belongs to.
27 | - `description` (optional - string) A description of this episode.
28 | - `fileName` (optional - string) The name of the audio file these chapters apply to.
29 | - `waypoints` (optional - boolean) If this property is present, the locations in a chapter object should be displayed with a route between locations.
30 |
31 |
32 |
33 | ## The "Chapter" Object
34 |
35 | The "chapter" object takes this basic form:
36 |
37 | ```json
38 | {
39 | "startTime": 94,
40 | "title": "Donation Segment"
41 | }
42 | ```
43 |
44 | There is only one required attribute:
45 |
46 | - `startTime` (required - float) The starting time of the chapter, expressed in seconds with float precision for fractions of a second.
47 |
48 |
49 |
50 | #### Optional Attributes:
51 |
52 | - `title` (optional - string) The title of this chapter.
53 | - `img` (optional - string) The url of an image to use as chapter art.
54 | - `url` (optional - string) The url of a web page or supporting document that's related to the topic of this chapter.
55 | - `toc` (optional - boolean) If this property is present and set to false, this chapter should not display visibly to the user in either the table of contents or as a jump-to point in the user interface. It should be considered a "silent" chapter marker for the purpose of meta-data only. If this property is set to `true` or not present at all, this should be considered a normal chapter for display to the user. The name "toc" is short for "table of contents".
56 | - `endTime` (optional - float) The end time of the chapter, expressed in seconds with float precision for fractions of a second.
57 | - `location` (optional - object) This object defines an optional location that is tied to this chapter. It follows the structure of the [location](https://github.com/Podcastindex-org/podcast-namespace/blob/main/location/location.md) tag in the XML namespace.
58 |
59 |
60 |
61 | ## The Location Object:
62 |
63 | The "location" object takes this basic form:
64 |
65 | ```json
66 | {
67 | "name": "Eiffel Tower, Paris",
68 | "geo": "geo:48.858093,2.294694"
69 | }
70 | ```
71 |
72 | It is intended to provide for rich location-based experiences tied to a point of time within a podcast episode, or other feed based media. For example, a "walking tour" may include latitude and longitude waypoints along side the image within chapters markers as someone listens to the tour podcast. This
73 | would allow apps to show a map with markers within the UI as the tour progresses. Or, perhaps a "History of the Middle East" podcast might expose a map to highlight where certain landmarks are when being discussed.
74 |
75 | There are two required attributes:
76 |
77 | - `name` (required - string) A human readable place name.
78 | - `geo` (required - string) A simple latitude,longitude given in geoURI format, conformant to [RFC 5870](https://tools.ietf.org/html/rfc5870).
79 |
80 | #### Optional Attributes:
81 |
82 | - `osm` (optional - string) An OpenStreetMaps query string. Please see the [location](https://github.com/Podcastindex-org/podcast-namespace/blob/main/location/location.md) XML tag specification for full details.
83 |
84 |
85 |
86 | ## Basic example
87 |
88 | Here is what a very basic chapters file may look like:
89 |
90 | ```json
91 | {
92 | "version": "1.2.0",
93 | "chapters":
94 | [
95 | {
96 | "startTime": 0,
97 | "title": "Intro"
98 | },
99 | {
100 | "startTime": 168,
101 | "title": "Hearing Aids",
102 | "img": "https://example.com/images/hearing_aids.jpg"
103 | },
104 | {
105 | "startTime": 260,
106 | "title": "Progress Report"
107 | },
108 | {
109 | "startTime": 410,
110 | "title": "Namespace",
111 | "img": "https://example.com/images/namepsace_example.jpg",
112 | "url": "https://github.com/Podcastindex-org/podcast-namespace"
113 | },
114 | {
115 | "startTime": 3990,
116 | "title": "Just Break Up",
117 | "img": "https://example.com/images/justbreakuppod.png"
118 | },
119 | {
120 | "startTime": 5510,
121 | "title": "The Big Players"
122 | },
123 | {
124 | "startTime": 5854,
125 | "title": "Spread the Word"
126 | },
127 | {
128 | "startTime": 6089,
129 | "title": "Outro"
130 | }
131 | ]
132 | }
133 | ```
134 |
135 | In this simple form, the chapter objects are treated as sequential just based on their index as a function of being
136 | ordered in ascending fashion based on their `startTime`. In a very simple example such as this nothing is present except the `startTime`,
137 | `title`, and a few bits of optional meta-data.
138 |
139 |
140 |
141 | ## More complex example
142 |
143 | In this more robust example, we can bring in more meta-data about the podcast episode, and provide a way for this file to exist more easily in a web
144 | context for something like an embedded HTML5 player on a website. Also there is an example of a "silent" chapter that has no presence in the visible
145 | chapter list, but allows for different artwork to be shown:
146 |
147 | ```json
148 | {
149 | "version": "1.2.0",
150 | "author": "John Doe",
151 | "title": "Episode 7 - Making Progress",
152 | "podcastName": "John's Awesome Podcast",
153 | "chapters":
154 | [
155 | {
156 | "startTime": 0,
157 | "title": "Intro"
158 | },
159 | {
160 | "startTime": 168,
161 | "title": "Hearing Aids"
162 | },
163 | {
164 | "startTime": 260,
165 | "title": "Progress Report"
166 | },
167 | {
168 | "startTime": 410,
169 | "title": "Namespace",
170 | "img": "https://example.com/images/namepsace_example.jpg",
171 | "url": "https://github.com/Podcastindex-org/podcast-namespace"
172 | },
173 | {
174 | "startTime": 3990,
175 | "title": "Just Break Up",
176 | "img": "https://example.com/images/justbreakuppod.png",
177 | "url": "https://twitter.com/justbreakuppod"
178 | },
179 | {
180 | "startTime": 4826,
181 | "img": "https://example.com/images/parisfrance.jpg",
182 | "toc": false,
183 | "location": {
184 | "name": "Eiffel Tower, Paris",
185 | "geo": "geo:42.3417649,-70.9661596"
186 | }
187 | },
188 | {
189 | "startTime": 5510,
190 | "title": "The Big Players"
191 | },
192 | {
193 | "startTime": 5854,
194 | "title": "Spread the Word"
195 | },
196 | {
197 | "startTime": 6089,
198 | "title": "Outro"
199 | }
200 | ]
201 | }
202 | ```
203 |
204 |
205 |
206 | ## Note about privacy
207 |
208 | Clearly, when pulling in web based data there is the chance that this functionality could be used for tracking. As a safeguard against that, apps
209 | using chapters are encouraged to prompt the user to acknowledge whether they trust the podcast in question before displaying the content. Trusted
210 | podcasts can then be remembered for the future.
211 |
--------------------------------------------------------------------------------
/contributors.txt:
--------------------------------------------------------------------------------
1 | Tom Rossi
2 | James Cridland
3 | Guilherme Dellagustin
4 | Kevin Finn
5 | Dave Jones
6 | Daniel J. Lewis
7 | Andreas Hubel
8 | Christopher Isene
9 | Todd Cochrane
10 | Adam Curry
11 | @PhoneBoy
12 | Ben Slinger
13 | Martin Mouritzen
14 | Andy Beard
15 | Andy Valencia
16 | Matt Basta
17 | Mitch Downey
18 | @Muppet1856
19 | Douglas Kastle
20 | Andy Lehman
21 | Daniel Siebiesiuk
22 | Jon Buda
23 | Justin Jackson
24 | Tyler Lacy
25 | @brianoflondon
26 | Angelo at Blubrry
27 | Stacey Goers
28 | Stuart Moore
29 | @PofMagicfingers
30 | @Bigaston
31 | Alecks Gates
32 | Dave Keeshan
33 | Steven Bell
34 | @dergigi
35 | CTHTC
36 | @kenCode
37 | @Agorise
38 | @Dwev
39 | ... add your name as you contribute!
40 |
--------------------------------------------------------------------------------
/docs/1.0.md:
--------------------------------------------------------------------------------
1 | # RSS Namespace Extension for Podcasting (Tag Specification)
2 |
3 | A wholistic RSS namespace for podcasting that is meant to synthesize the fragmented world of podcast namespaces. As
4 | elements are canonized, they will be added to this document so developers can begin implementation. The
5 | specifications below are considered locked and the team will prioritize backward compatibility. We are operating
6 | under the [Rules for Standards-Makers](http://scripting.com/2017/05/09/rulesForStandardsmakers.html).
7 |
8 | The namespace for this extension is `https://podcastindex.org/namespace/1.0`. Clients which recognize this namespace
9 | must also recognize `https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md` as identical. The
10 | suggested tag prefix for use in XML is `podcast`, but clients should support alternate prefixes for this namespace.
11 | If your application generates RSS feeds and you implement one or more elements below, you will need to link this
12 | document in your XML:
13 |
14 | ```xml
15 |
16 | ```
17 |
18 | ## Podcast Tags
19 |
20 | Each tag below exists in the podcast namespace within the specified parent. All attributes are required unless
21 | explicitly specified as optional. Anywhere the url of a hyper-text based resource is specified, it must be given as
22 | `https:` and not `http:`.
23 |
24 |
25 | ## Table of Contents
26 |
27 | - [Transcript](tags/transcript.md)
28 | - [Locked](tags/locked.md)
29 | - [Funding](tags/funding.md)
30 | - [Chapters](tags/chapters.md)
31 | - [Soundbite](tags/soundbite.md)
32 | - [Person](tags/person.md)
33 | - [Location](tags/location.md)
34 | - [Season](tags/season.md)
35 | - [Episode](tags/episode.md)
36 | - [Trailer](tags/trailer.md)
37 | - [License](tags/license.md)
38 | - [Alternate Enclosure](tags/alternateEnclosure.md)
39 | - [Source](tags/source.md)
40 | - [Integrity](tags/integrity.md)
41 | - [Guid](tags/guid.md)
42 | - [Value](tags/value.md)
43 | - [Value Recipient](tags/valueRecipient.md)
44 | - [Medium](tags/medium.md)
45 | - [Images](tags/images.md)
46 | - [Live Item](tags/liveItem.md)
47 | - [Content Link](tags/contentLink.md)
48 | - [Social Interact](tags/socialInteract.md)
49 | - [Block](tags/block.md)
50 | - [Txt](tags/txt.md)
51 | - [Remote Item](tags/remoteItem.md)
52 | - [Podroll](tags/podroll.md)
53 | - [Update Frequency](tags/updateFrequency.md)
54 | - [Podping](tags/podping.md)
55 | - [Value Time Split](tags/valueTimeSplit.md)
56 | - [Chat](tags/chat.md)
57 | - [Publisher](tags/publisher.md)
--------------------------------------------------------------------------------
/docs/chatprotocols.txt:
--------------------------------------------------------------------------------
1 | irc
2 | xmpp
3 | nostr
4 | matrix
--------------------------------------------------------------------------------
/docs/other-recommendations.md:
--------------------------------------------------------------------------------
1 | # Other Recommendations from the Creators of the RSS Namespace Extension for Podcasting
2 |
3 | While the wholistic RSS namespace for podcasting is meant to synthesize the fragmented world of podcast namespaces, there are some existing standards and defacto-standards we want do endorse:
4 |
5 | ## Episode GUID
6 |
7 | For all new episodes, we recommended to use
8 |
9 | * either a permanent URI, e.g. `https://example.com/ep0003`
10 | * or a [Universally unique identifier (UUID)](https://en.wikipedia.org/wiki/Universally_unique_identifier) e.g. `7c029615-a810-5214-9342-eee73f58435d`
11 |
12 | The GUID of an episode should never change, even if a new version of the episode is being published, otherwise this episode will be duplicated downstream.
13 |
14 |
15 | Consumers of podcast feeds should fall back to the enclosure URL or the namespaced UUIDv5 (SHA1 Hash with ns:URL) of the enclosure URL, if the value is not set – see https://github.com/Podcastindex-org/podcast-namespace/issues/186#issuecomment-932742468 for more details.
16 |
17 |
18 |
19 | #### Examples
20 |
21 | Only one entry per `` is valid:
22 | ```xml
23 | https://example.com/ep0003
24 | 7c029615-a810-5214-9342-eee73f58435d
25 | ```
26 | (`isPermaLink` is optional, its default value is true –)
27 |
28 |
29 |
30 |
31 | ## Episode Description and Summary
32 |
33 | If you use ``, it should be an actual summary of the episode, in one or two sentences, and not a copy of the description. Be aware that Apple dropped `` from [their spec](https://help.apple.com/itc/podcasts_connect/#/itcb54353390) but many other clients still support it.
34 |
35 | The [original RSS specification](https://cyber.harvard.edu/rss/rss.html#hrelementsOfLtitemgt) defined `description` as follows:
36 | > A channel may contain any number of ``s. An item may represent a "story" -- much like a story in a newspaper or magazine; if so its description is a synopsis of the story, and the link points to the full story. An item may also be complete in itself, if so, the description contains the text (entity-encoded HTML is allowed; see examples) …
37 |
38 | There also exists `` for dedicated HTML episode notes [[rssboard.org]](https://www.rssboard.org/rss-profile#namespace-elements-content-encoded), but more and more publishers switch to only having ``.
39 |
40 | When your description contains HTML, we recommend to wrap it into ``. See https://podnews.net/article/html-episode-notes-in-podcast-rss and https://podnews.net/article/how-podcast-show-notes-display for more information about supported HTML tags in different clients. Typical are `
30 |
31 | ## Step 1. Adopt the "podcast" Namespace
32 |
33 | To be a Podcasting 2.0 compliant podcast you need to first declare the "podcast"
34 | [namespace](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md) in your feed if you self-host your podcast. If you
35 | use a hosting company for your podcast, check [here](https://podcastindex.org/apps) for a list of hosts that now support the new namespace.
36 |
37 | The namespace gives you (and your listeners) access to many new features:
38 |
39 | - Transcripts: You can deliver a text transcript along with your episode to make your content more accessible to those with hearing challenges, or for those
40 | learning your language.
41 | - Funding: This points listeners back to a donation or membership page that they can click on to join or donate money to your show.
42 | - Chapters: MP3 files have had the ability to embed chapters for many years. But, now you can create a "chapters file" that gets delivered along with your
43 | episode to allow rich content like images, embedded web pages, titles and silent markers. This chapters file lives on the web, so it can be
44 | changed later after publishing without uploading a new audio file or changing your episode.
45 | - Soundbites: Specify short bits of your episode to serve as an intro or a teaser for your show.
46 | - Persons: You can give multiple bio's in each episode that have short "about" descriptions of the people on that episode (like hosts, guests, etc.). Did you
47 | interview someone cool? Point to their head shot image and link to their Wikipedia page or their blog. It makes searching for people within podcasts
48 | easy and enjoyable.
49 | - Location: Is your podcast about a specific place? Tag it's location right in the episode or podcast feed to let people know. It makes your show more
50 | discoverable on the web.
51 | - Named Seasons: Seasons have been around for a while, but now you can name them. This way you can avoid the hassle of trying to cram everything in your show title.
52 | - Trailers: Trailers can exist as a separate audio/video file, outside of an actual episode. They can be tied to specific seasons for promotional consistency.
53 | - License: Want to protect your work from derivative use, or the other way around? You can assign a specific license to the content of the entire podcast, or different
54 | licenses for each episode. You can use preexisting open source licenses or write one yourself.
55 | - Alternate Enclosures: It's now possible to deliver alternative versions of content in the same podcast feed. You can assign video versions of an audio podcast. Or,
56 | maybe a low (or high) bandwidth version of the main audio/video file. Or, perhaps you want to deliver a version of your content over another
57 | method like IPFS or WebTorrent.
58 |
59 |
60 |
61 |
62 | ## Step 2. Be Web App Friendly
63 |
64 | Next, you need to confirm that your feed does not have "mixed content", and that it supports CORS where necessary. Again, if you use a hosting company for your podcast
65 | just [make sure](https://podcastindex.org/apps) they are supporting Podcasting 2.0 features. If your host isn't on that list, send them a message and let them know you
66 | want these new features.
67 |
68 | If you self-host your podcast, take note of these two things...
69 |
70 | #### Mixed Content
71 |
72 | "Mixed content" is what happens when part of your podcast (like your feed) is served securely and other parts of it (like the images or the audio) are not. When this
73 | happens, web-based podcast players cannot play your content or see your images. Modern web browsers are very strict about security and "mixed content" is blocked by
74 | most of them. Make sure your entire podcast is served over HTTPS with a valid certificate.
75 |
76 | #### CORS
77 |
78 | Another problem that can hamper your content under certain circumstances (like embedded pages in chapters) is CORS. If you serve content along with your podcast that
79 | requires cross-origin access, please be sure to enable the correct CORS policies on the domain the content is served from. You can find details
80 | [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS).
81 |
82 | Web-based podcast apps, PWA's (Progressive Web Apps) and Browser Extension based apps are critical to Podcasting 2.0, so the above changes are very important.
83 |
84 |
85 |
86 | ## Step 3. Value for Value
87 |
88 | The final step is monetizing your content with cryptocurrency so your listeners can support you directly with no middle-men. This allows your content to be truly free from the pressures of advertising. Advertising serves a necessary role in any free market, but it does come with a cost. That cost is censorship - whether it's direct censorship by the advertisers themselves or self-censorship as you restrict your speech as to not offend the advertisers.
89 |
90 | Because of these issues, we've created a way to receive cryptocurrency payments directly from your listeners to you using the experimental `` tag in your podcast feed. Because it is experimental, it is not currently supported by any major podcast hosting companies. But, if you are so inclined, you can start using it in your feed today so that your podcast will show up on apps that support it like:
91 |
92 | - [Breez](https://Breez.technology)
93 | - [Podfriend](https://podfriend.com)
94 | - [CurioCaster](https://curiocaster.com)
95 | - [Podverse](https://podverse.fm)
96 | - [podStation](https://podstation.github.io)
97 | - [Sphinx.chat](https://sphinx.chat)
98 | - [Castamatic](https://castamatic.com)
99 | - [Fountain.fm](https://fountain.fm)
100 |
101 | If you can't add the `` tag to your feed manually, we also have created [a site](https://podcasterwallet.com) that can help you put a value tag directly into the Podcast Index database for your feed. Any apps that use the Podcast Index will see your value tag and be able to stream micropayments to you.
102 |
103 | The `` tag is still early and experimental. But, it does work today. There are more details about it in this [blog post](https://blog.podcastindex.org/html/AnotherWay-lJmNWj9T490hdmPmz5M4GV1Tlw6rDF.html), and in the official [whitepaper](value/value.md). The Podcasting 2.0 community is also always willing to lend you a hand and some advice on the [podcastindex.social](https://podcastindex.social) discussion server.
104 |
--------------------------------------------------------------------------------
/proposal-docs/API/Chapters.md:
--------------------------------------------------------------------------------
1 | # The podcast:chapters API Specification
2 |
3 | Version 1.0 by Benjamin Bellamy - 2021.03.11
4 |
5 |
6 | This version is a first draft. It will be updated. It may move somewhere else.
7 |
8 | ## Purpose
9 | The PodcastIndex namespace allows all podcast platforms (hosting, index, players…) to speak the same language and interact together.
10 | These interactions are limited to communications through the RSS feeds.
11 | This document describes a new type of interaction between actors who use a same PodcastIndex namespace tag: [Podcast:Chapters](https://github.com/Podcastindex-org/podcast-namespace/blob/main/chapters/jsonChapters.md).
12 | It was initiated by [David Norman](https://podcastindex.social/@hypercatcher) for [Hypercatcher](https://hypercatcher.com/) and [Benjamin Bellamy](https://podcastindex.social/@benjaminbellamy) for [Castopod](https://castopod.org/) so that HyperCatcher and Castopod are able to interact together and create a seamless experience for podcasters.
13 |
14 | We hope this will open a path to more collaborations between platforms which use the PodcastIndex namespace.
15 | (The podcast:transcript API is probably the next to be specified…)
16 |
17 | Note that the purpose of this specification is **not** to define “**how**” to manage the chapter service but “**who**” manages the chapter service, so that **any** podcaster is able to choose **any** provider among the ones able to provide the chapter service.
18 | Then that provider is free to use IPFS, centralised https or whatever makes sense to him — and to his users.
19 | This spec is **not** an extension of the [Podcast:Chapters](https://github.com/Podcastindex-org/podcast-namespace/blob/main/chapters/jsonChapters.md) tag, it sits next to it.
20 |
21 | ## Example
22 | To help making things clear, let's take an example:
23 | A podcaster, we'll call her Eve, is hosting a podcast on Castopod. She is using HyperCatcher to manage the chapters.
24 |
25 | ### Without the podcast:chapters API
26 | Whenever Eve wants to publish a new episode, she has to:
27 | - Go to her Castopod admin panel, save the episode, then publish it so that it is visible in the RSS feed.
28 | - Go to her HyperCatcher dashboard, click "Edit", click "Fetch Episodes" so that HyperCatcher gets this new episode.
29 | - Click on the newly fetched episode, copy the "Url for Json".
30 | - Go back to Castopod admin panel, edit the episode, paste the previously copied "Url for Json" into the appropriate field, hoping that no platform had fetched the RSS in the meantime, before the chapter Url was pasted.
31 |
32 | Later, Eve will wait for users to edit chapters, she will go back to HyperCatcher dashboard, Accept (or not) the community chapters.
33 |
34 | ### With the podcast:chapters API
35 | Whenever Eve wants to publish a new episode, she has to:
36 | - Go to her Castopod admin panel, save the episode. (Castopod will automatically call the podcast:chapters API at Hypercatcher, send the new episode and get from HyperCatcher the public "URL for Json" and insert it automatically in the RSS feed, get the private URL to the episode in the HyperCatcher dashboard and display the link on Castopod Dashboard.)
37 | - That's it.
38 |
39 | Later, Eve will wait for users to edit chapters, she will go back to HyperCatcher dashboard, Accept (or not) the community chapters.
40 | Because Castopod knows the private URL to the episode in the HyperCatcher dashboard, a link from the episode edit page in Castopod to the episode in HyperCatcher will be displayed. And we think that this is pretty cool.
41 |
42 | ## Technical Specification
43 | This API uses REST.
44 |
45 | It involves 2 parties:
46 | - a Poscast Hosting service.
47 | - a Chapters Provider service.
48 |
49 | ### Endpoints
50 | This API has only one endpoint (so far), hosted at the Chapters Provider.
51 |
52 | #### AddNewEpisode
53 | - `POST /AddNewEpisode`
54 | This adds a new Episode to the chapter provider.
55 | The endpoint URL may be defined by the chapter provider. The Podcast Hosting service must provide a way to specify this endpoint URL on its configuration panel.
56 |
57 | Parameters:
58 | - `rss`: RSS feed URL
59 | - `guid`: New Episode GUID
60 | - `enclosure_url`: New episode enclosure url
61 |
62 | Response:
63 | - `status`: true or false
64 | - `jsonUrl`: Url for Json
65 | - `episodeUrl`: Url for episode on dashboard
66 |
67 | ### Authentication
68 | Thir API will use the mechanism already used by the [PodcastIndex.org API](https://podcastindex-org.github.io/docs-api/#auth).
69 | The Chapters Provider will provide a couple `apiKey` and `apiSecret` which will be displayed on the user dashboard so that the podcaster can copy and paste them on his Podcast Hosting configuration panel.
70 | Fields:
71 | - `User-Agent`: Mandatory
72 | Please identify the system/product you are using to make this request.
73 | Example: Castopod/1.0
74 | - `X-Auth-Key`: Mandatory
75 | Your API key string
76 | Example: UXKCGDSYGUUEVQJSYDZH
77 | - `X-Auth-Date`: Mandatory
78 | The current unix epoch time as a string. 5 minute window.
79 | This value is an integer; round down if needed. The value shall not include a decimal point.
80 | Example: 1613713388
81 | - `Authorization`: Mandatory
82 | A SHA-1 hash of the X-Auth-Key, the corresponding secret and the X-Auth-Date value concatenated as a string. The resulting hash should be encoded as a hexadecimal value, two digits per byte, using lower case letters for the hex digits "a" through "f".
83 | Example: UXKCGDSYGUUEVQJSYDZH
84 | The Authorization header is computed with something like this (pseudo-code):
85 | ```
86 | authHeader = sha1(apiKey+apiSecret+unixTime)
87 | ```
88 |
89 | Discussion here:
90 | - https://github.com/Podcastindex-org/podcast-namespace/issues/209
91 | - https://podcastindex.social/web/statuses/105872943999299482
92 |
--------------------------------------------------------------------------------
/proposal-docs/bonusItem/bonusItem.md:
--------------------------------------------------------------------------------
1 | # The "podcast:bonusItem" Specification
2 |
3 | Version 1.0 by [Franco Solerio](https://github.com/francosolerio)
4 | January 10th, 2022
5 |
6 | ## Purpose
7 |
8 | With Value4Value podcasters can give their audience the possibility to send payments in response to the action of listening to a show. After a few months from its invention many shows already demonstrated that audiences embrace this possibility and reward podcasters, creating a virtuous loop that favours the production of more and better content. It is also evident that single listeners contribute in very different degrees, from big amounts to nothing. This can be attributed to many reasons, just to name a few: use of apps that still don't support Podcasting 2.0, the listener's financial condition, culture ad good will, the podcaster's ability to stimulate contribution both by improving the quality of their show and istigating listeners to contribute.
9 |
10 | The purpose of the `` block is to give podcasters another way to stimulate active contribution from the listeners by publishing bonus content on the same RSS feed, and making it available on the same app the listener already uses to consume regular episodes.
11 |
12 | Being available only on apps that support the specification, other than encouraging the financial contributions from the listeners, bonus content would give a competitive advantage and stimulate the adoption of the apps that support Podcasting 2.0 features.
13 |
14 |
15 | ## Process
16 |
17 | When the app parses the RSS feed, it stores and displays both the content of the usual `` blocks available in the standard RSS specification and the bonus items contained in `` blocks. The former are displayed as usual, while bonus content is displayed in a way that marks it as available for playing only when some conditions are met.
18 |
19 | The conditions can be specified in the `` block in terms of amount of money contributed in a specific timeframe. More than one alternative condition can be specified.
20 |
21 | Examples:
22 | - A bonus episode can be played by listeners who contributed with at least 10'000 sats in the last month.
23 | - An hystoric archive of episodes from the previous years is available for those who sent at least 100'000 sats in their lifetime.
24 |
25 |
26 | ## Structure:
27 |
28 | The structure of a `` block is identical to that of a regular `` block, with the addition of a `` sub-item:
29 |
30 | ```xml
31 |
32 | ...
33 | ...
34 | ...
35 |
36 | ...
37 |
41 |
42 | ```
43 |
44 | ### Sub-elements of \
45 | - `` (required) This specifies the mandatory condition to make the bonus item available to the user.
46 | It has one required and one optional attribute.
47 |
48 | #### Attributes of \
49 | - `minimumAmount` (required) specifies the minimum amount the user has to contribute to have access to the bonus item. The type of payment is the one specified in the \ block contained at the \ level.
50 | - `timeFrame` (optional) specifies the time, in seconds, to be considered for reaching the specified amount. If not present the time interval to be considered valid to reach the minimum amount is infinite.
51 |
--------------------------------------------------------------------------------
/proposal-docs/chat/chat.md:
--------------------------------------------------------------------------------
1 | # The "podcast:chat" Specification
2 |
3 | Version 1.0 by Dave Jones - 2022.04.10
4 |
5 |
6 |
7 | ## Purpose
8 | The `` tag allows a podcaster to attach information to either the `channel` or an `item` about where the
9 | "official" chat for either the podcast or a specific episode is to be found. Just like ``
10 | functions for social media, the `chat` tag will function for ephemeral chat. There are many protocols in use across
11 | the internet for chat based communication. This tag is meant to be flexible enough to adapt to whichever protocol the
12 | podcaster wants to use.
13 |
14 | This tag can exist at the `channel` or `item` level. It's presence at a particular level governs how it should be
15 | treated. If found at the `item` level, this should be treated as the information for that specific episode,
16 | overriding what is at the `channel` level. If this tag is found at the `channel` level, it would be considered the
17 | chat for the entire podcast and is recommended to be an "always on" chat room experience.
18 |
19 | If a podcast has an "always on" style chat service it is recommended to link that at the `channel` level and do not
20 | use the `` tag at the `item` level.
21 |
22 | ## Chat Element
23 | ``
24 |
25 | ### Parent
26 | `` or ``
27 |
28 | ### Count
29 | Single
30 |
31 | ### Attributes
32 | - **server** (required) The fqdn of a chat server that serves as the "bootstrap" server to connect to.
33 | - **protocol** (required) The [protocol](chatprotocols.txt) in use on the server.
34 | - **accountId** (recommended) The account id of the podcaster on the server or platform being connected to.
35 | - **space** (optional) Some chat systems have a notion of a chat "space" or "room" or "topic". This attribute will serve
36 | that purpose.
37 |
38 |
39 | Example (IRC):
40 | ```xml
41 |
47 | ```
48 |
49 | Example (XMPP):
50 | ```xml
51 |
57 | ```
58 |
59 | Example (Nostr):
60 | ```xml
61 |
67 | ```
68 |
69 | Discussions:
70 | - https://github.com/Podcastindex-org/podcast-namespace/discussions/502
--------------------------------------------------------------------------------
/proposal-docs/chat/chatprotocols.txt:
--------------------------------------------------------------------------------
1 | irc
2 | xmpp
3 | nostr
4 | matrix
--------------------------------------------------------------------------------
/proposal-docs/hive-account-name/hive-account-name.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | # WITHDRAWN - The "podcast:hiveAccount" Specification
4 |
5 | Version 1.0 by Brian of London - 2021.06.08
6 |
7 | Withdrawn - It's handled better by `customKey` and `customValue` in the [`value block`](value/value.md)
--------------------------------------------------------------------------------
/proposal-docs/license/license.md:
--------------------------------------------------------------------------------
1 | # The "podcast:license" Specification
2 |
3 | Version 1.0 by Benjamin Bellamy - 2021.03.05
4 |
5 |
6 |
7 | ## Purpose
8 |
9 | Podcasting is an open ecosystem where information travel freely from platform to platform, but that does not mean that podcasts are free.
10 | The fact that podcast files are available for anyone to download does not mean that anyone is allowed to do anything with them.
11 | But how can one know what is permitted? It is often difficult, or even impossible, to know - even more if you want to manage that automatically.
12 | This situation creates awkward conflicts where everyone acts in good faith, everyone shares the same goal (growing audiences for podcasts) but everyone disagrees on what is acceptable.
13 |
14 | - Can the podcast be locally copied? Then can the copy be shared? Should it be fetched from the original location only?
15 | - Can the podcast be shared/played for free?
16 | - Can the podcast be shared/played for a fixed fee? For a subscription fee?
17 | - Can the podcast be used to display ads on it?
18 | - Can it be used for audio insertion? Pre-roll, mid-roll, post-roll?
19 | - Can it be trimmed, cut, edited? Translated? Dubbed?
20 | - Can the shownotes be trimmed, cut, edited? Converted from HTML to plain text?
21 |
22 | We have seen in the past Podcasters demanding to have their podcast removed from a platform because they felt they were being stolen from, even if that would mean less audience for them.
23 | If we can provide a way to make what is allowed and what is forbidden crystal clear, we will avoid such conflicts.
24 |
25 | Please note that this document is about what can be done after the podcast is published, not before.
26 | (For instance, using copyrighted music or copyrighted material in a podcast is not the subject here.)
27 |
28 | You may read [PODCASTING LEGAL GUIDE: RULES FOR THE REVOLUTION](https://wiki.creativecommons.org/wiki/Podcasting_Legal_Guide) for more information.
29 |
30 | This matter is very complex so this specification only intends to scratch its surface in its current version.
31 |
32 | ## Specification
33 |
34 | - **\[License Slug from SPDX List]
17 |
18 | ## Process
19 |
20 | The process of subscribing to a feed consists of making the purchase, storing a shared seed value and storing a shared subscriber id. The purchase
21 | can be made over standard payment processors, cryptocurrency or any other method of payment the podcast creator chooses to use.
22 |
23 |
24 |
25 | ### Initiating the purchase
26 |
27 | A members-only feed will contain a `` element that points to a website the user will use to complete the subscription signup
28 | process. That process can be any method of paying and the app would probably just open a web view to the site and let the signup process happen
29 | right in the app.
30 |
31 | ### Generating the shared values
32 |
33 | Once the signup and payment has occurred, the server that processed the signup will generate a seed value to be used in a TOTP (Time-based One Time Password)
34 | calculation. The seed value will be stored by the server in order to calculate the TOTP value in the future. It will also be handed back to the app which
35 | will store the seed in it's internal database associated with this particular RSS feed. A user identifier will also be generated by the server and handed
36 | back to the app so that an association can be kept between the TOTP seed and the user it belongs to.
37 |
38 | ### Playing the Content
39 |
40 | When the app does a GET request for an enclosure within the subscription feed, it will first calculate the current TOTP value based on it's stored copy
41 | of the seed and then attach that value to the GET request as a url parameter, like this:
42 |
43 | ```http
44 | GET https://example.com/cdn/podcast/episode23.mp3?_subscriberid=019280835669288573153765328753&_privtoken=247163
45 | ```
46 |
47 | The server validates the transmitted TOTP code by generating it server side based on the subscriber id given in the request.subscriber
48 | If the subscriber's subscription ever lapses, the server simply forgets the TOTP seed and no future requests for content will validate.
49 |
50 | ### Moving subscriptions between apps
51 |
52 | Because subscriptions are maintained by a simple TOTP random seed value, the values can be exported along with an opml file and imported into other apps.
53 |
54 |
55 |
56 | ### Subscribe Element
57 |
58 | The `` tag designates the server that will handle the subscription processing for the feed.
59 |
60 | This element must exist at the `` level.
61 |
62 | There can be only one copy of this element in a feed.
63 |
64 |
65 |
66 | #### Structure:
67 | ```xml
68 |
71 | ```
72 |
73 |
74 | #### Attributes:
75 | - `url` (required) This is the service slug of the cryptocurrency or protocol layer.
76 |
77 |
78 |
79 |
--------------------------------------------------------------------------------
/proposal-docs/podping/podping.md:
--------------------------------------------------------------------------------
1 | # The "podcast:podping" Specification
2 |
3 | Version 1.0 by Brian of London - 2021.06.08
4 |
5 |
6 |
7 | ## Purpose
8 |
9 | The Podping notification system is rapidly developing as a new standard for signalling new episodes of podcasts to reduce constant polling. Once a new episode or entirely new podcast is sent out as a podping on the Hive blockchain, aggregators and apps can query the feed.
10 |
11 | However, as pointed out in issue https://github.com/Podcastindex-org/podcast-namespace/issues/258, there is, as yet, no way to know which feeds are using Podping.
12 |
13 | This tag proposal will allow feed owners and the hosts of multiple feeds, to signal that future updates will be sent via Podping and there is no need to speculatively poll this rss feed.
14 |
15 | An additional benefit will derive if feeds signal the name or names of the Hive accounts authorized to send Podpings. These authorized Hive accounts will be included in a `` tag
16 |
17 | ## API Requirements
18 |
19 | This tag can also contribute to a future API endpoint for the PodcastIndex which can easily return whether or not any given RSS feed is using Podping and return the Hive accounts authorized to send pings.
20 |
21 | ## Specification
22 |
23 | For the `` tag there is only one optional attribute `usesPodping` which will usually be set to `True` though could be set to `False` to specifically opt out of using Poding and indicate a feed must be polled by legacy RSS polling methods.
24 |
25 | For the optional but helpful `` tag there is one attribute, a single value with a single Hive account which is allowed to issue `podpings` for this feed.
26 |
27 | ## Example
28 |
29 | ```xml
30 |
31 |
32 |
33 |
34 |
35 | ```
36 |
37 | ## Example
38 |
39 | ```xml
40 |
41 | ```
42 |
43 | or
44 |
45 | ```xml
46 |
47 | ```
48 |
--------------------------------------------------------------------------------
/proposal-docs/social/platforms.md:
--------------------------------------------------------------------------------
1 | ### Social Platform / Protocol
2 |
3 | Note: Draft - trying to figure out if the platform/protocol list should be a separate file.
4 |
5 | The and elements both contain a platform and protocol element. This is a list of suitable platforms and protocols
6 |
7 | - `platform` (required): This is the platform id. It can be one of the following:
8 | - `protocol` (required): This is the protocol name. It can be one of the following:
9 |
10 | | `platform` | `protocol` |
11 | | ---------- | ------------------|
12 | | castopod | activitypub |
13 | | mastodon | activitypub |
14 | | peertube | activitypub |
15 | | | xmpp |
16 | | | irc |
17 | | matrix | matrix |
18 | | facebook | facebook |
19 | | twitter | twitter |
20 | | instagram | instagram |
21 | | slack | slack |
22 | | discord | discord |
23 | | castgarden | hive |
24 | | 3speak | hive |
25 | | peakd | hive |
26 | | fountain | lightningcomments |
27 |
28 |
29 | - `platform` (required): This is the platform id. It can be one of the following:
30 | - castopod
31 | - mastodon
32 | - peertube
33 | - facebook
34 | - twitter
35 | - instagram
36 | - slack
37 | - discord
38 | - cast.garden
39 | - 3speak
40 | - peakd.com
41 | - fountain
42 | - …
43 | - `protocol` (required): This is the protocol name. It can be one of the following:
44 | - activitypub
45 | - xmpp
46 | - irc
47 | - matrix
48 | - facebook
49 | - twitter
50 | - instagram
51 | - slack
52 | - discord
53 | - hive
54 | - lightningcomments (see #347)
55 | - …
56 |
--------------------------------------------------------------------------------
/proposal-docs/social/social.md:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 | # THIS IS NOT THE FINAL SPECIFICATION
8 |
9 | You [want to look here for that](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#social-interact)
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 | # The "podcast:social" Specification
18 |
19 | Version 1.0 by Benjamin Bellamy - 2021.04.13
20 |
21 | **This is not the final specification. You [want to look here for that](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#social-interact)**
22 |
23 |
24 |
25 | ## Purpose
26 |
27 | Social networks (Facebook, Instagram, Twitter, Mastodon…) and discussion platforms (Slack, Discord, XMPP/Jabber, IRC, Matrix…) are a convenient way
28 | for podcasters to interact with their audience, and for listeners to interact with podcasters.
29 | Thanks to them listeners can comment, share or like podcast episodes.
30 | The purpose of this specification is to allow podcast apps to know where they should guide the listeners to make these interactions - and the onboarding process
31 | necessary to make them possible - as seamless as possible.
32 | Of course not all podcast apps would implement all platforms. Each one would implement the one(s) they want to provide their users a better interaction with.
33 |
34 | There are three elements:
35 | - **"podcast:social"** for the \ element: tells the user **which platform(s)** is/are used for this podcast.
36 | - **"podcast:socialSignUp"** for the \ element: tells the user **where to sign up** on this platform.
37 | - **"podcast:socialInteract"** for the \ element: tells the user where to **interact with this specific episode**.
38 |
39 | ## Elements
40 |
41 | ### Social Element
42 |
43 | - **\**[one or more "podcast:socialSignUp" elements]**\**
44 |
45 | Channel (optional | multiple)
46 |
47 | This element allows a podcaster to specify one or more platforms where listeners can interact.
48 | There may be several occurences of this tag for the same element (on several platforms, the podcast may have several accounts on the same plaforms…)
49 |
50 | - `platform` (required): This is the platform id. It can be one of the following:
51 | - castopod
52 | - mastodon
53 | - peertube
54 | - facebook
55 | - twitter
56 | - instagram
57 | - slack
58 | - discord
59 | - cast.garden
60 | - 3speak
61 | - peakd.com
62 | - …
63 | - `protocol` (required): This is the protocol name. It can be one of the following:
64 | - activitypub
65 | - xmpp
66 | - irc
67 | - matrix
68 | - facebook
69 | - twitter
70 | - instagram
71 | - slack
72 | - discord
73 | - hive
74 | - …
75 | - `accountId` (required): The podcast ID on this platform.
76 | - `accountUrl` (required): The podcast URL on this platform.
77 | - `priority` (optional): This platform priority (useful if the podcaster wants to tell which platform is preferred, lower is better)
78 |
79 | Examples:
80 | - ``
81 | - ``
82 |
83 | ### SocialSignUp Element
84 |
85 | - **\**
86 |
87 | podcast:social (optional | multiple)
88 |
89 | This element allows easy onboarding for listeners on social/discussion platforms, especially for decentralized ones (such as Matrix or ActivityPub) where podcasters and listeners can register on different servers.
90 |
91 | - `homeUrl` (required): The platform home URL.
92 | - `signUpUrl` (required): The platform sign up URL.
93 | - `priority` (optional): This platform priority (useful if the podcaster wants to tell which platform is preferred, lower is better)
94 |
95 | Examples:
96 | - ``
97 | - ``
98 |
99 | ### SocialInteract Element
100 |
101 | - **\**[URL to this episode on this platform]****
102 |
103 | Item or Channel (optional | multiple)
104 |
105 | This element allows listeners to interact with (comment, share, like, review…) an episode, or a podcast.
106 |
107 | - `platform` (required): This is the platform id. It can be one of the following:
108 | - castopod
109 | - mastodon
110 | - peertube
111 | - facebook
112 | - twitter
113 | - instagram
114 | - slack
115 | - discord
116 | - cast.garden
117 | - 3speak
118 | - peakd
119 | - fountain
120 | - none *(to indicate a strong opt-out preference)*
121 | - …
122 | - `protocol` (required): This is the protocol name. It can be one of the following:
123 | - activitypub
124 | - facebook
125 | - twitter
126 | - instagram
127 | - slack
128 | - discord
129 | - xmpp
130 | - irc
131 | - matrix
132 | - hive
133 | - lightningcomments (see #347 for protocol description)
134 | - …
135 | - `accountId` (required): The podcast ID on this platform.
136 | - `pubDate` (optional): publication date on this platform. This can be useful when there are several interactions for the same platform for the same episode (for instance, two Tweets about the same episode). Format must be [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601).
137 | - `priority` (optional): This platform priority (useful if the podcaster wants to tell which platform is preferred, lower is better)
138 | - element's content: URL to the social media post on this platform corresponding to this episode (if at the `` level) or for this podcast (if at the `channel` level), or a short reason for apps to display when comments are disabled (if `platform="none"`)
139 |
140 | Examples:
141 | - `https://twitter.com/Podverse/status/1375624446296395781`
142 | - `https://lespoesiesdheloise.fr/@heloise/notes/e4b3d7f3-e84b-40c6-b828-f5537f0c3659`
143 | - `https://api.fountain.fm/v1/comments?feed=221233&episode=1230123071`
144 |
145 | Or to opt out:
146 | - `Comments disabled for this episode`
147 |
148 | ## Full RSS feed example
149 |
150 | ```xml
151 |
152 |
153 |
154 |
155 | Les Poésies d’Héloïse
156 | […]
157 |
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 |
167 |
168 |
169 |
170 |
171 | Oisillon bleu
172 |
173 | https://lespoesiesdheloise.fr/episode_2019-04-10_lpdh_oisillonbleu
174 | Wed, 10 Apr 2019 14:15:00 +0000
175 | https://lespoesiesdheloise.fr/@heloise/episodes/oisillon-bleu
176 | […]
177 |
178 | https://lespoesiesdheloise.fr/@heloise/notes/4ba8df51-d67d-405d-a475-6471e1235c1c
179 | https://api.fountain.fm/v1/comments?feed=221233&episode=1230123071
180 | https://www.facebook.com/LesPoesiesDHeloise/posts/399766303947452
181 |
182 |
183 | […]
184 |
185 |
186 |
187 | ```
188 |
189 | Discussion here:
190 | - https://github.com/Podcastindex-org/podcast-namespace/issues/153
191 | - https://podcastindex.social/web/statuses/106065482252134072
192 |
--------------------------------------------------------------------------------
/proposal-docs/updateFrequency/updateFrequency.md:
--------------------------------------------------------------------------------
1 | # The `` Specification
2 |
3 | Version 1.0 by [Nathan Gathright](https://github.com/nathangathright) - 2023.02.13
4 |
5 | > A tag to provide podcasters a way to express their intended schedule for future releases.
6 |
7 | ## Purpose
8 | In the spirit of taking platform-specific innovations and making them accessible to the open ecosystem of RSS, the intent of this proposal is to replicate the purpose of the “Update Frequency” field in Apple Podcasts Connect as well as replace the `` tag for podcasts that have no intention to release further episodes.
9 |
10 | Additionally, apps like Overcast, Pocket Casts, and Podchaser analyze the intervals between past episodes to estimate a prediction for future releases. Under certain conditions or naive algorithms, this can be inaccurate:
11 | * New podcasts that only have a trailer
12 | * Limited-run podcasts nearing the end of a season
13 | * “Daily” podcasts that only release on weekdays
14 | * Podcasts with consistent releases at irregular intervals (every Monday and Wednesday)
15 |
16 | If podcasters can unambiguously communicate their release schedule, then more apps can provide accurate information to their listeners.
17 |
18 | ## Parent
19 | ``
20 |
21 | ## Count
22 | Single
23 |
24 | ## Node value
25 |
26 | The node value is a free-form string, which might be displayed alongside other information about the podcast. Please do not exceed `128 characters` for the node value or it may be truncated by aggregators.
27 |
28 | ## Attributes
29 | * **complete (optional):** Boolean specifying if the podcast has no intention to release further episodes. If not set, this should be assumed to be false.
30 | * **dtstart (optional):** The `date` or `datetime` the recurrence rule begins as an [ISO8601-fornmatted](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString) string. If the `rrule` contains a value for `COUNT`, then this attribute is required. If the `rrule` contains a value for `UNTIL`, then the value of this attribute must be formatted to the same date/datetime standard.
31 | * **rrule (recommended):** A recurrence rule as defined in [iCalendar RFC 5545 Section 3.3.10](https://www.rfc-editor.org/rfc/rfc5545#section-3.3.10).
32 |
33 | ## Examples
34 |
35 | Recreating most of Apple Podcasts Connect’s “Update Frequency” values is easily achieved:
36 | ```xml
37 | Daily
38 | Weekly
39 | Biweekly
40 | Monthly
41 | Bimonthly
42 | Monthly
43 | Yearly
44 | ```
45 |
46 | However, greater precision can be easily communicated:
47 | ```xml
48 | Every weekday
49 | Every Monday and Wednesday
50 | Every friday the 13th
51 | Every year on American Thanksgiving
52 | ```
53 |
54 | Limited-run podcasts can indicate when they’ll go on hiatus by setting an UNTIL date or a COUNT:
55 | ```xml
56 | Every other Monday for 10 episodes starting on Aug 28, 2023
57 | Every Monday until Dec 31, 2023
58 | ```
59 |
60 | Podcasts currently on hiatus can indicate their intention to resume production by setting a DTSTART value in the future:
61 | ```xml
62 | Weekly, starting in 2025
63 | ```
64 |
65 | Complete podcasts with no intention to release further episodes:
66 | ```xml
67 | That’s all folks!
68 | ```
69 |
--------------------------------------------------------------------------------
/proposal-docs/value-webmonetization/value-webmonetization.md:
--------------------------------------------------------------------------------
1 | # Web Monetization using ``
2 |
3 | To enable and promote Web Monetization (WM) in podcasting, necessary information for WM could be provided for a podcast by adding a `` tag to the RSS feed.
4 | https://github.com/Podcastindex-org/podcast-namespace/blob/main/value/value.md
5 |
6 | This `value` tag would have the following values for use with Web Monetization:
7 | ```xml
8 |
12 | ```
13 |
14 | The `podcast:value.type` defines the cryptocurrency or protocol layer, which in this case is used to define Web Monetization payment information, using the value of `webmonetization`.
15 |
16 | The `method` of `ILP` specifies the use of [Interledger Protocol (ILP)](https://interledger.org/rfcs/0027-interledger-protocol-4/) which is the protocol for payment providers in WM.
17 |
18 | Within the `podcast:value` tag we also need to designate recipients. In Web Monetization, payment info is discovered using the [Simple Payment Setup Protocol](https://interledger.org/rfcs/0009-simple-payment-setup-protocol) with which the [Open Payments](https://docs.openpayments.dev/web-monetization) protocol is designed to be [backwards compatible](https://docs.openpayments.dev/web-monetization#backwards-compatibility-with-spsp).
19 |
20 | Both SPSP and Open Payments use a recipient address in the form of a [Payment Pointer](https://github.com/interledger/rfcs/blob/master/0026-payment-pointers/0026-payment-pointers.md) which will be provided in the `address` attribute, with the `type` of `paymentpointer`.
21 |
22 | ```xml
23 |
27 |
33 |
34 | ```
35 |
36 | While payments in WM are streamed to a single payment pointer at a time, the WM authors suggest splits can be implemented using [Probabilistic Revenue Sharing](https://webmonetization.org/docs/probabilistic-rev-sharing) or perhaps it should be [implemented at the payment pointer](https://github.com/Podcastindex-org/podcast-namespace/issues/132#issuecomment-780145285) rather than expecting the client to be responsible. In either case, the `podcast:value` and `podcast:valueRecipient` tags can provide sufficient information for a web player or page to setup Web Monetization for the podcast.
37 |
38 | ------
39 |
40 | ### Current
41 | https://github.com/Podcastindex-org/podcast-namespace/blob/main/value/value.md
42 | https://github.com/Podcastindex-org/podcast-namespace/blob/main/value/valueslugs.txt
43 |
44 | ### Web Monetization and Podcasting Discussion
45 | https://github.com/Podcastindex-org/podcast-namespace/issues/132
46 | https://github.com/WICG/webmonetization/issues/70
47 |
48 | ### Background WM (i.e. for podcast audio playing on a background tab)
49 | https://github.com/coilhq/web-monetization-projects/issues/387
50 | https://github.com/WICG/webmonetization/issues/17
51 |
52 | ### PRX Player Implementation (in production)
53 | Player repository: https://github.com/PRX/Play-Next.js
54 | Component to implement monetization: https://github.com/PRX/Play-Next.js/tree/main/components/Player/WebMonetized
55 | Parsing `webmonetization` from the RSS feed: https://github.com/PRX/Play-Next.js/blob/main/lib/parse/data/parseEmbedData.ts#L33-L40
56 |
57 | ### Castopod Implementation
58 | https://podlibre.social/@Castopod/105278541687633547
59 | https://blog.castopod.org/castopod-supports-web-monetization/
60 | https://github.com/ad-aures/castopod/blob/v1.0.0-beta.14/app/Helpers/rss_helper.php#L85-L95
61 |
62 | ### PodStation Planning by [Guilherme Dellagustin](https://github.com/dellagustin)
63 | https://github.com/podStation/podStation/issues/185
64 |
--------------------------------------------------------------------------------
/publishers/publishers.md:
--------------------------------------------------------------------------------
1 | # The Publisher Medium
2 | v1.0 - April 5, 2024
3 |
4 |
5 |
6 | Below, you will find implementation details about using the `publisher` value in the [``](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#medium) tag to
7 | create "publisher feeds".
8 |
9 |
10 |
11 | ## Overview
12 |
13 | The idea of a "publisher" is that a single entity (person, organization, record label, etc) might be the responsible
14 | party which produces multiple podcast feeds. In such a case it would be useful to be able to see all of a
15 | publisher's podcasts collected in a single place. For instance, a news organization might produce 12 different
16 | podcast feeds. Or, a music artist might produce 3 albums of music using the `` tag of `music`. In
17 | those cases, having a high level feed that references these other feeds would make it easier for podcast apps to
18 | associate those feeds with a particular publishing entity.
19 |
20 | Likewise, it is helpful if the produced feeds link back to the "publisher feed" so that podcast apps can walk back
21 | up the chain from a podcast feed to it's publisher in order to find other relevant content from that publishing
22 | entity. For instance, a listener may subscribe to a music album by an artist and want to find their other
23 | albums and singles.
24 |
25 | When a publisher feed links to it's "child" feeds, and those "child" feeds link back to their "parent" publisher
26 | feeds, this provides a two-way validation that a feed is indeed a valid part of a publishing entities portfolio of
27 | content. If a feed links to a publisher feed without the publisher feed referencing it, that association should be
28 | discarded.
29 |
30 |
31 |
32 | ## Publisher Feed Requirements
33 |
34 | A publisher feed must have the following parts in it's ``:
35 |
36 | 1. A [``](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#medium) tag with a value of `publisher`.
37 | 2. A valid [``](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#guid).
38 | 3. One or more [``](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#remoteItem) tags that link to podcast feeds.
39 |
40 | ### Example
41 |
42 | The following example shows a publisher feed that links to all of the feeds published by the "AgileSet Media" entity.
43 | This feed also makes use of the [``](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#person) tag to define a responsible person at the
44 | publishing entity.
45 |
46 | ```xml
47 |
48 |
49 | AgileSet Media
50 | https://agilesetmedia.com
51 | AgileSet Media is an unincorporated, unregistered, and unpapered entity of AgileSet LLC for producing and publishing stuff by Mike Neumann. It is based in Texas, USA.
52 |
53 | https://agilesetmedia.com/assets/static/AgileSet-logo-square-sm-144.png
54 | AgileSet Media
55 | https://agilesetmedia.com
56 | 144
57 | 144
58 |
59 | Mike Neumann
60 | 003af0a0-6a45-55bf-b765-68e3d349551a
61 | publisher
62 |
63 |
64 |
65 |
66 |
67 | ```
68 |
69 |
70 |
71 | ## Linking to Publisher Feeds
72 |
73 | While not strictly required, adding a reference to the publisher feed from the "child" feeds is a good idea, as it
74 | makes discovery of your other content much easier. Podcast apps can see this linkage and "walk back up the chain"
75 | to your publisher feed and then recommend your other podcast content to a listener. To do this, you will need to
76 | add a `` tag in the `` of the "child" feed that will contain a `` link to
77 | the
78 | publisher feed.
79 |
80 | ### Example
81 |
82 | The following example snippet shows a podcast feed produced by "AgileSet Media" that links to the publisher feed
83 | example above.
84 |
85 | ```xml
86 |
87 |
88 |
89 | A value4value happenstance music show.
90 | https://itsamood.org
91 | Sovereign Feeds
92 | Mike Neumann
93 | 469b403f-db2d-574c-9db9-96dbb3f6561c
94 | podcast
95 |
96 |
97 |
98 |
99 |
100 | Wed, 03 Apr 2024 02:06:28 +0000
101 | ...
102 |
103 |
104 |
105 | ```
--------------------------------------------------------------------------------
/serviceslugs.txt:
--------------------------------------------------------------------------------
1 | acast
2 | amazon
3 | anchor
4 | apple
5 | audible
6 | audioboom
7 | backtracks
8 | bitcoin
9 | blubrry
10 | buzzsprout
11 | captivate
12 | castos
13 | castopod
14 | facebook
15 | fireside
16 | fyyd
17 | google
18 | gpodder
19 | hypercatcher
20 | kasts
21 | libsyn
22 | mastodon
23 | megafono
24 | megaphone
25 | omnystudio
26 | overcast
27 | paypal
28 | pinecast
29 | podbean
30 | podcastaddict
31 | podcastguru
32 | podcastindex
33 | podcasts
34 | podchaser
35 | podcloud
36 | podfriend
37 | podiant
38 | podigee
39 | podnews
40 | podomatic
41 | podserve
42 | podverse
43 | redcircle
44 | relay
45 | resonaterecordings
46 | rss
47 | shoutengine
48 | simplecast
49 | slack
50 | soundcloud
51 | spotify
52 | spreaker
53 | tiktok
54 | transistor
55 | twitter
56 | whooshkaa
57 | youtube
58 | zencast
59 |
--------------------------------------------------------------------------------
/socialprotocols.txt:
--------------------------------------------------------------------------------
1 | disabled
2 | activitypub
3 | twitter
4 | lightning
5 | atproto
6 | hive
7 | matrix
8 | nostr
9 |
--------------------------------------------------------------------------------
/transcripts/example.json:
--------------------------------------------------------------------------------
1 | {
2 | "version": "1.0.0",
3 | "segments": [
4 | {
5 | "speaker": "Darth Vader",
6 | "startTime": 0.5,
7 | "endTime": 0.75,
8 | "body": "I"
9 | },
10 | {
11 | "speaker": "Darth Vader",
12 | "startTime": 1,
13 | "endTime": 1.25,
14 | "body": "am"
15 | },
16 | {
17 | "speaker": "Darth Vader",
18 | "startTime": 1.5,
19 | "endTime": 2.0,
20 | "body": "your"
21 | },
22 | {
23 | "speaker": "Darth Vader",
24 | "startTime": 2.25,
25 | "endTime": 2.50,
26 | "body": "father."
27 | },
28 | {
29 | "speaker": "Luke",
30 | "startTime": 2.75,
31 | "endTime": 3.0,
32 | "body": "Nooooo"
33 | }
34 | ]
35 | }
36 |
--------------------------------------------------------------------------------
/transcripts/example.vtt:
--------------------------------------------------------------------------------
1 | WEBVTT
2 |
3 | 00:00:00.000 --> 00:00:02.760
4 | In today's episode, you'll learn whether or not you
5 |
6 | 00:00:02.760 --> 00:00:06.090
7 | should have a podcast trailer. And if so, what should you
8 |
9 | 00:00:06.090 --> 00:00:11.610
10 | include in one? Welcome to Podcasting Q&A, where you learn
11 |
12 | 00:00:11.610 --> 00:00:15.750
13 | the best tips and strategies to launch, grow and monetize your
14 |
15 | 00:00:15.750 --> 00:00:18.630
16 | podcast. This week's question comes from Gillian.
17 |
18 | 00:00:19.080 --> 00:00:21.450
19 | Hi Buzzsprout, Gillian here from breaking through
20 |
21 | 00:00:21.450 --> 00:00:25.350
22 | careers podcast. My question is, do we need a podcast trailer?
23 |
--------------------------------------------------------------------------------
/transcripts/transcripts.md:
--------------------------------------------------------------------------------
1 | ## Transcript File Format Details
2 |
3 | This is the initial spec for the podcast transcript format. There are four possible formats detailed below.
4 |
5 | Some transcript implementations are done in-browser. [CORS headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)
6 | are required to make these files available from other websites. [A CORS tester is available here](https://cors-test.codehappy.dev/),
7 | to ensure that transcripts are available within browser-based players.
8 |
9 | * **Want to support only one format?** WebVTT is used by Apple Podcasts for ingest, and also natively supported by web browsers. Because the WebVTT format is the most flexible, it's an ideal choice if you can only support one format.
10 |
11 | The examples given below are just for convenience. In production you should ensure you are conforming to the actual spec for each format as defined in its own documentation.
12 |
13 | ## WebVTT
14 |
15 | The [Web Video Text Tracks Format (WebVTT)](https://www.w3.org/TR/webvtt1/) is designed for use in HTML on the web. You can use the [