On Jan 26, 2008 2:12 PM, <bbackde at googlemail.com> wrote: > On Jan 26, 2008 12:55 PM, Michael Rogers <m.rogers at cs.ucl.ac.uk> wrote: > > bbackde at googlemail.com wrote: > > > Maybe it would help if we would be able to retrieve a KSK without to > > > retrieve the underlying CHK. Then we could check the underlying > > > CHK at .... key if we already know this key. In this case we could choose > > > to not to retrieve the CHK and therefore stop pushing the request > > > stats for this CHK? I don't know if this makes any sense. > > > > If we've already retrieved the CHK it will be in the cache, so > > retrieving it again won't do much except pull it to the top of the > > cache. But I think you're onto something - is the signature in the KSK > > or the CHK? If it's in the KSK, maybe Frost could check the signature > > and choose not to retrieve the CHK if the message won't be displayed > > anyway (eg the identity's status is CHECK and the user has configured > > that board to hide CHECK identities)? > > If you mean the signature that Frost creates and checks, its of course > in the data, in the CHK. > I don't know if there is a signature or filehash in the KSK, but I > know that we can't retrieve > a KSK or its properties via fcp2 currently. When we retrieve a KSK, > the CHK is always retrieved > and we only get the data. There is no way to store or retrieve > application data inside a KSK (or CHK).
Doesn't the KSK have metadata that you can look at? Shouldn't the metadata do the actual redirect? Does there exist an option in the node to see this that could be exposed to FCP? -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080126/acc39837/attachment.html>
