Four little letters…

LLUP
—

Life after email

As a social phenomenon, the end of email has been widely reported. The next generation doesn’t use it. As a technical phenomenon, spam is a persistent threat. Spam’s been a lot worse in the last couple of weeks (no doubt the reason I started thinking about these things); apparently the spammers have concocted a strategy that circumvents Bayesian filtering (it’s only temporary, I’m sure, but the next victory in spam filtering is only temporary too). �

I’ve noticed the same phenomenon. It’s getting really, *REALLY*, bad!

What’s next? IM, Wikis, web forums instead of email? Bleh!

Agreed!

Maybe I’m just too old to learn new tricks, but I want correspondence pushed to me (or I want the appearance of push, anyway) and I want to read and edit it locally, in the application of my choosing, not in some browser form

Agreed. Too much effort. The solution must be seamless, and work with the tools we already use for email-esque communication. In fact, the solution has to be developed in such a way that those with an established position in the email client/server market(s) can quickly, easily, and as mentioned (and is really the key, in my own opinion) seamlessly integrate with these tools such that the “switch” from the existing technologies (e.g. SMTP, POP, IMAP, proprietary protocols such as those used in Exchange for advanced workgroup/corporate communication/collaboration, etc..) may not even require a switch at all (i.e. a driver that allows each of these technologies to easily interop with any of the new required protocols), and if it does, will be as transparent as possible to the customer/employee, etc… who will be using it.

It occurs to me that with a little work, Atom might function as a replacement for POP/IMAP and the Atom publishing protocol might replace SMTP. I can see a glimmer of how I might move forward while mostly preserving a couple of decades of work habits. As usual, the social problems are larger than the technical ones

Yep, completely agree! Through the work I have been doing with LLUP, I have come to my own conclusions that there are a few additional off-the-shelf pieces necessary to complete the puzzle, but without a doubt, Atom and APP are the key behind all of this.

In fact, this was a point I brought out to Eve (Maler) a while back when Russ and I first spoke with her about LLUP. There have been a few people along the way who have insisted that “you guys are taking too long to finish this up” or “if this really was so simple, why not just finish it out and be done with it” to which the answer, as mentioned to Eve, is pretty straightforward,

The right pieces have to be in place *first* before LLUP will be able to work and work well***. The specification is *SIMPLE*! MIND NUMBINGLY SIMPLE, in fact. Here’a a quick overview provided by Russ from a while back,

At the heart of LLUP is the BLIP. The BLIP is a piece of content, declared in a standard way using XML, that specifies four main things:

* A reference
A pointer to the content that the BLIP describes.
* A lifetime
How long the BLIP will be relevant for.
* Relevancy
Listed as keywords by a defined or undefined vocabulary. Can also include a signature or signatures of those who should receive the BLIP.
* Signature
A means of signing the message by the message sender.

NOTE: For a more extended overview, I’ve been pulling together a notes page on the LLUP development site. A work in progress, but a solid base of information to look through none-the-less. And to be quite specific, an overview answer to the question “What is LLUP“, where you will find the following, somewhat outdated sample of what an LLUP-based message might look like (Blip is a term we use to act as a sample implementation of the LLUP specification) using Atom Notifications as its carrier,

POST /blip-notification HTTP/1.1
Host: blip.ws
Content-Type: application/atom+xml
Content-Length: nnnn

    <notification action="updated">
        <!-- NOTE: possible values for @action = created, updated, deleted.
            subscribe, unsubsribe would need to be added.  I think.  Russ,
            can you verify based on the development work you did if these
            are necessary @action values? -->
        <entry xmlns="http://www.w3.org/2005/Atom" xmlns:pub="..." xmlns:llup="http://www.x2x2x.org/2005/LLUP">
            <id>tag:iblog.name/m.david/public/groups/comp/lang/lisp:1</id>
            <link rel="self" href="https://secured.iblog.name/m.david/public/groups/comp/lang/lisp/HelloLLUP.xml" />
            <title>Hello LLUP</title>
            <published llup:expires="2005-09-15T00:00:00Z">2005-09-08T00:00:00Z</published>
            <updated>2005-09-08T00:00:00Z</updated>
            <author>
                <name>M. David Peterson</name>
                <uri>https://secured.iblog.name/m.david/blip-response</uri>
            </author>
            <summary>Heres a quick 'Hello World' sample for all you lisp weenies out there.</summary>
            <category label="computers" term="programming" scheme='http://channelxml.org/channels/top-level' />
            <category label="languages" term="lisp" scheme='http://channelxml.org/channels/mid-level' />
            <category label="sample" term="HelloWorld" scheme='http://channelxml.org/channels/specific' />
            <llup:recipient href="nntp://comp.lang.lisp" />
        </entry>
    </notification>

