OpenID Proposal: OpenID Messaging

[M. David Peterson]

It is definitely out of the scope of OpenID. But one of the primary reasons 
I took an immediatte interest in the OpenID project when I learned of its 
existence from Sam Ruby is that it fits into the "credentials" space of a 
project I began developing a year ago March called "L.L.U.P." (PULL 
backwards; "The Other Side of Push" is the project slogan) which actually is 
an acronymic base for a variety of terms:

Limited[Lifetime|Length|Location] Ubiquitous Protocol > which in short 
definition is:

A proposal summary of a messaging protocol for weblog intercommunication and 
decentralized messaging of time sensitive and/or geographically specific 
publications.

The very old and nearing outdated executive summary to the specification can 
be found here > http://llup.org/LLUPWorkingDraftSummary.doc

After originally developing and documenting this idea I brought together 
several close friends in Kurt Cagle (recently appointed as the Chief 
Architect for Netscape 9), Russ Miles (Software Engineer, General Dynamics 
UK, author of "AspectJ Cookbook" from O'Reilly and is now working on another 
undisclosed title after recently finishing his Masters Thesis at Oxford 
University's Kellog College), and Don "DonXML" Demsak (Microsoft XML MVP) 
and created the first iteration document linked above. I am currently 
working on the updated specification in which too much has changed to try 
and cover in this email. However, when available I will offer up the link 
location to this list for immediatte consumption.

LLUP is actually set to be the defacto messaging format for my ChannelXML 
project in which the .net domain space will be a decentralized network of 
nodes working together in coordination to gather, sort, and make available 
via subscription and search services content that is specific to a defined 
channel in which those in whom have an interest in a particular topic (e.g. 
Decentralized Messaging, General Technology, Exotic and Gourmet Coffee's of 
the World, or whatever other topics might exist where there are groups of 
people willing to collaborate in both resources, knowledge and expertise, 
etc...) have banded together and donated a percentage of a systems resources 
to serve up this channeled content to the world after it has been processed 
by these same servers. Again, too much to try and cover in this email but 
you will hear more of this piece very soon.

As you will notice if you read the above specification summary this is 
something I have sat down with both Tim Bray and Sam Ruby in person to 
ensure this was something they saw as both valuable and necessary and to 
furthermore gain advice on what to do next. While I wont go into specifics I 
will mention that Tim's last words before we left the bar that evening were 
"Go and change the world!" so I can assure you this is a project that I have 
since poured my heart, soul, and all available energy into its creation and 
I'm excited to now state that I believe I have most definitely found the one 
remaining missing piece to this project in OpenID which, in many ways, will 
be the crux of the entire project if it can be proven to act as a reliable 
and adequate filter for who can and who can not gain access to us via the 
mediums used as part of this messaging protocol.

I believe this project (OpenID) can do a lot more than that and am EXTREMELY 
excited now to see this completed (or very near completion) right around 
this time as I have purposely and specifically held back any and all 
releases for public consumption of the updated materials until such time as 
the Atom Data Feed Specification and Publishing Protocol reach the
1.0status. According to Tim Bray's latest comments from the end of
last week
they are less than a couple months away from this release which is now the 
primary foundation of the LLUP protocol. Between now and then there should 
be adequate time to both determine/prove that LLUP has found its 
"credentials" solution in OpenID and furthermore develop the ChannelXML 
project with complete integration such that upon recieving word of an Atom 
1.0 specification release I can then immediatelly announce the first beta 
release of the ChannelXML project and related software with full integration 
of LLUP and OpenID. Actually, the two sound pretty good together when you 
speak them outloud.

Cheers :)

On 6/29/05, Dro Kulix <dro at drocore.com> wrote:
> 
> 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
> >
> 
> 
> 


-- 
<M:D/>

M. David Peterson
[ http://www.xsltblog.com/ ][ http://www.xmlblogs.net ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/yadis/attachments/20050629/e26a1343/attachment-0001.htm