It's been a long time that we haven't updated this list, shame on us. But
it doesn't mean we have given up on LLUP, quite the opposite.
Nonetheless I feel like it's time for to refresh the memory of the good
people subscribed to this list about the ideas behind LLUP.
1. In a nutshell
LLUP, Limited Lifetime Ubiquitous Protocol, is a protocol based on the
exchange of messages called blips within a network of LLUP nodes.
A LLUP network is just a cloud of nodes that are able to accept and
propagate blips. A node that main task is to dispatch new blips is called
a producer. A node that mainly consumes blips is called a consumer,
clients can subscribe to a consumer or be consumers themselves, in the
former case the subscription could be an Atom feed, an XMPP PubSub node,
etc.. Nodes that accept and propagate blips in equal measure are called
The purpose of a LLUP network is to transit a blip through those routers
until one or two of the following conditions are met:
1. The blip reaches a consumer
2. The blip lifetime is not yet over
The role of each router is to apply a set of filters to fulfill those two
rules. When a consumer gets a blip, it knows it is relevant and not dead.
The idea behind LLUP is simple: offer a way to notify the creation,
modification or deletion of a resource located by a URI while giving the
chance for intermediaries to decide in an automated fashion the processing
of that notification.
A blip is a message format containing the following kind of information:
- the type of operation on the resource
- the URI identifying the resource to which the blip relates to using the
- a start, end and expire datetimes defining the life span of the resource
and the blip
- a way to describe a taxonomy, or just to tag a blip using the
- a geo-localisation of the resource using one of the existing geo namespace
As you can see a blip is capable of identifying and describing a resource
as well as placing it in space and time. All this means that a blip is
self-describing and standalone. A blip doesn't relate to other blips. It's
a simple message with meaning on its own.
Note that we have decided to re-use existing and well understood elements
from existing formats such as Atom, Dublin Core or georss rather than
coming up with new ones (although we have some elements belonging to the
llup namespace, but those are limited to handful and straightforward).
However we have decided not to make a blip an atom entry per se as there
would have been too much noise and waste of bandwith in terms of unused
elements. It is possible of course that iterations of LLUP show that we do
need to add more elements.
Note also that the term taxonomy is quite loosely used here. Our goal is
not to create yet a new taxonomy model but rather provide a very simple,
yet straightforwad mechanism to make the semantic of a blip as rich as it
may need to be. M. David Peterson sensibly noticed that the
term+scheme+label triplet of atom:category could well remind the RDF
triplet without having its entire model as a payload.
Finally, a blip is not solely XML. We will define the elements but the
data could well be carried in a JSON or binary format, as long as both the
receiver and the transmitter understand each other.
In a LLUP network a router is in charge of filtering a blip based on its
metadata. Each router implements its own logic and this is not defined by
the protocol. The only decision that a router must make is whether or not
a blip can continue its course within the network. If the filtering fails,
then the blip is stopped.
That's an interesting approach against spam to a certain extent because a
router could decide that a blip is actually spam and simply drop the
message, avoiding the consumer to be polluted.
5. Protocol agnostic
LLUP is simple and works because it is protocol agnostic. We have been
asked why we weren't using XMPP and its PubSub extension for instance.
Well an XMPP message is only one potential carrier for blips. We did not
want to be tied to one single protocol for the following reasons:
* That simplifies the adoption of the format and protocol. Not everyone
uses XMPP, BEEP or AMPQ. Besides those may be easy to scale on an intranet
but are not so easily deployed and spread on the Internet itself. The
Jabber commity has to push hard these days to integrate AtomPub and XMPP,
which I think is fantastic, but also shows that XMPP has a very high entry
* That allows for routers to demultiplex the propagation of a blip to
different protocols. A router could accept blips using a web service but
dispatch the blip using XMPP or a internal home made network protocol.
* Allows the protocol to be more resilient to the mess that is the
Internet. There is no way around it, the Web cannot be structure as neatly
as some people would love to. So instead of fighting a growing organism,
you should embrace it and go with the flow. LLUP tries to stay out of the
way of how people want to implement the web as much as it can while
offering enough service to justify its use.
In other words, the core of LLUP does not care about whether or not you
use SMTP, XMPP, SMS or HTTP to carry a blip as long as the entity to which
you send it to understand what you are trying to do. It's a gentlemen
That being said, once the core of the protocol is defined, some extensions
ala XMPP will come up for particular cases.
6. Transcient or persistent?
We have long pushed for the idea that each router must keep every single
blip it receives until it expires. This allows for all kind of added
features. However LLUP does not define how each router decide to store
blips, in fact a router might decide not to store them at all. For now,
this is still an area that needs testing and experience.
7. What for?
Well basically anything where you would have wished to be able to:
1. Break that 1-to-1 relationship between the resource and the consumer of
that resource, providing therefore a place for intermediaries.
2. Push the notification to a cloud knowing that it will either be taken
care of independantly from the resource itself.
3. Do any of these things without RDF ;-)
8. What next?
We have written some LLUP network mockup and they worked just fine, we are
about to write a major LLUP service that will be open source and much more
Nonetheless there are still some questions open for discussion, for
instance currently there is no "system" or "command" style messages
allowing for nodes to communicate on their capabilities. There is also no
message delivery mechanism defined for now and I'm personally not sure
this would be a good idea anyway.
I hope these few words have clarified again what was LLUP and sparkled
some ideas in your minds about where and how to using it.