As long term fellow i had some experience with the "monster".
I think Freenet should have a rather simple arithmetic design - besides
the fuzz with randomization, tunnel hops and routing.
We have Keys, and we have Nodes. A Node's fingerprint is the attractor
position in the keyspace (if you don't like your spec, remove the
"node" file).
diff(Key1,Key2) = bit_count_of_ones ( Key1 XOR Key2 );
(this is my special nag because i don't like one-dimensional keyspaces)
Sounds like other nodes know what your "natural" specialisation is.
Specialisation of the Nodes is extended by the successful retrieved
keys (that is the private part of the routing assumptions).
The long term knowledge consumes far too much memory; forget all nodes
not responding for X days! Freenet gets more dynamic when new Nodes
(behind a firewall) have some connections and their prior spec offers
them the honour to serve requests.
Does that routing assumptions say anything to plausible deniability? You
did not choose yer Node ID - you got a random.
Second scope: connection count. Multiplexing carries more payload,
especially good for low bandwidth.
The connection count option has the potential to be the first thing to
be chosen by the first time user :-)
Third scope: data compression for unencrypted content. We do not want
air being transported in big containers. Maybe some finer granule in
container sizes.
Probably 1.1 scope: break that monster into server and client and give
fproxy freedom :-) that is maybe the only point in .jar-files - they
have no strict main(). Besides, is there no way to load freenet-ext.jar
etc. into VM by the way with java? That would be a great way to fork a
node out of a decent VM inside the browsers sandbox or permanent by
telling it to!
just my 2 euro-cent.
_______________________________________________
Tech mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/tech
