Here’s a rough idea I’d appreciate feedback on.

One of the main principals behind podcasting is that the podcaster publishes an RSS feed detailing their most recent releases. At least that is the current model, with nearly all podcasters viewing their shows as a rolling series. Consider a different model, however, where a set of shows might need to be heard sequentially. This might be “Teach yourself Spanish in 24 hours” or a serialised novel or anything of that kind. Using a ‘most recent’ RSS feed would be like dipping into a series of 24 half way through – it just wouldn’t work.

For sequential podcasts a more controlled RSS feed is required to drip feed the shows in the right order, as and when they become available. Obviously the key to this is to personalise the RSS feed to the individual and keep track of their position in the sequence on the server side. The trouble arises in identifying the user.

If someone is discovering the podcast via the web, then offering a personalised feed is easy. At the simplest level a unique ID could be generated for every page load, thus ensuring the user has a unique feed address. More complex systems might require registration. This, however doesn’t address the great many users subscribing via one of the various podcast directories, or being passed the address manually by and friend and so on. Additionally, if a naive user manages to share their personalised feed address with others, the whole sequence will mess up spoiling everyone’s enjoyment.

What might be more useful is if the podcast aggregator (podcatcher) supported cookies. By setting a new cookie with a unique ID, or reading in an existing cookie for return users, the server could uniquely identify the user and therefore their position in the sequence.

This does, however, raise a few issues. Firstly it complicates the model. One of the really appealing aspects of podcasting is the simplicity of the model. Ultimately there must be some trade off between simplicity and more advanced functionality.

The second issue is that of course this would require support from the major podcatchers out there, of which there is an increasing number almost daily. However, we’re probably at a stage where something like this could be introduced without too much trouble. The format is young, and all the clients are under current development – there isn’t really any legacy stuff out there yet. From a programming point of view, adding a bit of HTTP manipulation is a little extra work, but hopefully wouldn’t be too onerous.

The third issue is one of portability, and it’s not one I have an answer for straight off. Cookies are ultimately tied to the user agent. If you download from multiple machines or decide to try out a different aggregator, the cookie data would not be ported. To enable the user to download from multiple machines, or change aggregators, there’d need to be some method of porting that data across or syncing up with an external service. That’s a whole different kettle of chips when it comes to programming effort, as well as user experience.

The final issue is that of privacy. It’s a social issue however, as cookies tend to get a bad press for little reason. People think they’re being tracked and that the world is out to get them and their nastyass data. Aggregators would need to employ a similar security model to that of standard browsers – with access to cookies limited by domain. As each feed would be managing its own cookies, there’s no cross contamination and so the privacy issue is moot. Of course it would be friendly to give the user the option to accept the cookie or reject it. Any such dialogue should be non-alarmist where possible.

So that’s the rough idea. I like the idea of cookies above authentication or any other such method as it’s already established technology and it also is non-specific. There could be a thousand different use cases that I’ve not dreamed of that cookies could be a solution to. I just wanted to get this out there for feedback.