Re: [Blocks-development] Some suggestions

[Michael S. Jr. <bl...@ms...>]

I agree about mixing up the routing letters.  This sounds like a good idea.
:)

But remember that a lot of those 'inconvenient' features are very good for
security -- file advert flooding (through too much traffic) becomes less of
a problem if we don't rebroadcast file adverts so much.  Remember that this
client that just connected to you might already have four other connections
when you send your file list to him.

Leaving it as a user-configurable option is probably the best bet.  However,
maybe sometime down the road the client program should keep track of which
routes it's advertised to which connections, and not readvertise those
routes.  Also, if malicious clients become a problem someday, perhaps the
client should automatically attempt to retrieve the header and some random
blocks from a random subset of file adverts received over a link, to confirm
that the files being advertised exist...and drop the connection (and take
other measures perhaps) if many or most of the files are bogus.

--Michael Spencer
bl...@ms...


----- Original Message -----
From: "Erik Moeller" <mo...@sc...>
To: <blo...@li...>
Sent: Saturday, August 05, 2000 9:25 AM
Subject: [Blocks-development] Some suggestions


> Just a few suggestions for the coming versions after the patch.
>
> - Should the letters assigned to the IP numbers be randomly
>   picked instead of the order of their apperance? Right now,
>   the primary server is always "A". If the primary server
>   is very common (like it is right now) it is possible to
>   guess that a certain IP number reappears in the path, e.g.
>   CADDAF probably means that one of our two primaries is at
>   hop 2 and 5. I suppose encryption as suggested in the protocol
>       specs would also solve this problem.
> - adverts for the same file with different routes could be
>   summarized
> - initial handshaking should contain a version number and
>   optionally a "network name", which is sort of a password
>   that can be used to isolate networks easily. Of course,
>   this should be encrypted like everything else.
> - improved cache flushing:
>   Flushing all local files seems pretty pointless since at
>   least some of them are probably stored permanently
>   somewhere else. This is especially annoying for users
>   whose connections are cut every 24 hours, or those who
>   cannot let their PC run all day.
>
>       The solution I suggest is pretty tricky, but I think it should
>   be implemented before we go to a larger public. I suggest
>   to have two options for uploading files: "temporary upload"
>   and "persistent upload". Persistently uploaded files would be
>   stored in a separate cache that is encrypted with a permanent
>   cipher and only flushed on explicit request.
>
>   That way, you could upload your MP3 collection once and you
>   would never have to think again about it. One other advantage
>   is that the hash of the files remains the same so that there
>   are not lots of different adverts for the same files floating
>   around. Security of the other non-local files would not be
>   affected.
> - optional expiry date for adverts. The TTL limits them in space,
>   the expiry date would limit them in time. This is important for
>   files like messages, which are only relevant for a week or so
>   and should then stop circulating on the network. I don't know
>   how hard this is to do since the adverts would have to be
>   updated regularly.
>
> Regards,
> Erik Moeller
> --
> Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
> Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
> The Origins of Peace and Violence: <http://www.violence.de>
> Please donate free food NOW: <http://www.thehungersite.com>
>
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development