Emphasize + Oembed + open § API = open frontend model for metaweb annotations?

[Mushon Zer-Aviv]

I know we've been quiet lately.

And I know the fact I left you guys behind in a horrible winter for the pleasures of eternal sunshine for blindspot minds might have a bit to do with it.

But maybe some of you guys might be interested in bouncing this idea around...

1. Emphasize:

Jonah first brought up Empahsize which was developed by the NYTimes team that David works for. What's great about it is that it is a method for addressing a string on the page based on (seemingly robust) frontend content analysis that would be pretty durable in case of DOM changes.

2. OEmbed:

Is this emerging standard for embedding web services. The way it works is that urls to embeddable services such as YouTube are converted to the actual embed script so there is no need for convoluted embed code and even browsers that do not support embedding (or Flash in YouTube's case) can still be referred to the url. WordPress have supported OEmbed for several versions now, so it is being popularized and new services such as Embed.ly (yet another service paying domain registration to Kadafi) are extending the support and are providing OEmbed based services.

3. §:

We want to do as little as possible. Especially since over the last few years we've been trying to do way more than we can maintain or deliver. If we could provide a frontend only API that turns something like this:

http://open.blogs.nytimes.com/2011/01/11/emphasis-update-and-source/#p[EskTut],:after[http://youtu.be/Sum_5GdvFG0]

into this (imagine it's inline, just after the p):

http://www.shiftspace.org/api/sandbox/?id=441d

Then we're building a pretty flexible API that can be extended with or without running a ShiftSpace server.

I'm thinking :after, :before as in css selectors.

Obviously the url can reference a JSON file and then many other things can happen from there, but the basics can happen via a userscript or an embedded JS with no serverside at all required.

Thoughts?

--

Mushon Zer-Aviv
Shual.com - design studio
§  ShiftSpace.org - an opensource layer above any website
¶  Mushon.com - blog
× @mushon - Tweet me

[Digital Brandz]

Thoughts? Hurry up and do something

On 3/5/11, Mushon Zer-Aviv <mus...@shual.com> wrote:
> I know we've been quiet lately.
>
> And I know the fact I left you guys behind in a horrible winter for the
> pleasures of eternal sunshine for blindspot minds might have a bit to do
> with it.
>
> But maybe some of you guys might be interested in bouncing this idea
> around...
>
>

> *1. Emphasize:*

>
> Jonah first brought up Empahsize

> <http://open.blogs.nytimes.com/2011/01/11/emphasis-update-and-source/#p[EskTut],h[EskTut]>

> which was developed by the NYTimes team that David works for. What's
> great about it is that it is a method for addressing a string on the
> page based on (seemingly robust) frontend content analysis that would be
> pretty durable in case of DOM changes.
>
>

> *2. OEmbed:*

>
> Is this emerging standard for embedding web services. The way it works
> is that urls to embeddable services such as YouTube are converted to the
> actual embed script so there is no need for convoluted embed code and
> even browsers that do not support embedding (or Flash in YouTube's case)
> can still be referred to the url. WordPress have supported OEmbed for
> several versions now, so it is being popularized and new services such

> as Embed.ly <http://embed.ly/> (yet another service paying domain

> registration to Kadafi) are extending the support and are providing
> OEmbed based services.
>
>

> *3. §:*

>
> We want to do as little as possible. Especially since over the last few
> years we've been trying to do way more than we can maintain or deliver.
> If we could provide a frontend only API that turns something like this:
>
> http://open.blogs.nytimes.com/2011/01/11/emphasis-update-and-source/#p[EskTut],:after[http://youtu.be/Sum_5GdvFG0]
>
>
> into this (imagine it's inline, just after the p):
>
> http://www.shiftspace.org/api/sandbox/?id=441d
>
>
> Then we're building a pretty flexible API that can be extended with or
> without running a ShiftSpace server.
>

> I'm thinking :after <http://www.w3schools.com/css/sel_after.asp>,
> :before <http://www.w3schools.com/css/sel_after.asp> as in css selectors.

>
>
> Obviously the url can reference a JSON file and then many other things
> can happen from there, but the basics can happen via a userscript or an
> embedded JS with no serverside at all required.
>
>
> Thoughts?
>
> --
>
> Mushon Zer-Aviv

> ע Shual.com <http://shual.com> - design studio
> § ShiftSpace.org <http://ShiftSpace.org> - an opensource layer above any
> website
> ¶ Mushon.com <http://mushon.com> - blog
> × @mushon <http://twitter.com/mushon> - Tweet me
>
> --
> You received this message because you are subscribed to the Google Groups
> "ShiftSpace-dev" group.
> To post to this group, send email to ShiftSp...@googlegroups.com.
> To unsubscribe from this group, send email to
> ShiftSpace-de...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ShiftSpace-dev?hl=en.
>
>

--
Sent from my mobile device

[Doron Ben Avraham]

It sure has been quiet.
I would like to address the topic of silence before we talk about the
merits of the ideas that Mushon wrote about (all elegant and useful btw).
If I generalize here, in a way that makes any of you feel I make broad
strokes in place of subtlety, I apologize, and please correct me if I am
in the wrong. It will be a semi long rambling, longer than a tweet, hope
you will find the time to read.

There are several reasons why � is dying, this happens to many different
projects, we are all familiar with this process. The question is, can it
be revived and under what conditions.

The most obvious reason is that we are all very busy. Our lives revolve to
a large extent around very demanding work, and I wager that the mental
requirement for a project with no specific goals, nor obvious yield, is
draining, confusing, and doesn�t lend itself to our individual and group
aspirations. Put simply, it is allot, maybe too much, to ask anybody to
sacrifice the small amount of time they have to this project at its
present state. We all grew a little tired.

Another reason is that the platform has grown in complexity to the extent
that it doesn�t hold an attraction to the developers that we have long
tried to position ourselves as cool platform for them to have and
implement. I am reminded of the occasion that David and myself debugged
performance issues on the testing server/couchdb stack. It was fun, It was
also highly specialized, we examined protocol actions, socket behaviors
etc� and it yielded positive results, but it has also proven that the
requirements for figuring out solutions for this platform at this stage,
are not in the realm of your common web developer, the very people we want
to attract. We have built a complex and exotic system, built on fairly
exotic parts, very far from any KISS model, a little daunting, and
requires the result of different disciplines (or a very well rounded
hacker) working on a problem.

When we look at NYTimes, as well as at MoMA, it is clear that � lives in
spirit, if not in actual methodology and snippets of code on those sites.
So there is an obvious business value to what the platform does, and could
do. But with clear caveat. In both cases there is a defined clear
infrastructure that supports and runs the platform elements, there are
clear defined goals as to where and why they are used. I had a
conversation some months ago with Dan that stuck in my mind, Dan posited
that while we mused about possible angles by which � can be used as a
possible business, we did not account for the infrastructure required to
keep it running and maintain development on it, this point struck me as
absolutely correct.

I think we have focused on certain elements of the open source practice
which we are enamored with ideologically, and underplayed or ignored
business practices that could be of value to this venture. Perhaps it is
out of our element (I know it is out of mine) but it would seem to me that
there is a room here for investment at business model that can be created
(heck there are many bullshit web startups that get capital investment now
offer far less potential value,).

If there is demonstrated cases (which there are) of use to this platform,
then there is a value proposition that can be defined and possibly
monetized, I�m sure we could all do much better if there was a possible
angle by which we can make money out of this, I hope I don�t offend
anyone sensibilities by claiming that money is a great motivator to get
shit done. After all we all need to pay our rents.

Perhaps the model we are looking for is similar to
wordpress.com/wordpress.org. A business end service provider, and a
developer community outlet. Perhaps it is a different one. But the point
is this, For the project to continue, and reach its potential, we need to
have a business strategy developed beyond coding and feature adding, as it
stands now it is clearly not sustainable. We have reached this far, We
don�t need to attract more development resources now, if anything, we need
business development expertise. the utility of � can be demonstrated, we
need expertise to craft a strategy, define goals, seek a market.

D

[Doron Ben Avraham]

[David Nolen]

On Sat, Mar 5, 2011 at 8:11 AM, Mushon Zer-Aviv <mus...@shual.com> wrote:

I know we've been quiet lately.

And I know the fact I left you guys behind in a horrible winter for the pleasures of eternal sunshine for blindspot minds might have a bit to do with it.

But maybe some of you guys might be interested in bouncing this idea around...

1. Emphasize:

Jonah first brought up Empahsize which was developed by the NYTimes team that David works for. What's great about it is that it is a method for addressing a string on the page based on (seemingly robust) frontend content analysis that would be pretty durable in case of DOM changes.

I like this project. I don't use it much since it's limited to the Times and there's little social discovery component (as none of my friends use it).

 

2. OEmbed:

Is this emerging standard for embedding web services. The way it works is that urls to embeddable services such as YouTube are converted to the actual embed script so there is no need for convoluted embed code and even browsers that do not support embedding (or Flash in YouTube's case) can still be referred to the url. WordPress have supported OEmbed for several versions now, so it is being popularized and new services such as Embed.ly (yet another service paying domain registration to Kadafi) are extending the support and are providing OEmbed based services.

This interesting, but the scope seems quite limited right? Content consumption.

 

3. §:

We want to do as little as possible. Especially since over the last few years we've been trying to do way more than we can maintain or deliver. If we could provide a frontend only API that turns something like this:

http://open.blogs.nytimes.com/2011/01/11/emphasis-update-and-source/#p[EskTut],:after[http://youtu.be/Sum_5GdvFG0]

into this (imagine it's inline, just after the p):

http://www.shiftspace.org/api/sandbox/?id=441d

Then we're building a pretty flexible API that can be extended with or without running a ShiftSpace server.

I'm thinking :after, :before as in css selectors.

Obviously the url can reference a JSON file and then many other things can happen from there, but the basics can happen via a userscript or an embedded JS with no serverside at all required.

Thoughts?

--

Without some kind of server (centralized/decentralize) how would non-expert users put their content in the right place?

David

[David Nolen]

Doron,

Thanks for thoughtful post! :)

On Mon, Mar 7, 2011 at 11:59 AM, Doron Ben Avraham <do...@transorma.com> wrote:

There are several reasons why § is dying, this happens to many different
projects, we are all familiar with this process. The question is, can it
be revived and under what conditions.

I think it can be revived (even easily) but I admit, I need a break from the project.

 

Another reason is that the platform has grown in complexity to the extent
that it doesn’t hold an attraction to the developers that we have long
tried to position ourselves as cool platform for them to have and
implement.  I am reminded of the occasion that David and myself debugged
performance issues on the testing server/couchdb stack. It was fun, It was
also highly specialized, we examined protocol actions, socket behaviors
etc… and it yielded positive results, but it has also proven that the
requirements for figuring out solutions for this platform at this stage,
are not in the realm of your common web developer, the very people we want
to attract. We have built a complex and exotic system, built on fairly
exotic parts, very far from any KISS model, a little daunting, and
requires the result of different disciplines (or a very well rounded
hacker) working on a problem.

Simple services != simple platform. Was attracting common web developers ever a goal? I thought it was to attract *users*. We also designed the platform in such a way that *hackers* (developers of Spaces) would be interested.

Even the 0.16 branch assumed a certain level of backend expertise. In anycase, even now, most of the complexity is not in the backend. It's entirely frontend.

 

Dan posited
that while we mused about possible angles by which § can be used as a
possible business, we did not account for the infrastructure required to
keep it running and maintain development on it, this point struck me as
absolutely correct.

I did account for that. There's no more or less infrastructure then is required for what we collectively set out to build. And unlike the pre-1.0 branch, it's well documented for Windows, Ubuntu Linux, Mac OS X going all the way back to 10.4 on PowerPC and it's on a wiki so if something is wrong *anyone* can fix the documentation.

 

If there is demonstrated cases (which there are) of use to this platform,
then there is a value proposition that can be defined and possibly
monetized, I’m sure we could all do much better if there was a possible
angle by which we can make money out of this, I hope I don’t offend
anyone sensibilities by claiming that money is a great motivator to get
shit done. After all we all need to pay our rents.

Agreed.

 

Perhaps the model we are looking for is similar to
wordpress.com/wordpress.org. A business end service provider, and a
developer community outlet.  Perhaps it is a different one. But the point
is this, For the project to continue, and reach its potential, we need to
have a business strategy developed beyond coding and feature adding, as it
stands now it is clearly not sustainable. We have reached this far, We
don’t need to attract more development resources now, if anything, we need
business development expertise. the utility of § can be demonstrated, we
need expertise to craft a strategy, define goals, seek a market.

D

I'm in agreement, we don't need anymore features. And before all the business stuff, what we need is a release. However I'm loathe to release what we have even though it basically done.

A) Login still sucks (any page can see your credentials)

B) We've outgrown userscripts - loading 573k of JavaScript in every single tab in Firefox doesn't scale

A and B both require someone investigating Chrome Extension/Safari Extensions/Jetpack and coming up with a workable design that requires the least amount of change to our current code base. But this isn't a small project.

Also I'm skeptical that the proxy can scale, but someone needs to produce a test case and demonstrate what it can handle under even small loads.

As you say I've been busy with work, music, and other personal programming related studies so I haven't found the time to commit to taking this on.

David

[Mushon Zer-Aviv]

On 3/7/11 8:14 PM, David Nolen wrote:

I think it can be revived (even easily) but I admit, I need a break from the project.

So do I (think it can be revived) and so do I need a break. But I agree with Doron that reviving it would require examining our project's model, strengthening it and blowing a new spirit in its wings.

B) We've outgrown userscripts - loading 573k of JavaScript in every single tab in Firefox doesn't scale

A and B both require someone investigating Chrome Extension/Safari Extensions/Jetpack and coming up with a workable design that requires the least amount of change to our current code base. But this isn't a small project.

Tomorrow morning 10am I have a meeting with some guys here in .il that are developing a new technology called CrossRider which will allow an easy deploy for JS browser extensions across all major browsers (including IE). From what I understand it is something like PhoneGap for browser extensions. But I would learn more tomorrow and report back.

Also I'm skeptical that the proxy can scale, but someone needs to produce a test case and demonstrate what it can handle under even small loads.

I would argue that the business model that can work would require the proxy and that even a complex server setup would be worth it. What I am proposing with the setup stated in the title of this thread is that our core should be as small and elegant as possible and any other layers of complexity should be developed as additional layers above it. The Emphasis/oEmbed/§ core will do very little, but that little would be the core of what we are trying to do, and would could other developments and initiatives to grow independently.

So my point is that if we want a sustainable model, our core should be small and elegant and the complexity could (/should) be funded & monetized separately.

(I will respond to David's other point separately)

[Mushon Zer-Aviv]

On 3/7/11 7:24 PM, David Nolen wrote:

On Sat, Mar 5, 2011 at 8:11 AM, Mushon Zer-Aviv <mus...@shual.com> wrote:

I know we've been quiet lately.

And I know the fact I left you guys behind in a horrible winter for the pleasures of eternal sunshine for blindspot minds might have a bit to do with it.

But maybe some of you guys might be interested in bouncing this idea around...

1. Emphasize:

Jonah first brought up Empahsize which was developed by the NYTimes team that David works for. What's great about it is that it is a method for addressing a string on the page based on (seemingly robust) frontend content analysis that would be pretty durable in case of DOM changes.

I like this project. I don't use it much since it's limited to the Times and there's little social discovery component (as none of my friends use it).

The blogpost states that Emphasis was open sourced so it can be used by more developers, be extended as a design pattern and maybe even turn to an open standard. These things take time but if through § Emphasis could be extended beyond the times (userscript/proxy) and using Twitter/Facebook/social media for sharing and social discovery we just might be taking it in the right direction.

 

2. OEmbed:

Is this emerging standard for embedding web services. The way it works is that urls to embeddable services such as YouTube are converted to the actual embed script so there is no need for convoluted embed code and even browsers that do not support embedding (or Flash in YouTube's case) can still be referred to the url. WordPress have supported OEmbed for several versions now, so it is being popularized and new services such as Embed.ly (yet another service paying domain registration to Kadafi) are extending the support and are providing OEmbed based services.

This interesting, but the scope seems quite limited right? Content consumption.

oEmbed is indeed about Content consumption, and I'm suggesting it as a model for inviting other UGC into a page. The interface and the production of the media would not be handled by oEmbed or necessarily by § for that matter.

 

3. §:

We want to do as little as possible. Especially since over the last few years we've been trying to do way more than we can maintain or deliver. If we could provide a frontend only API that turns something like this:

http://open.blogs.nytimes.com/2011/01/11/emphasis-update-and-source/#p[EskTut],:after[http://youtu.be/Sum_5GdvFG0]

into this (imagine it's inline, just after the p):

http://www.shiftspace.org/api/sandbox/?id=441d

Then we're building a pretty flexible API that can be extended with or without running a ShiftSpace server.

I'm thinking :after, :before as in css selectors.

Obviously the url can reference a JSON file and then many other things can happen from there, but the basics can happen via a userscript or an embedded JS with no serverside at all required.

Thoughts?

--

Without some kind of server (centralized/decentralize) how would non-expert users put their content in the right place?

True, but if by supporting oEmbed we support whatever other cloud UGC services out there this is already a very wide and creative pallet (Embedly currently supports oEmbeds for 165 services). This can make the case for metaweb specific extension of oEmbed (that's where §'s API can come in) that allows for wider manipulation of the page context you're shiftin'. —M.

David

[Digital Brandz]

Who cares. Just finish the project

> --
> You received this message because you are subscribed to the Google Groups
> "ShiftSpace-dev" group.
> To post to this group, send email to ShiftSp...@googlegroups.com.
> To unsubscribe from this group, send email to
> ShiftSpace-de...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ShiftSpace-dev?hl=en.
>
>

--

[Mushon Zer-Aviv | Web & Interactive prof]

Guys,
we value your enthusiasm, but please don't troll the thread and
respect the discussion.

Thanks.

On Mar 8, 11:49 am, Digital Brandz <digitalbra...@gmail.com> wrote:
> Who cares. Just finish the project
>

[Dan Phiffer]

Hey guys,

I'm kind of proud that we matter enough to troll. Mr. Brandz, let's keep it civil, yes?

On the topic of quietness and busy-ness/business -- I think what ShiftSpace needs isn't so much money or business development, but somebody who has a need for it and is willing to scratch the itch. I know that phrase gets thrown around a lot, but I think it's true! I don't actually use ShiftSpace, except occasionally enabling it to see an old shift. Step zero for me would be building something I'd be willing to leave enabled all the time. And I agree that our fat ass userscript approach might be the first thing to discard. Let me know how the CrossRider discussion goes, Mushon.

I already have way too much on my plate, but I think about ShiftSpace all the time and it's still the business card I give out to people. I could see myself clearing out some development time for it. I like the suggestions of building something small and elegant, and since I was sitting out most of the 1.0 process I'm not in need of a break. I'm feeling more and more like it's time that I got back into it again.

Going back to the original suggestion of oEmbed and Emphasize, those are interesting technologies that should be considered. I haven't been looking into it in great detail recently, but my impression of oEmbed is that it has a fundamental trust problem. At its core it turns URLs into HTML, a kind of "managed cross-site scripting" (which is, of course, also what ShiftSpace does). XSS is considered harmful for good reason, and as a result WordPress only allows oEmbeds from a small list of sources by default, others must be added with wp_oembed_add_provider(). I think it's also turned off by default? Can't remember... I don't use it myself.

After playing around with an oEmbed provider implementation for MoMA's video pages, I contacted Alex M. aka Viper007Bond about getting on WordPress's default list of trusted domains. He said "we're trying to keep [the whitelist] lean and with just the basics that many people will use." He suggested that I write a plugin. I can imagine writing the copy for that: "WordPress users: to conveniently auto-embed our video, just install this plugin!"

Aside from WordPress being in a position of great leverage about these things, I think there's a legitimate argument that oEmbed's model lacks the essential trust revocation mechanism you'd need to do it safely. There are probably other issues too, like oEmbed phishing (e.g. "yootu.be/...") attacks, etc. Maybe this is discussed out there somewhere, maybe there's even a good solution to it. I'd be curious to hear about it. In any case, embed.ly seems to have taken Alex's advice to get into the WP kingdom: http://wordpress.org/extend/plugins/embedly/

As for Emphasize, it would be nice to use a standard(ish) mechanism for in-page addressing. Or at the very least not have to write that code over again. But I wonder if there are more important problems to tackle (aside from a lack of commits against the repo). I'm much more interested in the decentralization problem.

Yes, decentralization! I would like to take a shot at it within a "generic" PHP/MySQL web stack. Have we already discussed PubSubHubbub on here? I can't find it when I search, maybe we talked about it in person. Anyone have input about that? Should I just start hacking on this?

Best,
-Dan

[David Nolen]

On Mon, Mar 7, 2011 at 2:00 PM, Mushon Zer-Aviv <mus...@shual.com> wrote:

Tomorrow morning 10am I have a meeting with some guys here in .il that are developing a new technology called CrossRider which will allow an easy deploy for JS browser extensions across all major browsers (including IE). From what I understand it is something like PhoneGap for browser extensions. But I would learn more tomorrow and report back.

Yeah definitely interested in hearing about this.

 

So my point is that if we want a sustainable model, our core should be small and elegant and the complexity could (/should) be funded & monetized separately.

I agree with this point, but I'm not particularly convinced that Emphasis or oEmbed are particularly interesting avenues of investigation.

David 

[David Nolen]

On Mon, Mar 7, 2011 at 2:13 PM, Mushon Zer-Aviv <mus...@shual.com> wrote:

True, but if by supporting oEmbed we support whatever other cloud UGC services out there this is already a very wide and creative pallet (Embedly currently supports oEmbeds for 165 services). This can make the case for metaweb specific extension of oEmbed (that's where §'s API can come in) that allows for wider manipulation of the page context you're shiftin'. —M.

Perhaps I don't understand what you mean by "support" oEmbed.

David 

[David Nolen]

On Tue, Mar 8, 2011 at 8:43 AM, Dan Phiffer <d...@phiffer.org> wrote:

As for Emphasize, it would be nice to use a standard(ish) mechanism for in-page addressing. Or at the very least not have to write that code over again. But I wonder if there are more important problems to tackle (aside from a lack of commits against the repo). I'm much more interested in the decentralization problem.

A standard for in page address would be nice, but URLs are mucked up enough as it is. I don't see Emphasize catching on. 

 

Yes, decentralization! I would like to take a shot at it within a "generic" PHP/MySQL web stack. Have we already discussed PubSubHubbub on here? I can't find it when I search, maybe we talked about it in person. Anyone have input about that? Should I just start hacking on this?

Best,
-Dan

I'd love to see a prototype for decentralization regardless of what it's built on. But PHP/MySQL doesn't sounds like it's going to buy us decentralization in any long term. Should all clients have to install Apache/PHP/MySQL? Or does this mean there'll be hubs - so it's federation rather than real peer-to-peer?

Even Python/CouchDB is just stop gap to really solving the decentralization problems. CouchDB lets us properly model our application around decentralized documents. All the other hard problems still remain (trackerless content discovery, routing, security).

BitTorrent + the simplicity of DropBox to me is what we should be striving for.

David 

[Doron Ben Avraham]

I always thought DHT as implemented in bittorent to be an intriguing
possibility for decentralization, in particular because you can have two
models at the same time. i.e the classic Tracker/central server that has a
dataset that can be replicated across servers, and client based blink UDP
(Also useful for hole punching) distribution.

basically we could provide a server (or a number of them, that have a
replication of shift tracking, and the clients operate via a combo of
polling the trackers, and serving DHT, this will work well to for shift
generated by the user, as they will be served from its local repo

http://khashmir.sourceforge.net/
looks interesting.

> BitTorrent + the simplicity of DropBox to me is what we should be striving
> for.
>
> David
>

[David Nolen]

On Wed, Mar 9, 2011 at 2:31 PM, Doron Ben Avraham <do...@transorma.com> wrote:

http://khashmir.sourceforge.net/
looks interesting. 

Sadly that project doesn't look like it's been committed to in 6-8 years. I looked around a bit and I didn't see anything off hand that looked particularly good, recent, unbloated. Also much of what I saw didn't address security. That's why posted the link to the MIT PhD thesis.

But yes, it's an avenue of investigation we should consider.

David 

[Christian Croft]

Would something like Telehash be more along the lines of what you're looking for, David?

http://www.telehash.org/

It was created by Jabber developer Jeremie Miller and looks to be the backbone

of what could possibly become a standard platform for distributed data applications on 

the web: 

http://www.readwriteweb.com/archives/creator_of_instant_messaging_protocol_to_launch_ap.php

-Christian

[David Nolen]

On Wed, Mar 9, 2011 at 3:42 PM, Christian Croft <xnc...@gmail.com> wrote:

Would something like Telehash be more along the lines of what you're looking for, David?

http://www.telehash.org/

It was created by Jabber developer Jeremie Miller and looks to be the backbone

of what could possibly become a standard platform for distributed data applications on 

the web: 

http://www.readwriteweb.com/archives/creator_of_instant_messaging_protocol_to_launch_ap.php

-Christian

Holy crap does that look awesome.

Thanks Christian!

David