Because there could be value in reimplementing a similar idea in a different way. Whether it's an RSS redo or not, it looks like it could be valuable. People in the comments argued the "notifications" idea can already be done by Gmail folders. But his idea may be the better implementation.
It's replacing a subset of email, and email is often pull.
Needing to subscribe is arguably a feature. In fact, if subscription was required on the protocol level like RSS spam would be impossible (for some values of "impossible").
So... when is it that I pull an email sent to me from the SMTP server of the person sending it? Pulling it from the server to the client to read it doesn't count as email being 'pull.'
The difference is that with RSS you are pulling from the source not pulling from your personal 'cache' (unless you use a web reader like Google Reader, but even then Google is pulling from the source; RSS updates aren't being pushed to Google). The email equivalent would be querying all SMTP servers out there (or a subset) to see if they have mail for you rather than hitting up your IMAP/POP server to see if anyone has sent something to you.
I think the better question is what does this solve that email doesn't? You can already sort notifications into different inboxes with a decent client. Now, true, you can't have your client take specific actions based on, but that doesn't mean clients can't support it as is. Simply add a feature to a mail client that allows you to enter in certain criteria for titles and take that action. I'm not really sure how this would be any different.
I think a better solution is the one a poster made above. Have a single email address for notifications and some web or desktop app that takes care of those. If it's web based with an API or allows plugins, you can build something that plugs into that and do everything that the author is suggesting.
I'm just generally against mucking with standards when a solution can already be implemented.
I've been working on a little notification app idea. You create an account with a web service. That account gives you a unique email address to forward all your notification emails to (presumably with automated rules) or to just set as your email address on systems that send you notifications. You'd also be able to add RSS feeds.
Between these sources, you build a list of notifications. Then there's a little iPhone app that let's you do six things with each notification:
- Read the full article or email
- Create a new todo
- Add something to your schedule
- Send a copy of the notification to someone else
- Bookmark the notification
- Ask for a reminder (Reshow the notification after a certain amount of time)
This is just something I've been playing with as my fun-hack project. It came about because a friend was complaining that she wished her inbox could be about correspondence, not notification.
The problem with it, though. Is that you'll have to change all your accounts and profiles to this e-mail, then the password reminders etc, come to this address. This address would then become, probably, the most important e-mail you have (so security vaulnerabilities are a extra-big no-no)
Then there's also the added overhead of having to deal with an extra service, simply for notifications that you usually just throw in the trash.
But maybe if it wasn't it's own e-mail address, but that you'd rather have your app connect to the user's e-mail inbox and download, and even delete, the notification e-mails.
John, great article. I met you at the first Rails conference in Chicago, I've used your well written CMS, so, I'm expecting addendum's to the related RFC's and an implementation into the major MUA's with all due haste :)
Seriously though, you make a great point. There is a definite distinction between "mail" and "notifications". When I went to go get my mail today, there were a bunch of actual letters, and, a bunch of postcard like notifications. Most were SPAM of course ("use our maid service!", "you need new gutters, ours are the best!", etc)... but some were legitimate reminders ("your XXX runs out in a week", "remember, we're coming by your house tomorrow").
I'm all for it, seeing that the amount of online notification-like emails are getting more and more frequent (at least in my case).
I've never understood what was wrong with using SMTP+IMAP/POP/Exchange as an abstract protocol for developing applications that aren't email-related, similar to how things that aren't web browsers today communicate via HTTP requests with things that aren't [generally thought of as] web servers.
Instead of reinventing the wheel with things like PUbSubHubbub, iPhone notifications, Twitter, Google Wave and so on, why not just make each API message-send an email, send it to the addresses of its subscribers, and have those subscribers check their inboxes and deal with each received message programmatically? You could give each communicating client/server program a separate email address, or you could give them a uniquely-identifying key as a MIME header and stick as many clients or servers as you wish into a single global inbox (that is, a message queue) that applications would pull messages out of—including, to polish off the abstraction, messages representing emails!
If the identifying key was unique to the thread/conversation/channel/wave instead of unique to the application, it would instantly nullify spam: to email someone, you'd push an "I want to start a conversation with you" notification to their publicly-known key under their address/identity, which they would then acknowledge (or not) by replying with a conversation key (sort of like a Facebook friend request, but temporary.) Of course, each person could have whitelists where any requests to start conversations were automatically accepted from given addresses.
Underneath, if you actually poked your head in with a "real" email client, there would be thousands of very trivial messages flying back and forth. However, we already have the infrastructure set up for exactly that; why not use it? Also, there would be many messages that would be sent (likely as spam) and silently discarded because the receiver didn't have anything corresponding to the conversation key; this would probably kill email spam down to Twitter levels, for those within the bubble of the email-in-message-in-email abstraction.
To optimize this, you'd likely have a global mail queue on each computer acting a bit like an SMTP server (but more likely speaking Exchange so as to keep your mobiles and other computers all reading the same messages at the same time), and an messaging library (or perhaps even a full-blown IPC kernel subsystem) that hides the fact that everything is really doing SMTP.
18 comments
[ 6.9 ms ] story [ 67.5 ms ] threadNeeding to subscribe is arguably a feature. In fact, if subscription was required on the protocol level like RSS spam would be impossible (for some values of "impossible").
So... when is it that I pull an email sent to me from the SMTP server of the person sending it? Pulling it from the server to the client to read it doesn't count as email being 'pull.'
The difference is that with RSS you are pulling from the source not pulling from your personal 'cache' (unless you use a web reader like Google Reader, but even then Google is pulling from the source; RSS updates aren't being pushed to Google). The email equivalent would be querying all SMTP servers out there (or a subset) to see if they have mail for you rather than hitting up your IMAP/POP server to see if anyone has sent something to you.
I think notifications handle that use case better than RSS. I think of notifications as basically an email subject with no body.
I think a better solution is the one a poster made above. Have a single email address for notifications and some web or desktop app that takes care of those. If it's web based with an API or allows plugins, you can build something that plugs into that and do everything that the author is suggesting.
I'm just generally against mucking with standards when a solution can already be implemented.
Between these sources, you build a list of notifications. Then there's a little iPhone app that let's you do six things with each notification:
- Read the full article or email
- Create a new todo
- Add something to your schedule
- Send a copy of the notification to someone else
- Bookmark the notification
- Ask for a reminder (Reshow the notification after a certain amount of time)
This is just something I've been playing with as my fun-hack project. It came about because a friend was complaining that she wished her inbox could be about correspondence, not notification.
The problem with it, though. Is that you'll have to change all your accounts and profiles to this e-mail, then the password reminders etc, come to this address. This address would then become, probably, the most important e-mail you have (so security vaulnerabilities are a extra-big no-no)
Then there's also the added overhead of having to deal with an extra service, simply for notifications that you usually just throw in the trash.
But maybe if it wasn't it's own e-mail address, but that you'd rather have your app connect to the user's e-mail inbox and download, and even delete, the notification e-mails.
Then it could be pretty cool (in my opinion)
Good luck with it :)
Seriously though, you make a great point. There is a definite distinction between "mail" and "notifications". When I went to go get my mail today, there were a bunch of actual letters, and, a bunch of postcard like notifications. Most were SPAM of course ("use our maid service!", "you need new gutters, ours are the best!", etc)... but some were legitimate reminders ("your XXX runs out in a week", "remember, we're coming by your house tomorrow").
I'm all for it, seeing that the amount of online notification-like emails are getting more and more frequent (at least in my case).
Instead of reinventing the wheel with things like PUbSubHubbub, iPhone notifications, Twitter, Google Wave and so on, why not just make each API message-send an email, send it to the addresses of its subscribers, and have those subscribers check their inboxes and deal with each received message programmatically? You could give each communicating client/server program a separate email address, or you could give them a uniquely-identifying key as a MIME header and stick as many clients or servers as you wish into a single global inbox (that is, a message queue) that applications would pull messages out of—including, to polish off the abstraction, messages representing emails!
If the identifying key was unique to the thread/conversation/channel/wave instead of unique to the application, it would instantly nullify spam: to email someone, you'd push an "I want to start a conversation with you" notification to their publicly-known key under their address/identity, which they would then acknowledge (or not) by replying with a conversation key (sort of like a Facebook friend request, but temporary.) Of course, each person could have whitelists where any requests to start conversations were automatically accepted from given addresses.
Underneath, if you actually poked your head in with a "real" email client, there would be thousands of very trivial messages flying back and forth. However, we already have the infrastructure set up for exactly that; why not use it? Also, there would be many messages that would be sent (likely as spam) and silently discarded because the receiver didn't have anything corresponding to the conversation key; this would probably kill email spam down to Twitter levels, for those within the bubble of the email-in-message-in-email abstraction.
To optimize this, you'd likely have a global mail queue on each computer acting a bit like an SMTP server (but more likely speaking Exchange so as to keep your mobiles and other computers all reading the same messages at the same time), and an messaging library (or perhaps even a full-blown IPC kernel subsystem) that hides the fact that everything is really doing SMTP.