Re: [dev] [quark] patch

From: Szabolcs Nagy <nsz_AT_port70.net>
Date: Sat, 5 Feb 2011 13:45:07 +0100

* Robert Ransom <rransom.8774_AT_gmail.com> [2011-02-04 18:56:48 -0800]:
> > -> GET /key#hash-of-data HTTP/1.0\r\n\r\n
> > <- [waiting..]
>
> The server will never see the fragment identifier (the "#" and text
> following it).

there is no such restriction in http nor in urls
(it's not a reserved character)

your browser strips fragments away, which is good: we don't want
to use this protocol from a browser, but if you insist on using one
it's better not to keep the connection open but reply immediately
(this is one of the reasoning behind using #)

altough i might choose another character (in case proxies etc
do not handle it properly), the separator does not really matter
much

> > communication here the communicated data does not know its destination)
>
> But the server does.

the data you put somewhere is (x,data) the
server sees (hash(x), encrypt(data,x), yourip)
neithr yourip nor hash(x) is stored
only hash(hash(x)) and encrypt(data,x) is stored

of course if a server keeps track which client requested which
keys then it can associate the communicating parties

but that will be solved with replication: if data does not know
its destination and is only identified by a key then it can be
replicated without issues. there will be no single server which
knows the source and destination as well

eg clients sitting behind a router requesting the same data
do not necessarily connect to a server: the router can cache
the data (integrity and authenticity of the data can be easily
verified, the freshness is more difficult (eg add timestamp
and expiration?))

full replication is of course not simple to implement efficiently
especially with notifications in mind, but this part is not
designed yet
(at this point you can use simple mirroring techniques for replication
and polling for notification like in rss feeds)

(btw tor is not very useful here: it adds encryption layers
during routing we don't need, and in the end sends the original
data to the original target, so it needs to know the data and
target, we only know the (already encrypted) data, there is no
target.
we don't want strong anonymity guarantees at this point, only privacy.
tor only gives anonymity iff the entry and exit nodes are not
compromised)
Received on Sat Feb 05 2011 - 13:45:07 CET

This archive was generated by hypermail 2.2.0 : Sat Feb 05 2011 - 13:48:03 CET