4 ms·

Show HN: Loud – Podcast-first feed syndication protocol

7 points by 0des 5y ago

mdaniel 5y ago
> AvatarURL string > Square show avatar, recommended 2000x2000px minimum size, 1:1 aspect ratio A 2000 pixel minimum, huh? It's also a bit weird that the yaml keys are all lowercase but the other two formats are camel cased As far as the spec goes: You will want to be cautious using string for everything and then trying to define the payload using natural language. Let's take "EpisodeHost []string - List of episode hosts" as a concrete example. Is it their name, email, URL to their IMDb page, does it support html, or (worst case from the perspective of a podcast client implementator) "it depends on the network"? When a field in a spec is string and "do whatever you want", without fail one will find a chocolate chip recipe and an XSS possibly in the same file In that same vein, the fact that FeedURL is singluar but the feed has 3 media types implies that the return type is either negotiated by an Accept header, is chosen by the network provider, or random. That means as a client implementator, I have to immediately support all three parsers with parity out of the gate because I have no means to choose what bytes are sent back. Speaking of bytes, presumably the spec makes the assumption that the file itself is UTF-8 but assumption and standard are at odds with one another I would be surprised if one couldn't extend the Atom spec with these concepts, but I guess the intro section saying it was designed to be more experimental implies that wasn't a consideration
- 0des 5y ago
  Thanks for commenting, this is the exact type of critical analysis and collaboration that was being sought in posting here. > It's also a bit weird that the yaml keys are all lowercase but the other two formats are camel cased That's a good catch, it makes sense that they should match. > You will want to be cautious using string for everything and then trying to define the payload using natural language. Let's take "EpisodeHost []string - List of episode hosts" as a concrete example. Is it their name, email, URL to their IMDb page, does it support html, or (worst case from the perspective of a podcast client implementator) "it depends on the network"? When a field in a spec is string and "do whatever you want", without fail one will find a chocolate chip recipe and an XSS possibly in the same file This is something that is being considered on this end: how do we go about enforcing valid input in each of the fields. In RSS [0] and Atom [1] feeds, it is common to see a mixture of plaintext as well as HTML, depending on which feed you are looking at, and it is up to the parser to present it correctly or whether to render it at all. The "render if desired" quality of the fields seems to be the right mixture of portability for now, but that may change as the protocol is young and implementations are few. One is being worked on, in the form of Loudreader, a CLI feed reader with subscriptions for LOUD. > In that same vein, the fact that FeedURL is singluar but the feed has 3 media types implies that the return type is either negotiated by an Accept header, is chosen by the network provider, or random. That means as a client implementator, I have to immediately support all three parsers with parity out of the gate because I have no means to choose what bytes are sent back. Initially, there was some concern about this and early "builds" of LOUD started out as all JSON, because what you said makes sense, that the dev implementing the client would be prompted to support all 3 in parity to fully support the range of formats that the feed can be presented in. While it is initially slightly more work for someone wanting to implement "the whole protocol", by supporting all 3, it shouldn't be a limiting factor in this day and age when the differences between these formats are so trivial in each language. So far, the biggest difference is a minor complaint that Golang doesnt have a .Valid() for XML or Yaml, which is a personal issue currently. Keep an eye out, this could change, potentially. What are your opinions on this, JSON only soon? > Speaking of bytes, presumably the spec makes the assumption that the file itself is UTF-8 but assumption and standard are at odds with one another Good catch, this wasn't even considered, but will be now that it is mentioned. > I would be surprised if one couldn't extend the Atom spec with these concepts, but I guess the intro section saying it was designed to be more experimental implies that wasn't a consideration This is correct. It is the personal opinion of this developer that without first being part of the legacy Atom community and ingratiating oneself to the nuances behind its current form that "kicking open the door" with hands pressed on hips might be a path of resistance to adoption of the LOUD protocol concept, and would risk the ability to have a holistic realization of the entire spec as it was envisioned. It seemed more polite to create something new. If Atom finds this work beneficial, it would be the highest honor to have any part of it included in any forthcoming revisions to their protocol. [0] - https://cyber.harvard.edu/rss/encodingDescriptions.html https://cyber.harvard.edu/rss/encodingDescriptions.html [1] - https://datatracker.ietf.org/doc/html/rfc4287#section-8.1 https://datatracker.ietf.org/doc/html/rfc4287#section-8.1
