Brainstorming: Community Chapters

[thebells1111]

With the idea of letting listeners become producers, I'm brainstorming some ways to allow for the creation of community chapters.

Basically, it would be some sort of API that can read the queries attached to the url, with the queries being episode startTime img and url to correspond to the chaptersJson keys. A podcaster would put the link to the API in the chapters tag something like

<podcast:chapters url="https://example.com/episode1/chapters.json" type="application/json+chapters" community="https://example.com/api/chapters>

Then the apps can easily create a UI that allows a listener to push a button to create a chapter, then allows them to add a title, startTime, image, and image url, which would then send a GET request to the link in the community tag. Like this:

https://example.com/api/chapters?episode=episode1&startTime=168&title=Hearing%20Aids&img=https%3A%2F%2Fexample.com%2Fimages%2Fhearing_aids.jpg

The chapters host can then allow the podcaster to see all of the different chapters the listeners have created, check the ones they want to include in the final chapters.json file, and then create the chapters.json file which in our example is https://example.com/episode1/chapters.json.

Once that is done, they simply remove community from <podcast:chapters> and the apps now know community chapters are no longer enabled for that episode.

[yoshimo]

Community chapters , that could also be something that runs without the content creators intervention. Transcripts and chapter marks are not always part of the producers pipeline as i noticed with some public radio stations. I think it would be an opportunity for others to supply added or corrected info for episodes without the need for the original producer to create them or edit the original feed. That stamp of approval could be optional.

[mitchdowney]

+1000000 for community chapters. I don't how it should work exactly, but some kind of open standard way to crowdsource chapter creation would be amazing.

One thing I'll say is I have a hard time seeing chapter creation fitting into Podverse's already quite busy UX...I think a standalone tool for posting community chapters, plus a link to it in the episodes description to the podcaster's recommended community chapter's tool/s could work well.

I also think podcasters may want to know who created the chapters. What if there are particular listeners they trust more with creating quality chapters? Identity is a huge problem to solve in itself though, so probably not feasible. I think worth considering though how podcasters might be able to filter "spam" chapters.

Anyway, awesome idea! Very interested in seeing how this develops.

[theDanielJLewis]

I have some thoughts.

1. Community-created chapters could be a way for listeners to simply highlight a section, like how you can see other most popular readers' highlights when reading some ebooks. So it might be good to support this kind of usage.
2. A potential problem community chapters creates is that it punishes the most loyal listeners who listen immediately when an episode is available, missing out on any chapters. I get this all the time with No Agenda and Podcasting 2.0. Even if I was listening with an app that supported the chapters, I wouldn't get to see them because it's still several hours or a day before the chapters are added. A way to create such chapters from a draft file or live-stream would be great! Of course, the timestamps would shift from the natural trimming from the start of episodes, and significantly shift from editing. So a format the podcaster can easily include in their editing could be great, like a label track for Audacity and markers in Audition.
3. I highly recommend avoiding "chapters.json" because it's an episode metadata file that can hold much more than chapters. It's like calling Walmart a donut shop. Don't start thinking inside the box now! 😃

[nathangathright]

The chapters host can then allow the podcaster to see all of the different chapters the listeners have created, check the ones they want to include in the final chapters.json file, and then create the chapters.json file

If the podcaster still has the final say over which chapters/transcripts are displayed to all listeners, then the heavy lift is really a wiki-style service for users to suggest edits and host JSON (and images). The podcaster could claim their feed, approve edits, and point their chapters/transcripts tags to the JSON hosted by that site. Imagine something like:

<podcast:chapters url="https://studio.hypercatcher.com/<podcast-guid>/episode/<episode-guid>/chapters.json">
<podcast:transcript url="https://studio.hypercatcher.com/<podcast-guid>/episode/<episode-guid>/transcript.json">

Once someone builds such a service, then there might be value in a new community attribute to link visitors to the correct place to suggest edits.

[ryan-lp]

I believe there may be some legal considerations here. For background:

• https://law.stackexchange.com/questions/21886/copyright-implications-of-creating-transcripts
• https://www.avvo.com/legal-answers/am-i-infringing-copy-right-if-selling-transcript-o-2377069.html

There seems to be a general consensus, where one Intellectual Property attorney writes:

