

If e-mail had a baby: notification messages - jlong
http://wiseheartdesign.com/articles/2009/12/04/if-email-had-a-baby-notification-messages/

======
warwick
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.

~~~
arnorhs
That's a cool idea.

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 :)

~~~
warwick
I figured that I trust forwarding certain emails a lot more than I would trust
handing out my email password to some random web service.

------
derefr
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.

~~~
jlong
Yup, the possibilities are endless. It should be built in.

------
dylanz
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).

------
arnorhs
Wow, wonderful idea. I wholeheartedly support this and I hope at least some
sites will implement this.

------
seabee
What problem does this solve that RSS doesn't already?

~~~
jlong
Well for one, RSS is pull. This is push. RSS also requires that you subscribe.
This wouldn't necessarily require that.

~~~
philwelch
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").

~~~
pyre
> _email is often pull_

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._