zzo38computer 5y ago
Which keys are mandatory and which are optional? I think that the pictures, long descriptions, web page URLs, and possibly some others, should be optional. It might only be a podcast and not a web site. Maybe the FeedURL should also be optional in some blocks; if a LOUD feed program downloads it, and possibly extracts it from the full feed, then it can fill it in if it is omitted. Also, you might want to allow floating numbers for time rather than being limited to integers, since the duration might not be an integer number of seconds. Also, for the list of audio files you might want some way to include the information about quality and file format, as well as to specify the file formats, character encodings, and languages of transcriptions. Again, like the other comment mentions, there will need more description of the formats of some of the string values. The examples help a bit, but examples are not good enough; a proper specification should be needed. Other thing mention in other comments also are issues with this format. I think it isn't good enough, for those and other reasons.
- 0des 5y ago
  Thanks for taking a moment to review the spec > Which keys are mandatory and which are optional? I think that the pictures, long descriptions, web page URLs, and possibly some others, should be optional. It might only be a podcast and not a web site. Maybe the FeedURL should also be optional in some blocks; if a LOUD feed program downloads it, and possibly extracts it from the full feed, then it can fill it in if it is omitted. Optional and required is something that until now had not been considered, but it will be. This is an important point. Thank you. What was meant by "then it can fill it in if it is omitted" this is the only part that was unclear. > Also, you might want to allow floating numbers for time rather than being limited to integers, since the duration might not be an integer number of seconds. Can you elaborate on this? Do you mean a granular measurement more exact than the span of a second? For some context, the reason why it is a number of seconds, currently, is because of the way you can link to a specific timestamp in URLs for audio files using the #t=NNN format, and it works for the most part regardless of which browser clicks the link. This is used in the current implementation of loudreader, a CLI LOUD feed reader with subscriptions. [0] > Also, for the list of audio files you might want some way to include the information about quality and file format, as well as to specify the file formats, character encodings, and languages of transcriptions. This is a good suggestion, thank you. > Again, like the other comment mentions, there will need more description of the formats of some of the string values. The examples help a bit, but examples are not good enough; a proper specification should be needed. This is the part where the most help is needed. All roads point to the need for a formalized spec. That area, or process, is the least familiar unfortunately, though contacts have been made with regard to pursuing this: Jamie Zawinski advised, when asked candidly about the process of making LOUD a standardized spec, that "it's a multi-year process that involves collaborating with a lot of people." which can't be ignored. Currently, the time for that pursuit isn't there, but that's not to say that can't change, which is a big reason behind the MIT license. This is something that is needed, and it can be awesome, but it will take more than 1 person leading the charge, which currently is all that is available. > Other thing mention in other comments also are issues with this format. I think it isn't good enough, for those and other reasons. Thank you for this feedback [0] - https://github.com/loud-feed-format/loudreader https://github.com/loud-feed-format/loudreader

7 points by 0des 5y ago

> AvatarURL string > Square show avatar, recommended 2000x2000px minimum size, 1:1 aspect ratio A 2000 pixel minimum, huh? It's also a bit weird that the yaml keys are all lowercase but the other two formats are camel cased As far as the spec goes: You will want to be cautious using string for everything and then trying to define the payload using natural language. Let's take "EpisodeHost []string - List of episode hosts" as a concrete example. Is it their name, email, URL to their IMDb page, does it support html, or (worst case from the perspective of a podcast client implementator) "it depends on the network"? When a field in a spec is string and "do whatever you want", without fail one will find a chocolate chip recipe and an XSS possibly in the same file In that same vein, the fact that FeedURL is singluar but the feed has 3 media types implies that the return type is either negotiated by an Accept header, is chosen by the network provider, or random. That means as a client implementator, I have to immediately support all three parsers with parity out of the gate because I have no means to choose what bytes are sent back. Speaking of bytes, presumably the spec makes the assumption that the file itself is UTF-8 but assumption and standard are at odds with one another I would be surprised if one couldn't extend the Atom spec with these concepts, but I guess the intro section saying it was designed to be more experimental implies that wasn't a consideration

