OpenID Proposal: OpenID Messaging

[Dro Kulix]

I think it's a great idea, but I wonder whether it's beyond the scope of
OpenID.  OpenID is an identification protocol, not so much a messaging
protocol, right?  I won't be the judge.  It's a good thought, and if it
doesn't belong in OpenID then it does belong in some protocol peripheral
thereto.

The more I think about this, actually, the more it seems like a protocol
to handle this would spawn a superb piece of mailing list or message
board software.

Consider it:  A comment on LiveJournal (or on similar sorts of weblog
software) is nothing more than some node in a hierarchy of messages,
like a Usenet post.  A journal site hosts a group of users, each of
which hosts a group of posts (, each of which host a group of
comments)+.

If I want to receive a copy of every reply to a certain comment--for
example, a comment C I left on some foreign journal J--I would tell my
messaging server M that I authorize J to send me messages about subject
C.  M will then (1) remember that messages received from J about J:C are
welcome, and (2) notify service J that it is welcome to send messages
about J:C through M to me, which is a tacit directive that it should do
so.  Then, if for some reason I wish to stop my subscription, I would
tell M server that messages from J about J:C are no longer welcome, and
the M would relay that point to J.  So, M keeps a list of subjects (and
their parent hosts) which are open subscriptions for me, the user.  Each
of those parent hosts also keeps a call list on a given subject in its
hierarchy.

A mailing list or an entire user's journal (or even an entire journal
site, if the site admin is into that sort of pain) could easily be
substituted for C.  Note that I said "subject C" and not "comment C"
once it was in the context of the messaging server--to M, everything in
existence that triggers the sending of a message is just a subject, no
matter where it is in the hierarchy.

Normally, you may say to yourself, a mailing list will only allow its
subscribers to post.  Well, a weblog/message board is also capable of
limiting who may post.  We're already sitting in the discussion room of
a protocol that facilitates this. :-)

So, we have legitimate messages taken care of.  We won't be receiving
much random spam because everything we receive through this particular
conduit is opt-in, and we should be verifying the senders of all
messages--because we can.  There's still the potential of journal site J
being/turning evil and sending me a bunch of dumb ads in messages marked
as being about J:C.  All I have to do to fix this is close my
subscription to J:C (and possibly to J:* if J is gonna be like that).
If J tries to continue sending me those messages, M will know to reject
them.  J has no real incentive to disobey an unsubscribe request.
Relief, people!

Now, because the same notion (that notion being that server J is allowed
to message user U on server M about subject J:C) is held in two
places--once on M, which then knows to receive said messages, and once
on J, which then knows to send said messages--there is a possibility of
falling out of sync.  It should be easy enough for J to find out that M
no longer welcomes a subscription, since M could respond to a message
(or even a ping, if J doesn't feel like sending a message) from J with a
sort of "cease messages" error code.  M should also be able to query J
somehow to find out if J:C is a dead trigger (is no longer updatable or
no longer exists) or if the subscription itself, "messages about J:C to
U at M", has vanished (had passed an expiration date, or was otherwise
accidentally or intentionally halted).

Outside of the protocol, a keen feature for M to implement would be to
keep subscriptions that were closed by the remote end still in the list,
with a button beside each one to request re-subscription, and maybe
another to just delete that entry.

So all this is, really, is an email box with an extremely focused opt-in
safe list, plus a certain extra degree of verification that any messages
sent are coming from whom they say they are, and built-in (not
hacked-on) features to manage subscriptions.  I would say that if
message board systems and instant messengers are different enough from
Usenet and email to build new specs, then this probably is as well...if
not in OpenID itself, then hopefully in something that plays well with
it.

-- Dro


On Wed, 2005-06-29 at 14:46 -0700, Kristopher Tate wrote:
> Hello everyone!
> 
> Amid using LiveJournal with my OpenID account lately, I find it very 
> troublesome that I can't receive a notification that someone has 
> replied to my comment. So, while I was out to lunch today, I started to 
> think about a new OpenID mode: 'message'.
> 
> Now alot of you may be thinking that this either a realllly good idea, 
> or to quite the contrary, a realllly bad one.
> 
> I don't think that it would be too hard to manage.
> 
> Basically, if a user associates their ID with a consumer, then the 
> consumer can send the user a message, that would be routed to their 
> email address by their ID server.
> 
> Am I going to far here, or would you like me to make some example code?
> 
> -Kris
>