FeedDemon and the feed:// protocol

Among the additions in FeedDemon 1.10 is support for the feed protocol for hassle-free feed subscription. This new protocol simply involves using feed:// rather than http:// for feed URLs.

Now, I know some aren't happy with the existence of this new pseudo-protocol, but let's face it: subscribing to feeds is a huge pain right now and it's causing far too much confusion. Feed reading has left the phase where only techies do it, so relying on orange XML and RSS buttons that spew XML when clicked just doesn't cut it.

The feed protocol aims to simplify this mess so that clicking on a feed:// link enables quick subscription via the user's feed reader. I'm hoping more applications - and more web sites - support this protocol so that we can put the days of subscribing by URL copy/pasting behind us.

PS: Yes, I know we should be able to rely on MIME types for all of this, but MIME types don't work.

Comments

[Stefano F Rausch]

Here are my 2 cents:

It sounds very plausible to support the feed:// protocol. For my part I will give it a chance and time will tell ;)

[Paul Mayne]

In the meantime, are there any good extentions for FireFox to right-click and add to FeedDemon? I remember seeing one a while back, but I could never get it to work right.

[Stefano F Rausch]

I just have added feed:// to my blog and it works like a charm. When will the addfeed command (with the parameters title and img) be supported by FeedDemon?

[Stefano F Rausch]

Correction: in my previous post the second parameter for the command addfeed must be "image" instead of "img".

BTW, FeedDemon supports all of the following schemes:
- feed:[/]
- feed:http://[/]
- feed://[/]
- feed://http://[/]

[anders]

i agree that the current copy/paste approach to feed subscription will not cut it with non-technical users (and isn't even that hot for us technical users), but i guess i have to count myself among those who feel that yet another pseudo-protocol is a bad idea.

the problem that i have with the 'feed://' protocol is that it can potentially make things *more* difficult for users at least in the short term. if sites start using it, but a user's aggregator doesn't support the protocol, then copy+paste turns into copy, paste, wonder why their aggregator gives them an error, and finally manually edit the feed url to put 'http://' back in.

my vision of how feed subscription work involves a little more browser + reader integration and better use of auto-detection. when the web-browser sees a page with a link rel="alternate" type="application/rss+xml" ... type element in the head, a little 'subscribe' button should appear (maybe in the status bar next to where the 'secure' padlock shows up, or where mozilla puts the icon notifying you that it's blocked a popup). clicking on that button will subscribe to the feed (if there are multiple feeds in the head, it would give the user a dialog to let them pick which one(s) to subscribe to).

that would involve no copy/paste, would be about as easy on the user as it gets, could be implemented relatively easily (at least for firefox), and wouldn't involve introducing a new pseudo-protocol.

[neozen]

i was kind of at feed://'s side, but now i must say anders has a really good point.

[Nick Bradbury]

Anders, when you browse in FeedDemon, it works just as you suggest. Feed links in the page being browsed are auto-detected, resulting in an icon in the status bar which enables easy subscription.

But auto-discovery doesn't enable you to simply click a link to subscribe to a feed - that's the big missing piece here.

Plus, what you describe would require every feed reader to integrate with every browser, which in practice would be a mess. I can't imagine any developer choosing to write code for every browser rather than support a simple protocol (we're talking a few minutes work here).

[anders]

if auto-discovery were properly supported, clicking on a link wouldn't be necessary. in my fantasy world, people wouldn't have user-clickable links to feeds period. the only time a feed url would appear would be in a link element and the browser's UI would handle everything else. if there is a good use-case for users clicking on links in web pages to subscribe to feeds, i think it should still be implemented using a browser extension but make use of something like a rel="subscribe" attribute that the extension would then pick up on (ie, similar to how XFN is designed).

you wouldn't necessarily have to have every feed reader integrate directly with every browser; that would be a nightmare, i agree. i imagine that an extension is written for each browser that handles the auto-discovery of feeds and all the UI for subscribing. then there would be a standard protocol that the browser extensions would use to talk to aggregators and tell them that the user wants to subscribe to a feed. each aggregator would then just implement that protocol. i haven't put too much thought yet into how that protocol would be implemented, but it shouldn't be very complicated.

so the total number of pieces of code that need to be written would be num_browsers + num_aggregators instead of num_browsers * num_aggregators. something has to be written for every aggregator no matter what method is used. the question is whether num_browsers is really huge or not? i don't think it is. writing an extension for firefox and IE6 would probably cover about 90% of users.

i want to clarify that i have no problem with FeedDemon or other aggregators supporting the feed:// protocol (Postel's law and all), i just don't think that sites should use it in their links (or if they do, they should also keep another link to an http:// url) because it makes it even more difficult for users like me who don't use FeedDemon (i'll happily become a FeedDemon user as soon as you release a linux version ;)

so i'm sure that my idea isn't a perfect solution either, but we need something that doesn't break the existing model.

[Lance]

I just added it to my blog. Been wanting something that worked regularly for a while now. This seems to although it even brings up FD when it's closed out so I can't tell what happens when and unsupported reader is in place. Or none at all for that matter. :)

[Nick Bradbury]

Stefano, I'm not convinced of the need for 'addfeed.' Clicking a feed link already subscribes to it, and both the title and the image can be taken from the feed itself.

[C Deardorff]

Not that a single-click solution to subscribing is a bad idea, but I'm not sure that using a misnomer like feed:// is a good idea. It suggests that a protocol other than HTTP is being used, which is not true.

