Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion about 3rd party metadata #6

Open
Siebe opened this issue Oct 4, 2020 · 2 comments
Open

Discussion about 3rd party metadata #6

Siebe opened this issue Oct 4, 2020 · 2 comments

Comments

@Siebe
Copy link

Siebe commented Oct 4, 2020

To define 3rd party metadata: any data not created by a podcast owner (through rss feed) or by podcastindex itself (craw dates, update dates) that has information on the main data, namely the podcast feed and it's episodes.

@daveajones I'm sure you have had ideas and working on how to handle incoming metadata like:

  • reviews and ratings
  • info from source/media crawlers, timing bitrate
  • secure thumbnail/image mirrors
  • possible dupe feeds
  • donate links
    etc...

And perhaps you're already heading in a different direction.
But what were your thoughts about just an extra key/value table with namespaces? So a unique index could be namespace:feedId:key. You could by request connect API keys to a (single) namespace to give them write access. If any party needs access to multiple namespaces, they can use multiple API keys.

I'm not too sure though how to present the data in the API in a efficient way. It seems a good idea not to show any of this data by default, but only if a connecting service is aware that a certain namespace exists.

For popular searches and request on the metadata I'm sure @daveajones will whip up custom endpoints in no time.

My main concert, could the database handle it this way? I think it could provide a lot of flexibility.

@datamythology
Copy link

datamythology commented Dec 11, 2020

I am also interested in 3rd party data that connects to a feed. However, I assumed that would be something you or I or they would host themselves. You'd download/get access to the main podcast newsfeed so that you'd have the correct podcastID to point to, but you would host the "child" database yourself. Reviews, Ratings, etc.

Example would be how PodVerse hosts clips. https://podverse.fm/

While I like the idea of your dynamic namespace idea, wouldn't Dave ALSO have to somehow dynamically host this metadata you're talking about? Which doesn't seem possible.
Perhaps I'm reading your idea wrong -- would love to hear more.

Update: Looks like Episode #6 talks about the namespaces that ARE being added.

@perelin
Copy link

perelin commented Mar 24, 2024

Just found this. Any new discussion going on about that? I would be very interested especially in ratings/reviews metadata.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants