I am in "collection-mode" at the moment... this page will seem a bit out of whack for a bit while I access notes, messages, etc... and use this page as a collection bin to then sort out once complete.

A recent post from Tim Lynch to the LLUP Development List

URI of original thread

Hey guys,

I've had a number of conversations with people recently about LLUP and BLIPs that seem to follow the same line of reasoning: "well, isn't RSS/Atom the same thing?" or, "I do that now with email!", etc., etc. In the latest such conversation, after a lot of hand waving and mad pencil sketching on my part, a light bulb finally went on for me: blips enable workflow.

From Sylvain's "Introducing LLUP" blog entry from ~month ago:

Feeds are great but not everything belongs to them. Say I have a regular HTML web page with one single image. I don't want to provide a full feed to inform users I have updated it. Instead I simply send a small blip when needed.

How 'bout if the current image object provided a way for me to register that I wanted to be blip'ed when Sylvain updated the image? What if every object on the page provided such functionality? What if the page itself provided a registration option: "I'll blip you when anything on this page changes"? The granularity of what I want to be notified about is left to me, the consumer. (Of course, the blog owner would set the initial, overall blip granularity and what per-object blip msgs he/she wanted to support.)

The ability to manage a set of keyword topic filters on some blogXast server is cool, but what could really set LLUP/BLIP apart is the ability to register on a per-object basis.

If registration-per-object is possible, then you've got a killer lightweight workflow tool that could be used for all sorts of things.

I'm imagining a smart-widget-w/tinyicon along the lines of Ray Ozzie's Live Clipboard where the tinyicon appears next to any object that wants to advertise it's blip-ability. Clicking the icon could provide a drop-down of available blip msgs ( [ 'Notify of any change', 'Notify of new content', 'Notify of new comments'] ). Obviously, not every object needs or wants to be blipable, but for those that do ...

ok, granted, there's some details to work out :) like, if a page-update blip goes out, how's it distinguished from an image-on-the-page-update? otherwise, what d'ya think?

Sylvains Follow-up

Nothing to add. This was the idea behind my blog entry. Exactly as you stated. This is in fact something that had striked me as well as one of the greatest strength of a LLUP/BLIP system. Any resource should be BLIPable (if I may abuse), or at least resources set as BLIPable (I must stop that now) by the publisher should be.

The fantastic difference between this an email or syndication is, as you say, the level of granularity as well as the flexibility of the LLUP system. There is another big advantage to LLUP which can be described quickly.

A few days ago I was googling (I should be careful as it seems Google doesn't like using their name as a verb) for LLUP to see who was talking about it. I found one entry of someone I don't think I had ever heard of around the project [1]. Now imagine if this blogger had published his entry to a LLUP publication service. Because I would be subscribed to the LLUP service regarding LLUP, I would have received a notification about his entry without having to search for it.

Of course because such capability could be abused as a SPAM, the LLUP service could have removed it all together instead of pushing it to me. Email can do this but well the mail protocol is so abuse with SPAM today that I'm not sure this would be the best option. Syndication might be able to reproduce the behavior to a certain extent (look at online aggregators) but again cannot provide the different capabilities of a LLUP service.

I can understand why people might get scared at yet a new protocol. we have so many already. The interest aspect of LLUP however is that it is independant from the underlying protocol that will carry BLIP messages. Therefore it doesn't redefine the wheel. It simply polished it a little.

- Sylvain

[1] Link that I cannot find anymore of course...

M. David's Follow-up to Sylvain

Ah, yes, very important points of distinction, Sylvain!

In the current Internet landscape, there might exist HUNDREDS of group lists, all centered around the same general topic. At present time, there is no way for me to subscribe to "Agriculture" and gain access to all of the various public conversations going on in regards to this topic. But what if I don't want something quite so general, and instead, only those conversations that have to do with "Agriculture" and "Outbreaks" (similar to your use-case)? And what if I only want those same messages that relate to the Central United States, and are contained within a certain date range (important for both an understanding of current outbreaks, but also useful from a historical snapshot perspective when doing research.)

This is the type of use-case where LLUP begins to shine. :D

M. David's Follow-up to Tim

Hi Tim,

In fact,

How 'bout if the current *image object* provided a way for me to register that I wanted to be blip'ed when Sylvain updated the image? What if every object on the page provided such functionality? What if the page itself provided a registration option: "I'll blip you when anything on this page changes"? The granularity of what I want to be notified about is left to me, the consumer. (Of course, the blog owner would set the initial, overall blip granularity and what per-object blip msgs he/she wanted to support.)

if you were to go through the archive of the original conversations that Russ and I had when we first began to nurture this idea, you would discover that this is in fact VERY similar to where we both could see this leading towards.

The primary difference between what you gain with Blip Messaging, and what you don't have with either web feeds or email is pretty straight forward,

with web feeds, but not with email.) This is the Pull side.

that message first (you get this with email, but not with web feeds.) This is the Push side.

Where they meet in the middle is where the distinct advantage come to be realized, and in fact, as you state, becomes part of a workflow system.

Take, for example, this VERY OLD mock-up of a work flow application:

http://dev.viberavetions.com/index.html

If you look in the upper right hand corner, you will notice several "Mode"s. The idea is simple,

