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:<br>
<br>
Limited[Lifetime|Length|Location] Ubiquitous Protocol > which in short definition is:<br>
<font size="2"><br>
A proposal summary of a messaging protocol for weblog
intercommunication and decentralized messaging of time sensitive
and/or geographically specific publications.<br>
<br>
The very old and nearing outdated executive summary to the
specification can be found here >
<a href="http://llup.org/LLUPWorkingDraftSummary.doc">http://llup.org/LLUPWorkingDraftSummary.doc</a><br>
<br>
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</font><font size="2"> XML</font><font size="2"> 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.</font><br>
<font size="2"><br>
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 <span style="font-style: italic; font-weight: bold;">very soon</span>.<br>
<br>
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.<br>
<br>
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.0 status. 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.<br>
<br>
Cheers :)<br>
</font><br><div><span class="gmail_quote">On 6/29/05, <b class="gmail_sendername">Dro Kulix</b> <<a href="mailto:dro@drocore.com">dro@drocore.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think it's a great idea, but I wonder whether it's beyond the scope of<br>OpenID. OpenID is an identification protocol, not so much a messaging<br>protocol, right? I won't be the judge. It's a good thought, and if it
<br>doesn't belong in OpenID then it does belong in some protocol peripheral<br>thereto.<br><br>The more I think about this, actually, the more it seems like a protocol<br>to handle this would spawn a superb piece of mailing list or message
<br>board software.<br><br>Consider it: A comment on LiveJournal (or on similar sorts of weblog<br>software) is nothing more than some node in a hierarchy of messages,<br>like a Usenet post. A journal site hosts a group of users, each of
<br>which hosts a group of posts (, each of which host a group of<br>comments)+.<br><br>If I want to receive a copy of every reply to a certain comment--for<br>example, a comment C I left on some foreign journal J--I would tell my
<br>messaging server M that I authorize J to send me messages about subject<br>C. M will then (1) remember that messages received from J about J:C are<br>welcome, and (2) notify service J that it is welcome to send messages
<br>about J:C through M to me, which is a tacit directive that it should do<br>so. Then, if for some reason I wish to stop my subscription, I would<br>tell M server that messages from J about J:C are no longer welcome, and
<br>the M would relay that point to J. So, M keeps a list of subjects (and<br>their parent hosts) which are open subscriptions for me, the user. Each<br>of those parent hosts also keeps a call list on a given subject in its
<br>hierarchy.<br><br>A mailing list or an entire user's journal (or even an entire journal<br>site, if the site admin is into that sort of pain) could easily be<br>substituted for C. Note that I said "subject C" and not "comment C"
<br>once it was in the context of the messaging server--to M, everything in<br>existence that triggers the sending of a message is just a subject, no<br>matter where it is in the hierarchy.<br><br>Normally, you may say to yourself, a mailing list will only allow its
<br>subscribers to post. Well, a weblog/message board is also capable of<br>limiting who may post. We're already sitting in the discussion room of<br>a protocol that facilitates this. :-)<br><br>So, we have legitimate messages taken care of. We won't be receiving
<br>much random spam because everything we receive through this particular<br>conduit is opt-in, and we should be verifying the senders of all<br>messages--because we can. There's still the potential of journal site J<br>
being/turning evil and sending me a bunch of dumb ads in messages marked<br>as being about J:C. All I have to do to fix this is close my<br>subscription to J:C (and possibly to J:* if J is gonna be like that).<br>If J tries to continue sending me those messages, M will know to reject
<br>them. J has no real incentive to disobey an unsubscribe request.<br>Relief, people!<br><br>Now, because the same notion (that notion being that server J is allowed<br>to message user U on server M about subject J:C) is held in two
<br>places--once on M, which then knows to receive said messages, and once<br>on J, which then knows to send said messages--there is a possibility of<br>falling out of sync. It should be easy enough for J to find out that M
<br>no longer welcomes a subscription, since M could respond to a message<br>(or even a ping, if J doesn't feel like sending a message) from J with a<br>sort of "cease messages" error code. M should also be able to query J
<br>somehow to find out if J:C is a dead trigger (is no longer updatable or<br>no longer exists) or if the subscription itself, "messages about J:C to<br>U@M", has vanished (had passed an expiration date, or was otherwise
<br>accidentally or intentionally halted).<br><br>Outside of the protocol, a keen feature for M to implement would be to<br>keep subscriptions that were closed by the remote end still in the list,<br>with a button beside each one to request re-subscription, and maybe
<br>another to just delete that entry.<br><br>So all this is, really, is an email box with an extremely focused opt-in<br>safe list, plus a certain extra degree of verification that any messages<br>sent are coming from whom they say they are, and built-in (not
<br>hacked-on) features to manage subscriptions. I would say that if<br>message board systems and instant messengers are different enough from<br>Usenet and email to build new specs, then this probably is as well...if<br>
not in OpenID itself, then hopefully in something that plays well with<br>it.<br><br>-- Dro<br><br><br>On Wed, 2005-06-29 at 14:46 -0700, Kristopher Tate wrote:<br>> Hello everyone!<br>><br>> Amid using LiveJournal with my OpenID account lately, I find it very
<br>> troublesome that I can't receive a notification that someone has<br>> replied to my comment. So, while I was out to lunch today, I started to<br>> think about a new OpenID mode: 'message'.<br>><br>> Now alot of you may be thinking that this either a realllly good idea,
<br>> or to quite the contrary, a realllly bad one.<br>><br>> I don't think that it would be too hard to manage.<br>><br>> Basically, if a user associates their ID with a consumer, then the<br>> consumer can send the user a message, that would be routed to their
<br>> email address by their ID server.<br>><br>> Am I going to far here, or would you like me to make some example code?<br>><br>> -Kris<br>><br><br><br></blockquote></div><br><br><br>-- <br><M:D/>
<br><br>M. David Peterson<br>[ <a href="http://www.xsltblog.com/">http://www.xsltblog.com/</a> ][ <a href="http://www.xmlblogs.net">http://www.xmlblogs.net</a> ]