The burden of usability should perhaps remain with the syndicating site authors, as well as the makers of the news readers. Let's not forget two important things that can be done to help this issue:

1) Use XSL references in your feeds to ensure that if users (90% at least) click on the link they won't see XML "garbage", but instead a nicely layed out HTML representation of the feed, along with a brief description of how to subscribe (see #2 for how brief this could be).

2) Use a news reader that supports drag-and-drop, so that subscribing (or at least viewing) a feed can be made much more simple than copy/paste. I use a reader that is independent of (different window) my default browser, but makes subscribing/viewing feeds and feed listings (OPML) as easy as dragging the XML icon/links/urls from the browser into the newsreader.

[Stefano F Rausch]

Nick, I just was curious about it. I don't see the need for it too.

[rjt]

The referenced blog-post that "MIME doesn't work" seems to ignore the fact that MIME documents can have actual content in addition to the meta-data. Surely it's trivial to define a new MIME document-type to be a list of (generally http) URLs of feeds, separated by new-line (or carriage return)? This then

* avoids the hacky ugliness of pseudo-protocols

* lets us give users explicit instructions inside the document itself if misconfiguration or missing software mean that the raw file is user-visible (unlike feed:// which just spits out an error)

* makes it trivial for content-providers to have a one-click subscribe-to-multiple-blogs button

Of course, rather than a plain text file, you could probably define the file content to be xml, but I've always been a fan of KISS. (aside: would OPML work here?)

[András Bártházi]

IMHO you're TOTALLY wrong. You just segmenting the web by doing it this way. There are - at least - two/three better way to define an RSS feed on a page. At first, you can include it in the header:

[link rel="alternate" type="application/rss+xml" title="RSS" href="/rss" /]

Or just use the standard way:

[a href="/rss" type="application/rss+xml"]RSS feed[/a]

Or create a relation:

[a href="/rss" rel="rss"]RSS feed[/a]

Defining a totally new thing is segmenting the web and an ugly way of using the power of you very nice application. PLEASE use the standards.

ps: sorry for double posting. :(

[Nick Bradbury]

András, FeedDemon does use the "standards" - and it supports the feed:// protocol as well. I'm not defining this protocol, either. It has already been defined (and implemented) by other feed readers.

[András Bártházi]

First of all, sorry, I thought feed:// is your idea (I didn't checked the link).

The other side, I still think, supporting a protocol, that is not based on a good design is not a good idea. As I guess, there are a lot of FeedDemon installation around, enough to give you a power to rule this world a bit. If you do it, then other people will do it, too. Don't do it. ;)

[Pete Hopkins]

C: I agree with you about replacing http: in the URL versus just prepending feed:. I'm happy that FeedDemon supports both, even though I favor the latter (which helps for non-http URLs, like https). The XSL idea is interesting, but does it work in IE?

rjt: Just what we need, another syndication-related standard. :) Plus, authors often don't have control over what mime types are served up by servers. In terms of KISS, the feed solution requires just adding five characters to a URL. It's hard to get simpler than that.

Andras: The problem with using the link tag exclusively is that it's invisible to users, so they don't know it's there. I like the idea of using the rel tag, but can applications hook into browsers so that rel gets redirected to them?

Nick: It's good to hear that another application developer is on board with feed:. One-click syndication is a big step in increasing RSS/Atom adoption among non-techies.

I'm of the mind that, yes, feed: is a bit of a hack, but it's five characters and it gets the job done better than any other solution. Don't let usability fall victim to semantic purity.

Plus, as more aggregators support feed:, it'll become a standard. :)

[Nico Morrison]

I'm curious why you recommend the 'feed://' protocol but do not use it on your blog feed links here? Or am I being really dumb? Or is it because Typepad does not support it or what? (BTW - have been a user of TS & FD both since V1)!

[Nick Bradbury]

I guess the reason is that my "TODO" list got a little too long :) I've just changed the "XML" buttons to "FEED" buttons which use the feed protocol.

[Noah Slater]

Ok, so I am a year late - but here are my thoughts anyway.

Surely your all missing one thing. The "http://" at the beginning of most common URLs indicates that the resource is to be fetched via the HTTP network communication protocol. A protocol that, surprisingly, defines how server and client should negotiate requests and responses for actions (such as GET or POST) on a resource.

Correct me if I am wrong, but: RSS, Atom or whatever format feed you use is being served up just like the rest of your site (with Apache, ISS or the like) and hence is being sent via the HTTP (most likely 1.1) protocol.

So... the protocol to use when requesting is "http://".

The ONLY (and I *meen* only) time "feed://" would be valid (by ANYONE'S standards) is if you were using a defined network communication protocol called "Feed".

Your proposal is an ugly hack and until you provide me with the URI of the Feed RFC I shall continue to believe this.

[Kieron Wilkinson]

In my opinon we should not hack about adding pseudo protocol's like feed:// - its just ugly. However I feel a few obvious things have not been said.

The problem seems to be that the RSS standard(s) are broken. Why not simply fix them by adding a url/base element?

The problems using MIME seem to stem from broken software, not broken MIME. MIME is absolutely meant to do this stuff, so why not fix the blogging tools to emit the appropriate headers? It's not that hard. Also any ISP that doesn't server up an rss+xml MIME header for *.rss files has a broken configuration - tell them to fix it.

Why not fix the problem rather than hack around it?