0des 5y ago
Thanks for commenting, this is the exact type of critical analysis and collaboration that was being sought in posting here. > It's also a bit weird that the yaml keys are all lowercase but the other two formats are camel cased That's a good catch, it makes sense that they should match. > You will want to be cautious using string for everything and then trying to define the payload using natural language. Let's take "EpisodeHost []string - List of episode hosts" as a concrete example. Is it their name, email, URL to their IMDb page, does it support html, or (worst case from the perspective of a podcast client implementator) "it depends on the network"? When a field in a spec is string and "do whatever you want", without fail one will find a chocolate chip recipe and an XSS possibly in the same file This is something that is being considered on this end: how do we go about enforcing valid input in each of the fields. In RSS [0] and Atom [1] feeds, it is common to see a mixture of plaintext as well as HTML, depending on which feed you are looking at, and it is up to the parser to present it correctly or whether to render it at all. The "render if desired" quality of the fields seems to be the right mixture of portability for now, but that may change as the protocol is young and implementations are few. One is being worked on, in the form of Loudreader, a CLI feed reader with subscriptions for LOUD. > In that same vein, the fact that FeedURL is singluar but the feed has 3 media types implies that the return type is either negotiated by an Accept header, is chosen by the network provider, or random. That means as a client implementator, I have to immediately support all three parsers with parity out of the gate because I have no means to choose what bytes are sent back. Initially, there was some concern about this and early "builds" of LOUD started out as all JSON, because what you said makes sense, that the dev implementing the client would be prompted to support all 3 in parity to fully support the range of formats that the feed can be presented in. While it is initially slightly more work for someone wanting to implement "the whole protocol", by supporting all 3, it shouldn't be a limiting factor in this day and age when the differences between these formats are so trivial in each language. So far, the biggest difference is a minor complaint that Golang doesnt have a .Valid() for XML or Yaml, which is a personal issue currently. Keep an eye out, this could change, potentially. What are your opinions on this, JSON only soon? > Speaking of bytes, presumably the spec makes the assumption that the file itself is UTF-8 but assumption and standard are at odds with one another Good catch, this wasn't even considered, but will be now that it is mentioned. > I would be surprised if one couldn't extend the Atom spec with these concepts, but I guess the intro section saying it was designed to be more experimental implies that wasn't a consideration This is correct. It is the personal opinion of this developer that without first being part of the legacy Atom community and ingratiating oneself to the nuances behind its current form that "kicking open the door" with hands pressed on hips might be a path of resistance to adoption of the LOUD protocol concept, and would risk the ability to have a holistic realization of the entire spec as it was envisioned. It seemed more polite to create something new. If Atom finds this work beneficial, it would be the highest honor to have any part of it included in any forthcoming revisions to their protocol. [0] - https://cyber.harvard.edu/rss/encodingDescriptions.html https://cyber.harvard.edu/rss/encodingDescriptions.html [1] - https://datatracker.ietf.org/doc/html/rfc4287#section-8.1 https://datatracker.ietf.org/doc/html/rfc4287#section-8.1

zzo38computer 5y ago

Which keys are mandatory and which are optional? I think that the pictures, long descriptions, web page URLs, and possibly some others, should be optional. It might only be a podcast and not a web site. Maybe the FeedURL should also be optional in some blocks; if a LOUD feed program downloads it, and possibly extracts it from the full feed, then it can fill it in if it is omitted. Also, you might want to allow floating numbers for time rather than being limited to integers, since the duration might not be an integer number of seconds. Also, for the list of audio files you might want some way to include the information about quality and file format, as well as to specify the file formats, character encodings, and languages of transcriptions. Again, like the other comment mentions, there will need more description of the formats of some of the string values. The examples help a bit, but examples are not good enough; a proper specification should be needed. Other thing mention in other comments also are issues with this format. I think it isn't good enough, for those and other reasons.

0des 5y ago
Thanks for taking a moment to review the spec > Which keys are mandatory and which are optional? I think that the pictures, long descriptions, web page URLs, and possibly some others, should be optional. It might only be a podcast and not a web site. Maybe the FeedURL should also be optional in some blocks; if a LOUD feed program downloads it, and possibly extracts it from the full feed, then it can fill it in if it is omitted. Optional and required is something that until now had not been considered, but it will be. This is an important point. Thank you. What was meant by "then it can fill it in if it is omitted" this is the only part that was unclear. > Also, you might want to allow floating numbers for time rather than being limited to integers, since the duration might not be an integer number of seconds. Can you elaborate on this? Do you mean a granular measurement more exact than the span of a second? For some context, the reason why it is a number of seconds, currently, is because of the way you can link to a specific timestamp in URLs for audio files using the #t=NNN format, and it works for the most part regardless of which browser clicks the link. This is used in the current implementation of loudreader, a CLI LOUD feed reader with subscriptions. [0] > Also, for the list of audio files you might want some way to include the information about quality and file format, as well as to specify the file formats, character encodings, and languages of transcriptions. This is a good suggestion, thank you. > Again, like the other comment mentions, there will need more description of the formats of some of the string values. The examples help a bit, but examples are not good enough; a proper specification should be needed. This is the part where the most help is needed. All roads point to the need for a formalized spec. That area, or process, is the least familiar unfortunately, though contacts have been made with regard to pursuing this: Jamie Zawinski advised, when asked candidly about the process of making LOUD a standardized spec, that "it's a multi-year process that involves collaborating with a lot of people." which can't be ignored. Currently, the time for that pursuit isn't there, but that's not to say that can't change, which is a big reason behind the MIT license. This is something that is needed, and it can be awesome, but it will take more than 1 person leading the charge, which currently is all that is available. > Other thing mention in other comments also are issues with this format. I think it isn't good enough, for those and other reasons. Thank you for this feedback [0] - https://github.com/loud-feed-format/loudreader https://github.com/loud-feed-format/loudreader