Yes, the key type does need to be stored along with the data. However, I don't think a Insert.Data.ContentHash need to include a key at all. It just needs the data. That way it will certainly by stored under the correct key since the node will generate the key. In fact, we don't even need an Insert.Data.ContentHash, we can just use plain old Insert.Data and make the SearchKey field optional. That way you can index by CHK and KHK or just CHK.
My solution to the problem of storing the key types with the keys is to store the different types of keys in different tables. So Request.Data looks in the KHK table, Request.Data.ContentHash looks in the CHK table (or generates it if the node doesn't bother to precalculate CHKs for some reason, like no one in that node cluster uses them) and so on. No problems with key collisions. As far as key URLs go, the key type should of course be part of the URL, although i'm not sure how best to do encode it. Either free://type/key or free-type://key. I like the second because your browser will only support certain key types and having a different protocol name for each key type will make it clear what your browser does and doesn't support and will allow for modular additions of different key type handling. I think that's the browser extension right way to do things. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
