ISSN
farski opened this issue · comments
concerns about hijacking, but it would definitely be beneficial to have a feed identifier that could persist across URI changes.
I continue to be unconvinced, after having to implement this for RadioPublic. This seems like something that would need to be managed by a trusted third party.
I'm curious what problem this solves. Systems already have a unique ID and/or slug (see iTunes, e.g. https://itun.es/i6hn5x6) that's independent from the URI. Normal internet redirects handle the "resource moved" case.
@CharlesWiltgen RadioPublic is one such system that created a unique slug. You should not be using iTunes' because they are free to do whatever they want with it. I propose a trusted third party be set up as steward of these things which could act in a similar way to the way iTunes is doing things, but with guarantees about how long it will be useful etc.
It's useful to ensure that we are storing user data that refers to a feed in a way that it will easily be pointed at that feed in the future, even if the RSS url has changed. It also helps to canonicalize in situations (like FeedBurner) where multiple URLs all point at the same content, with no redirects.
RadioPublic is one such system that created such a unique slug.
Yeah, that's the point I was trying to make with "Systems already have a unique ID and/or slug". So @chrisrhoden, do you need this? Would you drop yours in favor of the feed's, in cases where they exist? If this addresses slugs, how would you handle two podcasts claiming the same slug? How would you handle potential abuse?
@CharlesWiltgen I would love to not be responsible for this, and for these IDs to exist in a way that is available across different apps - imagine being able to switch apps while keeping perfect track of heard / unheard episodes!
You could also share links to feeds or episodes that are guaranteed not to go stale.
I've also been thinking about this issue and having a centralised 3rd party keeping track of the id's doesn't really feel in line with the open/distributed thinking of rss. But it would my life a lot easier if I could tell which feeds are duplicates and which aren't.
Got one idea which might be slightly on the complicated side.. You could imagine some private/public-key where you sign the id of the podcast in combination with date and url. This way you can always tell which of two feeds with different url's being the most recent one and it shouldn't be an issue with hijacking feeds. It would be a simple public algorithm so anyone could implement a service/tool where you can validate or generate a signature. What do you think?
@markusahlstrand I've thought about doing the crypto route but it seems prone to never being implemented properly. The idea that people will keep their keys around seems unlikely to me, so it would likely need to be a combination of the crypto approach and the style of canonicalization that exists in apps now (following redirects, reading link and new-feed-url tags) which seems like it is going to get complicated quickly for all parties.
You could just use the public key fingerprint as the feed id and publish the public key and signature of the URL directly into the feed. I don't want perfect to be the enemy of good enough but I also wouldn't want to design a system that preserves the current possibility of highjacking subscriptions by purchasing a domain, so would likely need expiring signatures, which adds to the complexity.
Also (and @farski can confirm this from my time working with him at PRX) I'm usually the first to propose a crypto-based solution so thank you very much for doing it for me 😃
A trusted third party--or a trusted method--seems to be in line with W3C style-of-approach mentioned as inspiration by syndicated-media.
It seems like a trusted generator and authentication method would be more sustainable, in terms of upkeep. Encryption might not be the best solution, as it is meant to solve a different problem of masking content. If I'm understanding the problem correctly, it's more about correct ownership and authentication?
I hesitate to mention it, but when it comes to authentication, distributed ledgers with proof-of-work or similar proof-of-ownership methods seem to be more appropriate. That is assuming I'm understanding the issue correctly?
@cooganb a blockchain would work ok, but it has exactly the same problems as a crypto based solution and is several orders of magnitude more expensive to operate.
@cooganb Sorry I didn't notice this on my first read, but it seems like you're not quite understanding the crypto-based solution proposed here. Are you familiar with public key cryptography and the concept of cryptographic signatures? I don't think I am going to be able to do a good job of explaining those here, but there are lots of sources for learning about those on the Internet if not.
If you just misread, sorry for pointing you in that direction.
In this case crypto wouldn't be used encrypt the content, but rather to sign it to ensure that it's the right person publishing the data. My point with having a published algorithm is that anyone could put up a service (or you can do it locally) that generates the signed field required to validate the feed. The problem is as @chrisrhoden mentioned that it's easy to lose the keys to the kingdom..
Building a 3'rd party system wouldn't be technically challenging but who would that 3'rd party be? It's also a bit scary having a single point of failure for the podcasts of the world ;)
@cooganb it's a crypto solution because it relies on principles of cryptography. You are using asymmetric encryption to prove that you control a secret which is tied to a public identity.
the expense of maintaining a blockchain is the whole point of the notion of proof of work. It needs to be constantly calibrated to make it very hard to add something to the chain, requiring a bunch of work on the part of many computers. The more computers participating, the harder you have to make the problem.
I can explain why in more depth if you care, but basically the way block chains work is that they are a chain of blocks, and all clients agree that the longest chain is the true chain. If creating new blocks were easy, it would be easy to remove transactions and generate a new, longer chain that excluded those, so you would never be able to trust things that were already on the chain.
I think going further into what is and isn't cryptography and how block chains work may be best saved for other channels.
Suffice to say, I don't think a blockchain is remotely necessary in this case since we are already relying, at a minimum, on DNS. Most of what would be gained by a block chain is complicated by the fact that it would necessarily be interfaced (unless you're suggesting running a full chain on every client), and the whole reason to avoid using straight public/private key pairs to authenticate is that it's potentially too complicated for the vast majority of publishers (and they'd need to keep their keys for it to work properly) which is as bad or worse with a block chain.
@cooganb no toes stepped on at all! I'm happy to talk about this further I just found myself getting a little in the weeds which I don't think is appropriate here for others to be able to read.
I'm not aware of other non proof of work propsals that work in a trustless environment, so if you would be willing to share with me I would love to read more. My email is on my github profile.