On Sun, Jun 03, 2001 at 03:40:58PM -0400, Tavin Cole wrote: > > 1) is an inevitable consequence of any improvement to Freenet > > functionality, > True, but this is something that can be cleanly separated from the > requirements for implementing a "Freenet" node.
Which is essentially semantics. > > and is countered by the fact that itegrating this > > functionality into Freenet means that there will be more nodes capable > > of providing this search functionality, which will be good for the > > network. > > I think you will have to prove that. I think it is obvious that the more people who run nodes which support this searching functionality the better it will be. > This system will certainly require > some kind of web of trust rankings system to provide useful search results. Not nescessarily, both Gnutella and Napster get along without them. > You won't be able to stop searches on the first hit like you can when > searching for a Freenet key, so the topological requirements of the > network may become different, and in any case, you will be dealing with > a different set of challenges regarding bandwidth usage and caching. I think that results will be interesting, but with the exception of allowing multiple search responses (each of which will be cached probabilistically I guess) it is largely the same as the current mechanism, but with a more sophisticated closeness function. Of course there are questions, as there were (and still are) with Freenet, but I think that there is a good enough chance it will work to make it worth trying. > It's really a very different animal and it could be horrible for the network, > just as it could be good. It should be designed so as to have no effect on the current network, good or bad (an isolated section of the datastore, or a separate datastore altogether). Ian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20010603/b51c176c/attachment.pgp>
