>From Brandon <[EMAIL PROTECTED]>
>> where the KSK@ is implied in the second case? Are we going to allow the
>> mapkey to be a redirect? That would be good, since it would provide for
>> secure date-updated mapkeys.
>How do you mean? The KSK is everything before the // (search from the
>end. the thing after the // can't have a // in it, but the KSK can).
MSK@KSK@some_ksk//some_item
KSK@some_ksk is a dated redirect to SSK@(pubkey)/map
so when you request the key, it gets transparently (and securely) translated
through a date updated copy of a map.
>> Speaking of which, I'm debugging an automatic date-based redirect
>> implementation for the Fred client as we speak...
>
>The one we semi-agreed upon, I hope. :-)
Which one would that be? :) Anyway, yes, I think I mostly follwed the
consensus on the list, although many implementation details needed to be
added, of course. My date-updated redirects take the form:
Redirect
baseline=20000101000000
increment=86400
End
(key)
where 'baseline' is the starting date/time and 'increment' is the rate of
updates (in seconds). This prepends '20001226000000-' (the most recent date
that is baseline + a multiple of increment) to the human-readable part of key,
and treats it as a normal redirect from there on in.
--
Benjamin Coates
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
