person tag improvements #662
Replies: 6 comments 18 replies
-
|
This is the subject of a piece today by the Podcast Standards Project - https://podstandards.org/2024/09/25/podcast-standards-meeting-in-washington-dc/ - though I'm led to believe there's been no further thinking on it other than this piece. Another potential option is Gravatar, a web-scale open project. The benefits of Gravatar are "secondary emails" - so james@podnews.net is the same as james@cridland.net - and it offers images and social media links as standard. Yes, it's a centralised tool, owned by Automattic, but it, at least, seems relatively sincere in its openness. It uses email hashes, has a lot of open libraries, and seems well adopted by many different services out there. I think email makes the most sense here - not least, podcast hosting companies, and podcasters themselves, would all know the email addresses of their guests. Two other things to bear in mind: |
Beta Was this translation helpful? Give feedback.
-
|
It's just a SHA256 hash of an email address. (SHA256 is one-way). https://gravatar.com/ec12a8db5c01106564ee6cd4f2a06e0a7dd2dd22d3c090390877ba65080196e8 is me. There's a fully-featured API to return my details (which I have control over). https://gravatar.com/0c8515e57e236c578e565e82f8ae7c1023fe6ee6072ec2fd7adde24530f3f8df is you. And you haven't registered at Gravatar. But that's still fine - it's still a unique ID. https://gravatar.com/avatar/ec12a8db5c01106564ee6cd4f2a06e0a7dd2dd22d3c090390877ba65080196e8 is my avatar. It seems that a simple SHA256 hash of an email address would give compatibility with Gravatar if apps wished to integrate; and no harm if not. |
Beta Was this translation helpful? Give feedback.
-
|
Can I ask how you generated those links? Is there a library that you used? |
Beta Was this translation helpful? Give feedback.
-
|
sha256 is probably built into any programming language you'll use. But in my case, because I'm lazy, I just typed "SHA256 encoder" into a search engine and used the first one. |
Beta Was this translation helpful? Give feedback.
-
|
there is only one small issue if you give your secondary email to a podcaster they wont get the same HASH as the primary. Maybe since we know that james@podnews.net is not primary but we can tell podnews.net we can check your podnews podcast to get your valid PID. But that adds a lot more complexity into it. Also Gravatar does say if you login to their system with the secondary email it will generate a new profile for you. I am sure there been people that have done that. (https://support.gravatar.com/profiles/multiple-emails/) |
Beta Was this translation helpful? Give feedback.
-
Automatic is in the middle of a big controversy where they cut off access to their plugin repo to a hosting company they want to pay them licensing fees. Customers are unable to add or update plugins through their wordpress sites as a result. |
Beta Was this translation helpful? Give feedback.
-
|
I don't know how much guests would love their personal email addresses being added to databases of shows they've been on, even if it's hashed out in the rss feed. |
Beta Was this translation helpful? Give feedback.
-
|
If we use what @jamescridland said sha256 which is one way encryption then no one will be able to decrypt it unless they know the email address. Yes we could start a global database and have a centralised server, but then we would be creating a UID2 server and people are against that idea because it has been proposed to use that system for advertising. UID2 is a good system that can be used for more than just advertising and marketing. |
Beta Was this translation helpful? Give feedback.
-
|
Should add we don't ever publish the hash data. |
Beta Was this translation helpful? Give feedback.
-
|
Check out using wikidata for shared hrefs for people: https://m.wikidata.org/wiki/Q349039 |
Beta Was this translation helpful? Give feedback.
-
I've always had issues adding new wiki (on Wikipedia) also hosts are not going to integrate with wiki data at least not straight away. HREF is not a good identifier. |
Beta Was this translation helpful? Give feedback.
-
|
Chiming in late, but as @jamescridland mentioned, this topic also came up during our latest Podcast Standard Project meeting. There’s clearly a strong interest in creating a PID (as @redimongo calls it) or a “Person GUID” (inspired by podcast:GUID). Calculating this Person GUID programmatically is a great approach: no reliance on third-party services, and it’s relatively straightforward to implement, much like podcast:GUID. Using the email address as the basis for the Person GUID seems like a solid option. For security and privacy, SHA256 is a strong candidate since it cannot be reverse engineered, as noted earlier. But, if we want to maintain consistency with how podcast:GUID is calculated, we could opt for UUIDv5, using the email and the In a nutshell, we all seem to agree on the value of having a "Person GUID". My preference / proposal is to use the full email address (without removing variants like +) as input and generate the GUID with UUIDv5 and the |
Beta Was this translation helpful? Give feedback.
-
I think we all seem to agree on the value of having a unique identifier for a person. But I'm not convinced on a central GUID. I don't really see why this can't be an href URI as it currently is. A link to https://podid.com/jamescridland is a unique identifier. So is https://rss.com/user/jamescridland as long as I use it consistently. Using the existing URI schema means:
Additionally, using the existing URI with a I would much rather have one that is run by my podcast host, and I suspect any podcast host would like that too. |
Beta Was this translation helpful? Give feedback.
-
|
I think my only concern with that method would be that if the person changes their url they use, they then need to notify everyone it's changed and then podcasters would need to change all instances of it. Easiest way to facilitate that might be hosting platforms would need to have their own internal person database to propagate that change across all podcasts hosted with them. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. Just like email or URLs, if you change it, it's a right pain (though I'd suggest that people change their email addresses too). At least there is the possibility for a 301 redirect from my old ID to a new one, I guess. The benefit of using SHA256 hashes is that they are currently used by Gravatar, and therefore there is the potential of using that service to grab images and other elements. |
Beta Was this translation helpful? Give feedback.
-
|
So I'll post examples later but PodId.org doesn't require anyone to change anything. We will offer an API that can do sha256 look ups of every person Href as it currently stands. Then you just send another API call to fetch all podcasts that that person has been on. I would love for people to change their Href to a PodID URL or for podcast hosting companies to let people put a "real" Href I have noticed that some podcast hosting companies generate the Href for a person and link it to their platform. Am just on my way to the hospital now, so that's why I can't show the example in this post. However we have the API ready for lookups based on everyone's current implementation of Href in person tag. Note we don't store data if a person hasn't signup to PodID.org I personally want this platform to be free for podcasters and guests to use. If I can keep the API free to access as well I will (it comes down to costs to run the service). Also @jamescridland said it correctly the issue isn't if the podcaster uses your Href correctly as it's your own show. It's whether when you're a guest on another show do they do it correctly and do they use the person tag? PodID.org can match you even if the podcaster didn't use the person tag and didn't use the correct Href. |
Beta Was this translation helpful? Give feedback.
-
|
As promised here is how PodID.org can be used without needing to change any Href that already exist in the wild. What we do is when a user signs up for a PodID we ask them some questions from websites, social media accounts and all their emails addresses. We hash all of this information as @jamescridland has suggested in SHA256 for example This means using PodID.org an app can look up for my social media account handle using that hash (or the raw This will return Then if you want to find out all the podcasts I have been on either as a guest , co-host or host just query https://podid.org/api/v1/podidLookup?podid=xy6a79ra This will return At the moment it's a little messy, and we will make it a little neater but that is a proof of concept. What about Websites like say I have https://podtoo.com as my Href because a website might have multiple staff members (like PodNews.net) we do something super special as it will list everyone that has put that as their website address. https://podid.org/api/v1/search?query=https://podtoo.com&type=website It will return Note we will add the ability to send the full name as well and then it will only return one result. (Remove spaces and add + for each space.) This way we can hash it on our end and do the verifications that we need to at PodID. Unlike Gravatar PodID allows a person to link any number of Href to their account all searchable to the public via sha256, so if someone links to my X (twitter) profile instead of say my linkedin, PodID can still match me and say - That was Russell Harrower on that podcast. This is designed to helps apps that want an Apple host feature where you can click on a picture of a person and show query podcast that person has been apart of. |
Beta Was this translation helpful? Give feedback.
-
|
Note that the issue isn't with the podcasters who host their own podcast and fill out their own Href, it's mainly an issue when you are a guest and someone might not use or set the Href in their podcast hosting provider this is when we get multiple Href URLs for a person. There up til now has not been an easy way to link all of these together.
The issue I see is, say I am a guest and I host on PodToo but then I come onto Podnews podcast who hosts on Buzzsprout. I am hoping that Podnews uses my Href that I want used. Some hosting companies just create an internal person href and don't ask the creator of the podcast where a contacts href should point to (also this can be confusing/hard to understand for some Podcast beginners). I thought how can we solve this without changing anyone's current integration of Href, easiest way I found was to make a index of every podcast person Href linked to a person. But the issue then became some podcasts don't use the person tag so how can we find them and we can it just takes spidering and crawling the transcripts etc. The issue then becomes if Buzzsprout has there own PodID system then but I use PodToo and someone else uses RSS.com how can all of these talk together without creating a global ID (GUID). Should just add that names scanning is not a fun task as John Ball is also The John Ball Zoo, so we had to add a tool to scan and determine if the description + transcript is referencing a person or a place. |
Beta Was this translation helpful? Give feedback.
-
Just an example of Danny Brown who has been a host, co-host and a guest co-host
|
Beta Was this translation helpful? Give feedback.
-
Then we should go after those podcast companies, because that doesn't follow the spec. FYI - here's the experience in Buzzsprout |
Beta Was this translation helpful? Give feedback.
-
Agreed. Even a "mailto://" link is a valid url that can be used if they have nothing else. Lots of options for valid hrefs for almost everyone. |
Beta Was this translation helpful? Give feedback.
-
|
I no longer believe we need to modify the person tag, and actually, PodID doesn’t need it at all to determine whether you're a host, co-host, guest, or mention. Soon, we’ll be rolling out our transcription-to-person matching system! Could the person tag be improved? Maybe. But PodID can now figure all this out just based on the transcript. PodID will only use the person tag as a backup, or if transcripts aren’t available. Just to clarify—this isn’t AI! I coded all of this myself in about 8 hours. The goal now is to get podcast apps to use this data to show which shows a person has been on as a host, co-host, guest, or mention, and allow listeners to follow creators or guests to discover more content by them. Imagine a playlist of every podcast @daveajones has been on (I’d definitely listen to that!) or every interview @jamescridland has done (which would be amazing). Additionally, PodToo will use this database, like Dave mentioned, to link to a person’s Href that they’ve registered with PodID (like a lookup system). I really hope other hosting providers and services will start using it too. Together, we can make podcasts more about community and help listeners discover new shows that their favorite creators have appeared on. |
Beta Was this translation helpful? Give feedback.
-
|
I know I'm coming to this late, but after being on Podcasting 2.0 last week, I think I see how these pieces can fit together. Right now, But some audiences will want to tap on that person and get other podcasts with which they've been involved. That's where the tag in its current iteration fails. The only way for a podcast app to crossreference other podcasts with the same credit(s) is to have scrapped the person tag from all other feeds and episodes. And that's where I think @redimongo's idea is leading to a solution. Here's my proposal: add an additional attribute to the "person" tag to link out to structured data the podcaster controls to list all their other credits. PodID can be such a provider, or the podcaster can maintain it themselves. This would give apps the ability to easily link out to all the other podcasts and episodes on which that person is listed in its credits. It would give those people an opportunity to list and control their complete list of credits (as well as having separate lists for potential privacy or relevance concerns). And it gives audiences the opportunity to engage more with that person's other involvements. Here's a potential JSON format of that data: {
"name": "Daniel J. Lewis",
"href": "https://theaudacitytopodcast.com/",
"img": "image_url_here",
"webView": "https://podid.org/thedanieljlewis",
"credits": [
{
"podcastGuid": "…",
"href": "https://theaudacitytopodcast.com",
"roles": ["Host"]
}, {
"podcastGuid": "…",
"href": "https://futureofpodcasting.net",
"roles": ["Cohost"]
},
{
"podcastGuid": "…",
"href": "https://eofire.com/549",
"roles": ["Guest"],
"episodeGuid": "…"
},
{
"podcastGuid": "…",
"href": "https://schoolofpodcasting.com/all-about-podgagement",
"roles": ["Guest"],
"episodeGuid": "…"
}
]
}Note that This data could be built and hosted by a geek podcaster themselves, their hosting provider, or third-party tools like PodID or Podchaser. All we would need to do link to this JSON from the person tag. Perhaps the attribute would be What does everyone think? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
** UPDATE ** see #662 (comment)
While the
<podcast:person>tag is a great tag to have it is missing key requirements that make it a valuable tag for podcast players and applications to match a podcast guest or host with other podcasts that they have featured on.ISSUE
The current person tag documentation does not allow for a podcast hosting company to link an PID (person ID) or socialInteract / social to a person, this means that podcast players may unknowingly say that Russell featured on Y Podcast because the persons name matched other documents in that podcast player, when Russell did not feature on Y podcast.
This here is the current standard as documented
Examples
SOLUTION
Fields I think we should adopt, as these fields would allow us to make sure that players who are showing shows that for example Russell featured on would be able to look up the PID for a match. I would recommend the UID2 standard as a person may use russell+mypod@gmail.com but we know you can add anything after + and gmail will send it to russell@gmail.com. So by using that UID2 suggestion we would remove anything after + and the email HASH would be russell@gmail.com
PID (personID)
We can base this off of the persons email address as most guests will supply the same email address to multiple shows and hopefully podcasts hosting providers have a way for a person to manage their guests in the hosting system. to be secure I would recommend hashing with simular technology like UID2 (note we don't need to send it to a master server to hash correctly - we just need a standard MD5 or something like that (which needs to be standard for this on a global scale))
socialInteract or socials
To make this easy, I was thinking we could base it off of the chapter tag how it links to a JSON file, inside this file for this person could be all their social networks. Best of all because we match it with the PID a player can verify and update if changes are made across any podcast network.
Beta Was this translation helpful? Give feedback.
All reactions