This would be blatant, illegal copyright infringement. You Tube videos are protected by copyright. The transcriptions that you have made are derivative works. It is illegal to create a derivative work, such as a transcription, without permission from the copyright owner. Indeed, it was illegal for you to create these transcriptions even for personal use. If you were to attempt to sell copies of the transcripts on line, you would be engaging in willful, blatant, illegal copyright infringement for which you could face both criminal and civil penalties.

So you might want to consult a lawyer before doing something like this.

I wonder if chapters would be any different? IANAL, but it seems to me that community chapters might be less problematic if they are comparable in content to a chapter-by-chapter book review, expressed in the chapter creator's own words rather than being a direct copy of the podcast copyright holder's words. But it may all depend on the content of the chapters. So I would suggest consulting with a lawyer on either issue to make sure you're not committing copyright infringement en masse.

Now a related issue might be whether to introduce a namespace tag such that podcast creators can explicitly grant the community permission to do these things -- wherever they legally require permission from the creator -- in a machine readable way through the RSS feed itself. If they are indeed things that require permission from the copyright holder, then that would suggest that the default permission value of these tags should be assumed as "permission not granted". Hopefully, though, it ends up being the case that chapters do not require permission from the copyright holder (but again you probably should consult a lawyer to answer that question.)

As for the community aspect of these endeavours, unless this runs on the blockchain or some other kind of distributed system, what is being proposed above is a single API endpoint which will no doubt be owned and controlled by a single company or other organisation which takes part of the impact out of the word "community". On the other hand, we may need to appreciate that the way to solve the legal considerations mentioned above is for an actual company or other organisation to take on that legal responsibility to consult with the lawyers and to facilitate the legal contracts between the legal identities involved with the copyrighted works. In such a scenario, perhaps one of the purposes of this discussion can be to develop a standard that multiple companies can implement rather than a single company. For example, it could be that each podcast hosting provider could potentially implement the API, and there could be independent alternative services that can be used if a hosting provider doesn't offer that API. Then, whoever decides to provide such an API takes on the responsibility to present the necessary legal agreements to the users.

[nathangathright]

Yes, those are valid concerns if one were building a permissionless system for community chapters, but I don't expect this would play out like the socialInteract tag (with every app, host, and service running their own ActivityPub server). IMO, this is more suited to be a "Suggest Edit" feature for hosting platforms, moderated by the podcaster. For now, I'm not even sure if any of the current Podcasting 2.0 hosts support linking to external files for chapters or transcripts. Some might ingest a file and then rehost it.

All those legal concerns are mitigated as soon as the podcaster agrees to the Terms and Conditions of a given service. Every podcaster submitting their show to a big directory agrees to some provisions like:

You grant us and our Affiliates the non-exclusive, royalty-free right to use, market, promote, advertise, display, transcribe, cache, transmit, distribute, make available (including via stream and download), sublicense and perform your Content, Artwork and Metadata, as applicable, in connection with the Services in each Country in the Territory for the duration of the Term.

[thebells1111]

@ryan-lingopods

I don't know about any legal stuff, but my hunch (which could land me in jail) is by having a <podcast:transcripts> or <podcast:chapters>tag in the podcaster's RSS feed, along with something like a 'community' attribute, the podcaster is giving permission for their work to be modified by the community. As long as the 'community' attribute was opt-in, which as far as I'm concerned, it should be, the presence of the attribute gives permission to use the API.

The other thing is, with the API, I see it as creating a standard of what to expect in the payload from the apps. The podcaster could use a service, or create their own RESTful backend to handle the payload. That way it's not necessarily controlled by any one entity, as anyone could spin up a serverless function or host their own server to handle the payload from the app, and do whatever they want with the community data. Since the podcaster has ultimate control of the the url <podcast:transcripts> and <podcast:chapters> point to, any changes to those files would be ultimately controlled by the podcaster or the service the podcaster is using to host his chapters and transcripts.

[thebells1111]

@nathangathright

Yeah, I think the podcaster should always have final say. Calling it Suggested Edits is more what I'm envisioning. It's a way for the community to help the podcaster out by marking spots in the episode and giving it a title (chapters) or correcting spelling in the transcript, but it's still up to the podcaster to decide what goes into the url. I can see a wiki definitely being one way to accomplish it, but the nice thing about having a protocol for an API anyone can host is there's probably several different solutions to how the community can edit and the podcaster can select.