syndicated-media / sn-spec

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Networks

farski opened this issue · comments

There should be some verifiable (by the client) way of a feed indicating that it belongs to a network, which also has other members (which are feeds)

This could be like #28 but with different types.

In Atom this would be done like

<link href="https://example.org/network.opml" rel="network" type="application/opml+xml" />
<link href="https://example.org/recommended.opml" rel="recommended" type="application/opml+xml" />

however the rel may have to be different to avoid collisions.

In RSS, this might look something like:

<rss>
    <sm:feeds>
        <sm:network>
            <sm:networkName>Example Podcast Network</sm:networkName>
            <sm:networkLink>http://example.org/</sm:networkLink>
            <sm:networkShows type="application/opml" href="http://example.org/shows.opml" />
        </sm:network>
    </sm:feeds>
    <channel>
        (…stuff…)
    </channel>
</rss>

It makes more sense to me not being a child of <channel>, since it's not a channel/show/podcast property per se. This assumes that the way I'm reading the RSS spec is correct — the spec says that <rss> must contain exactly one <channel>, but doesn't say that it must only contain <channel>.

I think channel is spiritually the thing representing the podcast in a feed document, and going outside it is a slippery slope. Also I'm not sure it's correct to say network isn't a property of the show. Show X belongs to network Y is a valid description, so it feels like a property, even though the network would exist with the show (in the same way the author/owner does)

@Cj-Malone I think this works, I like the idea of using the link tag as much as is reasonable and this seems like a reasonable use of it.

Verifiability is hard, but I think it's worth really thinking through. What level of verifiability would we want, in this model? I can think of a few depths:

  1. We fetch the OPML, and treat all of the referenced feeds as related in some way.
  2. We fetch the OPML, confirm that it contains the pointing feed, and then consider the referenced feeds to be related.
  3. We fetch the OPML, confirm that it contains the pointing feed and that all feeds that it points to point back at the OPML, and then consider it a network.

Option 3 seems like the only one that isn't open for abuse, (e.g. I am going to form a "network" of which I am a member and so is Serial!) but it also seems like it might be asking a little much of the client. Presumably you could do it lazily but the amount of state we are then asking clients to keep track of might get onerous.

Is this related to the concept of, more generally, related programs? We have been experimenting with this (though it wouldn't be used to e.g. render out a network within the app, but as far as I am concerned any show can feel free to put links to other programs on their own show as long as the app doesn't artificially reciprocate)

Also I'm not sure it's correct to say network isn't a property of the show.

Me either — I'm just drawing so the sketch can be critiqued. 🙂 My argument for this not being part of <channel> is that network metadata seems more like context for the channel, vs. a property of the channel.

Is this related to the concept of, more generally, related programs?

I think so. I wrapped this in a parent element for that reason, and so related lists might look something like:

<sm:feeds>
    <sm:network>
        <sm:networkName>Example Podcast Network</sm:networkName>
        <sm:networkLink>http://example.org/</sm:networkLink>
        <sm:networkShows type="application/opml" href="http://example.org/network.opml" />
    </sm:network>
    <sm:lists>
        <sm:list>
            <sm:listName>Other cool true-crime podcasts</sm:networkName>
            <sm:listShows type="application/opml" href="http://example.org/true-crime.opml" />
        </sm:list>
        <sm:list>
            <sm:listName>More podcasts hosted by women</sm:networkName>
            <sm:listShows type="application/opml" href="http://example.org/women-hosts.opml" />
        </sm:list>
    </sm:lists>
</sm:feeds>

Those lists probably need images as well.

I disagree about this being in the same vein as related programs. There should be a way to indicate the network simply as a matter of "who owns this". Whether that means the show is related to other shows doesn't really matter. Friends is not related to the NBC Nightly News because they belong to the same network, except for the fact that they belong to the same network.

There should be a way to indicate the network simply as a matter of "who owns this".

I like @chrisrhoden's Option 3 for that, since otherwise the potential for abuse (or more likely, non-adoption) is high.