> I thought colons were forbidden in KSKs and SSKs, because the client
> rejected my colon when I tried to insert it. I omitted the "freenet:KSK@"
> and that confused it. With the freenet:KSK@, it worked. Bleah.
Nothing is *supposed* to be forbidden in KSKs or the latter field of SSKs.
> The thing is, who's really going to use the string ":/"? You aren't naming
> your inserted keys "freenet:KSK@blah:/blah:/blah:/blah", are you?
If you want to, you can. I won't accept a proposal which limits what you
can have as a KSK although I'm okay with certain weird naming conventions
not working right with things like web browsers. If you want to work with
web browsers, you have to follow web browser conventions.
> Are you comfortable forbidding KSKs with two slashes in a row? It's
> actually much prettier than ":/". And no sane person names their files
> with two slashes in a row. It looks quite good:
No, I'm not comfortable forbidding anything in KSKs, which is why I'm
proposing a new key type. SSKs have structure and that's fine. There is a
structred part followed by an unstructured part. There are no limitations
on the unstructured part. We could do the same with a new psuedo-keytype.
I don't see why the key parsing should be modified when you could build a
perfectly discreet layer on top of the existing keys. The mapping file
isn't really conceptually part of the key in the same way that the public
key is in an SSK.
> freenet:CHK@rE9zY9IVJAqGZInGOF0d03L6ZeoOAwE,nmrAmhCGI3EBnKMALocq7A//index.html
>
> freenet:pigdogjournal//index.html
That does look nice and you make a good point. But is a new psuedo-keytype
all that bad? We might want to define some other psuedo-keytypes later and
we'll quickly run out of notation. Or maybe we won't. I dunno.
> If you saw how fast I just loaded thirty images across my network, and how
> damn sexy that // looked (I typed "freenet:mork//index.html" and WHAM!),
> you would agree with me. That's my opinion, and I'm sticking to it!
Okay, I'll admit that the // does look damn sexy. I mean really, I'm being
swayed. And you've even implemented it already. I am very tempted.
Argh. I still have the issues of design philosophy. I guess my main
problem is that I think that this sort of processing should go in a layer
above the current keytypes so that 1) we don't have to modify the current
keytypes in order to add this feature, and 2) we can add other such
capabilities in the higher level, also without modifying the underlying
keytypes.
If you have a layer of psuedo-keytypes above the keytypes then each time
you add a new psuedo-keytype it automatically works with all keytypes and
each time you add a new keytype it automatically works with all
psuedo-keytypes.
Here's another attempt at defining a syntax for psuedo-keytypes:
freenet:map:mapfilekey//mappedpath
(Using // so mappedpath can have /. You'd have to search backwards because
mapfilekey can have //. I have no problem limiting what can be in
mappedpath since we're defining what can be in a mapping file.)
In this case, map: specifies that this is a mapped psuedokey. If you
another had psuedo-keytype, say, hypothetically, a psuedo-keytype which
assumes the key was encrypted with a passphrase (I dunno why, just an
example):
freenet:crypt:passphrase/encryptedkey
I think that, in both of these examples, relative paths work fine and both
mapfilekey and encryptedkey can be an keytype whatsoever. With a little
tweaking of the particulars you could probably even all them to be
psuedo-keytypes.
I dunno, maybe this idea is crazy. I've feeling a bit addled. It's been
that kind of night.
What an exciting feature. I can't wait until we come to a conclusion on
this and people can create Freenet sites with great ease. This will
particularly help with the whole Debian project.
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
