Lately I have been working on a possibly slightly "new" kind of interface to so-called feeds—one that refactors the hierarchical data model of RSS / Atom into a more explicitly relational model. Part of what I have been considering is how the "channel" concept in RSS / Atom is slanted towards a particular constraint on who (in the information chain) defines what a channel is.

Coincidentally, Jason Kottke, in observing how people commonly use RSS / Atom, is describing why he thinks we should probably stop calling it syndication. Ross Mayfield is also commenting on this in Ridiculously Easy Syndicate Forming. These are relevant to what I am working on, as I imagine re-asserting syndication (to borrow Ross' notation) as:

user <—> user <—> user
[where user = viewer / content (producer) / broadcaster]

So, I am thinking there are three types of channels in syndication models:

1. broadcaster -> viewer: the channel is the broadcaster's
2. (content) producer -> broadcaster: the channel is the producer's
3. viewer <- content: the channel is the viewer's

#1 and #2 correspond with, for example, TV stations broadcasting shows to viewers, and production studios producing shows to TV stations, respectively. I believe the data model in RSS / Atom is constrained to these two channel models.

At least some RSS / Atom readers, however, allow the user to combine different feeds into a single view. The "newspaper" view in Radio Userland is one example.

When the user combines different feeds, they are effectively defining their own channel: this is the what I mean by channel model #3. However, this combining is not itself in the RSS / Atom data model—it is something that can only be done outside of it (however, which can then be put back into RSS / Atom, of course).

In terms of the hierarchical model in RSS / Atom, the channel is defined like this:

channel 1 (e.g., broadcast or producer source 1)
  -item 1
  -item 2
  -item 3

What I see this as saying is that the items within the channel are meant to be constrained within it. And, this matches the needs of models #1 and #2. But, a structure matching model #3 could look more like this:

source 1 - item 1
source 2 - item 1
source 1 - item 2
source 3 - item 1

With this kind of format, the channel is designed for combining multiple sources. The user / viewer combination defines a channel into which information sources flow. (Of course, it is generally easy enough to refactor RSS / Atom into this kind-of format.)

But, I imagine this combining of multiple sources potentially being not just an end point (a client to servers) but more actively another router (peer) syndicating information on the network.