As should be quite obvious, its not an issue with “we still need to figure out this, or that, or whatever else” and instead, we simply have to make sure the proper infrastructure is in place before we can expect to push out a standard that relies *HEAVILY* upon this same infrastructure already being in place to be enabled to be a success. The Atom Syndication Format, a key component, is in place, so we’re half way there. However, the Atom Publishing Protocol, while close, is the one missing to all of this, and in fact, is the most crucial piece to ensure that when the specification is finalized and readied for use we can simply push play and, borrowing a term from the Bill Gates era, expect that people will be enabled to “plug-and-play” and expect for it to just work.

Extending from this a bit, there’s still a few missing pieces to all of this, but by missing I don’t mean they need to be either found or created, and instead for this all to work really, REALLY well, there are some additional pieces to the overall puzzle that are required to ensure that the Google’s and the Microsoft’s and the Yahoo!’s and the Amazon’s, and even more specifically, the Technorati’s and the PubSub’s, and the Syndic8’s of the world can quickly begin to provide services around this protocol such that the final piece to the puzzle, that of providing *incentive* to the established and/or start-ups of the world to integrate and/or implement these technologies is obvious, and therefore a no-brainer in regards to doing just that.

Below is a copy of both a recipe I posted a while back as well as extended directions of how one might use these ingredients to form the proper solution,

The Recipe

Add together

- One Part *Atom*
- One Part *Atom Publishing Protocol*
- One Part *An entry on your personal blog* [1]
- One Part *Web-based Delivery Transport* of some sort [2]
- One Part *Blip Messaging*
- and as many parts necessary, *SemanticWeb-enhanced Search Engine/Data Collection and Distribution Service* (e.g. Google, MSN/Windows Live, Yahoo!, A9, Technorati, PubSub, etc…)

Bake at 350 degrees for 14 minutes until just lightly golden brown.

Serve while hot!

Enjoy :)

The Directions (with two additional ingredients added to the mix)

…if you were to take (first and foremost),

The Content Creator

- Who would utilize the [Atom Publishing Protocol] for publishing the
content he/she has created.
- Which would then invoke a process in which generates/updates an [Atom]
feed providing subscription based access to this content.
- Which would then invoke a process which generates a [Blip Message] to
describe the time/date/contextual semantics contained in the content.
- Which would then be wrapped inside of an [Atom Notification] as the two
way PubSub delivery mechanism of these messages.
- Which would then be indexed by an indexing provider of some sort,
- Who would then make this content available via an [OpenSearch] machine
readable interface, proving a simplified, human understandable mechanism to
query this index for items of interest.
- Who might then use [RFC 4661 : Event Notification Filtering] such that
once they find that in which they have interest in they are then enabled to
set triggers in which to be notified when a match is made.

Wouldn’t that for all intents and purposes complete the circle of the
semantic webs life?

As should be pretty obvious, the above represents, for the most part, off the shelf parts to pull this all together in a nice, snug little package thats,

1) Simple
2) Really Simple
3) Really, REALLY Simple

All three of which I believe are the single most important aspect of *ANY* specification, though as with most of the above, *MOST* of the ideas behind LLUP are not really my own ideas, which in fact might be just as important of an attribute as *ALL* of the others,

Don’t re-invent *ANYTHING* you don’t have to.

So Norm (and anyone else with interest): We’ve got a good bunch of folks together already, and a few more recent additions that I need to add to the list, names in which you would immediatelly recognize and of which you would already have a respect for. For obvious reasons, we would *LOVE* to have you join us in our ongoing conversation regarding the development of this spec. :)

Either way, I’m with you 100% on all of that in which you have brought out. As you can probably imagine, I’m looking forward to seeing how this all turns out ;)

Oh, and one final thought… While I am taking risk of Uche taking me out back and beating me over the head with the same shovel he buries me with for bringing this out ;), as per your comment,

“Maybe I’m just too old to learn new tricks, but I want correspondence pushed to me (or I want the appearance of push, anyway) “

LLUP? It’s just pull spelled backwards, of which the original slogan I came up with was,

LLUP : The Other Side Of Push

“Uche! Put the shovel down!” ;)

—

*** : Microsoft’s Tiger Project (Video On-Demand) from the mid-90’s era proved this fact quite nicely. The technology to implement a video-on-demand service has existed for well over ten years. And yet even today, we still don’t have the infrastructure in place to pull it off. We *should* have it in place, but because of our good old friends Ma and Pa Bell, for some reason, they just haven’t got around to providing it for us yet. Why?

Well, there’s more than just this, but the primary reason, in my own opinion, is that they haven’t got the legal stranglehold in place in which they need to ensure they are the only players in town providing these services.

While country, after country, after country are adding high speed (think 100mb/s wired lines into your home) services to an increasing base of their customers, we are not and will not be one of them because Ma and Pa want to be sure they can continue to control all of that in which the rest of the world already has.

Don’t you just love politics.