There have been many proposals for avoiding and resolving namespace conflicts on this list - I'd like to add one (forgive me if this exact proposal has been made already, I haven't read every single submission to this list):
Proposal: - allow multiple (an arbitrary amount of) objects with the same key - the clients are responsible for recognizing and selecting appropriate objects to present to the user based on the content - no updates to objects are possible The ideas behind this are: - if you want to be sure about the originator and content of the object, you need some form of authentication anyway; if you want to avoid a centralized authentication system, the application (client) has to take care of this. Example: someone feeds Usenet articles into Freenet using keys such as "news/alt.test/<msg-id>". In order to prevent injection of fake articles, (s)he PGP-signs them and the application (Usenet-client using Freenet) selects only articles with the proper PGP signature. - conflicts are resolved naturally by requiring the client select the appropriate content based on his/her requirements (such as "anything will do" / "must be authenticated using mechanism XYZ" etc.). - a "web of trust" can be built on this: person A knows that person B and C are reliable people and has their public PGP keys. When looking up something, (s)he instructs the client to resolve key conflicts by preferring objects PGP-signed by A, B or C. A re-inserts the object with his/her PGP-signature attached (unless it was signed by him-/her- self already). Open issues: - PGP-signing something takes away some of the anonymity. Objects which noone will want to be associated with (illegal stuff) are more likely to disappear in a large heap of "spam" entries with the same key. On the other hand, PGP signatures can't be directly used to identify the signer (unless (s)he uses a real e-mail address). - it may be necessary to put some of the selection/authentication logic (not data such as PGP keys!) into the server to avoid large transfers for single key requests (which could return many objects, most of which might be spam). Comments? -mjy -- ***==> Marinos J. Yannikos <mjy at pobox.com> ***==> http://pobox.com/~mjy _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