By taking the two Push/Pull advantages from above, you gain granular level control over what messages gain access to your point of presence at any given time. So, for example, if I am currently working on some code, and to be interupted would mean losing my current "mind flow", I would set my current "Mode" to "Work". The definition file for "Work" might allow messages only from my team members that are of a certain subject matter that has to do with my current task (setting my current task via categories (e.g. project name, particular task within the project)) through, and potentially "emergency only" messages from my wife (I'm not married, but thats obviously not important to this example :). Beyond this, however, the messages would be left in the queue for me to access when my Mode changes, or when I decide "Oh, I need to check on that while I'm thinking about it."

There are some other advantages as well.

- Because the messages are the equivalent of an email header, with the message content itself never leaving the original publish point, information that may never get read isn't be sent out across the wire. Theres also only one message ever sent out, of which is then propagated across the overall system (system: think of something similar to DNS with message queues) to each intended recipient whether that be a person, place, or thing. This places responsibity of bandwidth on the sender, instead of the free internet lines, enforcing a policy of responsibility which currently does not exist. The implications towards the effect on SPAM should be pretty obvious.

- By nature of the messages never leaving their publish point, conversations immediatelly become threaded by their very nature, eliminating excessive "re-sending" of the same data over, and over, and over again, something that I am sure you are aware can become pretty awful if a conversation go on for any length of time.

- Because of the required publish and expiration dates, your "inbox" gains an automatic garbage collecter, archiving expired messages or deleting them all together, based on user preferences, which can be, as you point out, granular down to every last detail of the message (sender, category, etc...)

- LLUP is build on a foundation of semantics, so dependent upon client software, your current message "view" is always contextual, enforcing, again, a simple system of work flow policy.

There are a few more, but this should give you the general pieces that should help others quickly come to understand the differences between web feeds and email.

Hope this helps!

From a private email thread

In short, Blip Messaging allows you to send out messages that are contextually focused with a start and expiration date, keywords/category as to what the message is about, a short summary, and a location which can be anything from a single entity (person, place, thing) to a group (similar to a mailing list), and/or a location (in particular Geo-based, but is not limited in scope to only Geo, and could, for example, be "addressed" to an entity in which exists in multiple locations (a franchised business, for example).

The "kicker" is that the message itself resides on a web server that you maintain control over (access rights, etc...), so instead of sending out a copy of the same email to each recipient, each recipient is provided the opportunity to access the message based on their own free choice/will. So, for example, someone can still send out SPAM, but they only would send out one message (about the size of an email header) of which the "recipients" would then have either automatic triggers set to grab a particular message of interest (based on the sender, the topic, the locale, the keyword categories, etc...), or could use contextual searching to automically locate messages of interest.

The importance of the start/expiration date is fairly straight forward: If, for example, a band were to announce a concert this weekend in the Seattle area, if you were to search for concerts in the Seattle area for the following weekend, you wouldn't want concerts for this weekend returned. This becomes particularly important if its now Monday morning and the concert has long since ended. Thing of an automatic garbage collector for the Internet, if you will.

This applies as well to your inbox. All messages *MUST* have a start date (the start date is when the content of the message become "active" such that folks can send out messages well in advance of an event and still maintain proper context as to the time frame the message is intended to be "served") and an expiration date (both can be autogenerated based on the typical "lifecycle" of a message, so the burden doesn't have to be placed on the user if the message they are sending is just a simple "Hello, how are you?" type message in which selecting a start and expiration date would be overkill. ---

From an older message to the Live-Clipboard Mailing List

So, I know you all can see the obvious connection, so yes, in fact LLUP is just PULL spelled backwards, and furthermore is, quite simply, a crossover of both push and pull styled messaging combined together to bring the best of both user choice together with the more delivery styled approach that email offers without any of the problems that comes along for the free-ride as part of email (e.g. by default, anyone can send a Blip message, so SPAM can continue to exist, but the choice is flip-flopped > I have triggers set to snag all messages that promise me Male enhancement that will… you know the rest < and as such, when a message hits the system that matches this criteria, it sucks it down to my machine -- but the message is only, in essence, the equivalent of an email header... the message itself is stored in either the users publicly accessible web-share folder or an or somewhere else that the user has access to both post the message, as well as host the requests for that message (and if desired, implement secure control of that content.)*

The point? Instead of 10 million spam messages, one message is sent to a server that is willing to propogate such messages, but it points back to the originating server to gain the actual content placing responsibility of bandwidth on the sender of the message, instead of the free internet lines at our cost instead of theirs = user choice and massive reductions in bandwidth and overall cost.

One important note: LLUP implements start and expiration dates for the related content e.g. If an event takes place tonight, you don't want it returned in your search results tomorrow morning for "concerts in Seattle this weekend" Nor do you want last weeks sale items from your local grocery store as part of this weeks offerings only to find out when you arrive its not on sale anymore, etc.... Of course this has to do with LIVE-CLIP how? They go hand in hand, and in fact if you visit http://extf.net you will discover an interface that looks a bit different than the last time you visited. (unless you have visited in the last 12 hours, then no... its not any different The ability to copy and paste meaningful content from one message to another is of obvious value in the world of messaging... Some pics from your space on MSN Spaces into a message that you want to send to your family... A list of contacts from a group at work that relates to a particular project you are both working on, etc... etc.. etc..

EXTENDED NOTE:

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

Oh, and please share :D –

[1] no more copying things into your sent folder, no more need to store copies of messages on an IMAP server, no more concerns with “data lockdown” (as long as you choose a blogging tool/service that gives you easy in/easy out access to your blog entries. Most do, some don’t), no more cluttered inbox from hell (the start/expiration dates clean out your inbox for you… its up to you if you choose to archive expired items, or delete them altogether, but your inbox in and of itself gains a built in “Garbage Collector” that remains fresh with only the messages that are currently in context with the chosen date range, category, and location filters.

[2] e.g. SOAP, SMTP/XMTP, XMPP/Jabber, WCF, REST-styled APP extension, some other protocol you prefer/invent thats better than these, etc…