This is actually a proposal for the gnutella protocol but I thought I'd start here to see if it has any traction. This proposal is similar to an idea I had about the CDDB a few months back. Rather than depending completely on one centralized database or another I was intrigued with the idea of using a modified gnutella broadcast query/response to do a lookup. First there has to be a way to distinguish (XML?) a search for metadata rather than the actual file. If a node receives such a query and does not have the metadata it would forward it to its other connections. If it does have the metadata it would send a query response packet with the metadata. The modification would be that rather than forwarding the query (assuming TTL > 0) it would always drop the query since it was supplying a response. The idea is to limit the volume of the response packets since they are likely to be largely redundant.

When I made this proposal for CDDB style metadata it was not met with a ground swell of approval. People correctly noted it might lead to considerably more network traffic and the metadata being moved is not entirely complementary to the files (it only applies to CD audio files and files derived from them).

In this case the metadata applies to all the files one might find on the gnutella network. One might expect a gnutella client to maintain metadata about the files it is serving and possibly even about files it has that are not being served.

Whatever the case is in the long run, we certainly would want to use the services of bitzi to get this process off the ground.

This idea is very much in line with what we'd like to help enable.

In particular, and as you'll remember from my O'Reilly presentation, we'll be publishing freely-redistributable XML "Tickets" full of our best available information, which map one-to-one with files.

We want these Tickets to be shared alongside files (like old BBS .diz files) and used to help rank/display different file options locally. It's also conceivable that their contents could be queried, via XML templates like the LimeWire extended-query proposal, so that certain queries would return a bunch of blocks of candidate metadata (ie Tickets) separately from files themselves.

So yes, I think this idea has traction and could mesh well with both LimeWire's XML query syntax and Bitzi's forthcoming metadata-publishing.