On Sat, Aug 19, 2000 at 04:51:56PM -0400, Michael Wiktowy wrote:
> In sample.freenetrc that gets copied over to my regular .freenetrc:
> 
> -----
> # A list of keytype number class pairs for plugin keytypes
> keyTypes=0101 : Freenet.keys.KHK
> -----
> 
> Are the other keytypes supposed to be listed in here too?
> I inserted a few SVKs and they inserted and requested fine eventhough SVKs 
> are not listed.

The list is is for plugin keytypes, there is a static list in the Core
file on the keytypes supported when your code was compiled. The list is
there so people can plug in more keytypes without having to recompile.

> I tried a KHK (which I know are depreciated but are the still supported?) 
> with the command:
> -----
> java Freenet.client.BRequest -htl 1 freenet:KHK at index index.request
> -----
> and got a "Could not parse the provided URL" error.
> If they are not supported at all, why is this still in the .freenetrc?

Because it didn't magically disappear. Anyways, that lists concerns the
node (which still has KHK support), not the client which doesn't even read
.freenetrc.

> Should we reinitiallize the store_19114 (since I noticed that the format has
> changed and that new keytypes get plopped on the top while retaining the old 
> KHK stuff)
> and wipe out all the data files in .freenet (since everything seems to be 
> going in a
> subdirectory now)?

When moving from 0.2 to 0.3 you have to wipe the datastores, yes. The
routing has changed so the data on your node would not be found anyways.

> This spring cleaning hinges on being able to use these files via KHK requests.
> It would be nice to provide KHK support for this release so that people can 
> generate
> scripts that transfer all the old KHKs over to new KSKs.
> Then kill the KHKs and clean the .freenet directory in the next release.

KHKs are a security risk.

> I ran into my first instance of KSK squatting ... freenet:KSK at hello is 
> taken up by
> someone within 5 hops of me :]
> KSK at hello.mw contains a reference to my CHK that has my greeting in it :]
> You can try sending a file containing hello followed by two carrage returns
> to see if the CHK conflicts.

It is not someone within 5 hops of you, the data is within 5 hops of
you. This is not Gnutella, your own data is not stored locally.

> Are you planning to support stdin/stdout instead of filenames for the CLI 
> client?
> When I didn't include a filename it just spit out its commandline options.
> When I tried a dash as the filename it just saved it to a file called "-"
> (which is very hard to view with cat or less btw :])

It needs a file (the data is passed over two to three times), so the only
way to do that would simply be to copy STDIN to a file, in which case the
user could just do it himself.

cat hello.txt | java Freenet.cleint.BInsert CHK@ -

would do the exact same thing as 

cat hello.txt > lala.tmp ; java Freenet.client.BInsert CHK@ lala.tmp ; rm
lala.tmp

And the same thing goes for request.

If people really want that I suggest somebody write it into the shell
script as that is a lot less complicated then doing it in java.

> I'm not sure why my node burps the following out to the console periodically
> quite a bit after I run it in the background:
> 
> -----
> Freenet.node.StandardMessageHandler at 74f7c400
> LALALAL
> -----
> 
> A heartbeat, of sorts?

Just my debug stuff. I'm pretty sure that is gone now.

> Otherwise, build and installation went smoothly.
> Although the first time building there were no errors and subsequent times 
> gives:
> 
> -----
> Building Freenet server... Note: message/Echo.java uses or overrides a 
> deprecated API.  Recompile with "-deprecation" for details.
> 1 warning
> Done
> Building Freenet command-line client...
> Done
> -----
> 
> Which is not critical but I just found it odd that it didn't do it the first 
> time.

It's an old test class that is not used. I'll probably remove it.

> It seems to use nodes.config properly since I am using a node behind a 
> firewall
> going through a firewall node that is using inform0.3.php.
> The first time that I set it up I forgot to turn off the inform0.3.php usage. 
> The
> resulting inserted file didn't show up on my firewall node. When I killed the 
> internal
> node and made it depend on the nodes.config, subsequent inserts are showing up
> on the firewall node.
> 
> The /freenet/bin freenet_insert/freenet_request wrapper needs to be redone to 
> point to
> the BInsert/BRequest clients
> (or, like Oskar was saying, replace the ClientInsert/ClientRequest with these 
> new ones)
> 
> Great job guys ... I will continue to exercise it. Hopefully there is a nice 
> GUI to go with
> the 0.3 distribution.
> 
> Mike
> 
> 
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
> 

-- 
\oskar

_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to