[derefr]

Maybe technically. For me the difference is much more practical: with RSS, I can subscribe to something that updates once every five months, and not miss that update, because it ends up as an unread item in my inbox forevermore. With Twitter (or Facebook, Tumblr, or any other "activity feed" site), by the time I check, that one update has long been washed away by the stream of more frequent updates from other things.

You'll notice, though, that there is one other thing that already manages this perfectly: email newsletter subscription. RSS at this point could really just be made into a microformat on top of email--presumably, just a specific additional MIME-type for messages--and then an RSS "client" would just be a special email client that gives you an alternate view of your own email account's inbox, only showing messages that have a representation in that MIME-type available, and laying them out in the traditional "river of news + passing an item marks it as read" style. And there would be literally no difference experience-wise!

It could even be set up on top of your Gmail inbox, which feels justly spiteful somehow. :)

Now, obviously, not everybody wants to set up their own Sendgrid account or something just to allow RSS subscriptions. Regular "XML file on a webserver" RSS could still exist as the lazy producer-side method, while still changing the consumer-side entirely into something SMTP+MIME-based. PubSubHubbub gateways (like Superfeedr) are already doing something equivalent in cost to sending out email; it would just be a matter of convincing them to add an additional subscription option.

Also, the fact that RSS items would be served with an "additional" MIME-type is important: if all these messages also had a regular text/plain or text/html representation, then looking at your email inbox with a regular mail reader would still show you all the same messages (though they could obviously be filtered away from your inbox into a "Subscriptions" tag if you so preferred.) What was starred in your RSS reader would be starred in your email client. To share an RSS item with a friend, you'd just forward it (and then they'd see it in their RSS client, since the forwarded message ended up in their email inbox!) You'd never lose anything as long as you had an IMAP client to sync it with. Et cetera.

In effect, RSS would no longer be its own special domain, only exposed through special tools; it would "just" be email. And more interestingly, vice-versa! Any message that wanted to (I'm thinking "lifecycle emails" or newsletters) could add an RSS MIME representation, and it would start showing up in your RSS client just like anything you had subscribed to through one of the PuSH gateways. "Email newsletter" would, in fact, become unified as a concept with "RSS." If we're all being called-to-arms to get down to hacking on something, why not set this up instead of just writing a thousand crappy new RSS readers? ;)

---

P.S. While we're at this call-to-arms: you could build another "filtered-MIME-type viewer client" of your email inbox, and make that one a to-do list program. Think about it. (http://blog.gaborcselle.com/2012/03/email-as-todo-list-proto..., http://www.paulgraham.com/ambitious.html)

[icebraining]

But what's the point? If you want to read RSS in your email, it's not particularly hard, so what would be the point of coming up with new formats and adapting newsletter software?

[derefr]

Here's an analogy for the current "way of things" in email-land: imagine if, instead of a web browser, you just had a database view into an HTTP cache: a list of URLs retrieved recently, each of which, when clicked, rendered as an HTTP "message." (Imagine a file-folder full of MHTML archives, basically.) At the top, there would be an address bar--but, when you entered an address into it, it would simply retrieve a new item into the cache, which you would still have to click into to look at. It wouldn't be very obvious at all how to build something like an AJAX web-app on top of this, because, although the protocol is compatible with it, the representation is too low-level.

As a user of a web browser--an abstraction over HTTP messages--you don't care about each individual HTTP response; you only care about pages. Sometimes an HTTP response will deliver you new pages; sometimes it will modify a page already loaded. Web browsers only still really use HTTP at all because the verb set (GET, PUT, POST, etc.) so closely aligns with the things people want to do on the web. It's an excellent protocol for generic RPC between machines, that also happens to be usable directly by humans to GET web-pages. Now, why doesn't anyone see that SMTP+IMAP are an excellent protocol for doing publish/subscribe between machines, where real humans happen to also be able to (and already do!) PUBLISH and SUBSCRIBE?

The advantages of making a protocol an abstraction over email are manifold:

1. the messages are stored in the receiver's email inbox--a universal resource that everyone has [and understands the purpose of!];

2. all messages can be processed using the same "utilities" we use for email (backup utilities especially);

3. the ports for SMTP, POP3 and IMAP are almost always open inside corporate firewalls, just like the ports for HTTP;

4. and all messages you send through those protocols will get passed through email infrastructure (which is big and robust and reliable, and, most important, already exists)--and, in the process, can get forwarded, multiplexed across mailing lists, thrown out as spam, and all the other convenient things riding on email infrastructure gives you for free.