gpg: Signature made Tue May 13 18:39:30 2008 UTC using DSA key ID E43DA450
gpg: Good signature from "Matthew John Toseland <toad@amphibian.dyndns.org>"
On Tuesday 13 May 2008 00:44, Michael Rogers wrote:
> Evan Daniel wrote:
> > The major change needed would be a way to request not the specific SSK
> > block, but the SSK, whatever CHK it happens to redirect to, and any
> > CHK blocks needed to decode the result
>
> Exactly, so you'd need a different protocol, different data formats and
> a different routing implementation to cope with the latency - which
> raises the question, why use Freenet instead of building a separate network?
Why would you need different data formats? Well there are two options here:
1. Bigger SSKs, big enough to contain the entire message. Bback has asked for
this for Frost, but I'm not sure what the advantage is: it would make
uploading spam slower, but it would also make downloading it slower.
2. True (non-key-based) publish/subscribe.
2. Higher level requests, as a latency/security tradeoff. These could use the
same keys, or very similar keys, but clearly they are somewhat different to
how we do things now.
In any case the client level protocol doesn't have to be much different.
Even with the same exact request semantics, hopefully your neighbours would
hopefully be subscribed to the same stream, in which case, the latency would
only be a single local round trip.
>
> > -- plus a way to prevent that
> > being a DoS attack (tit-for-tat?).
>
> How would TFT work in this context? Say Alice sends Bob a batch of
> requests and Bob doesn't find the data - does Alice punish Bob for
> black-holing the requests or does Bob punish Alice for trying to DoS
> him? What if Alice was only forwarding the requests for Carol?
>
> I have some ideas for DoS-resistant routing, but they're only suitable
> for long streams of messages between the same endpoints, and the
> endpoints need to share an authentication key. I'm not sure whether they
> could be adapted to anonymous pub/sub.
There are ways to limit the damage e.g. by only allowing a certain number of
requests at each priority level for any single peer?
>
> Cheers,
> Michael
