[tor-dev] Revising Proposal 140
nickm at alum.mit.edu
Thu May 1 13:37:12 UTC 2014
On Thu, May 1, 2014 at 4:02 AM, Daniel Martí <mvdan at mvdan.cc> wrote:
> Hello everyone,
> Last week I introduced myself  on this list, shortly after being
> accepted into GSoC to work on Consensus Diffs. My GSoC proposal is
> heavily based on the Tor proposal #140 , which is close to being six
> years old now.
> This is why, after some discussion with Nick, Sebastian and Weasel (the
> original author of the proposal), it became obvious that it needs some
> revising. Here are the improvements we discussed on IRC:
> * Microdescriptors didn't exist back then, so the proposal makes no
> mention of microdescriptor consensus diffs. We should support these
I think the only change we'll need for this case is to add URLs for
the microdescriptor consensus diffs.
One more thing to clarify:
One more idea I thought of:
- What if instead of having a special URL for downloading consensus
diffs, we have a special header that tells the directory that the
client is willing to accept diffs?
According to the proposal, the client is supposed to ask for the resource with:
HTTP/1.0 GET /tor/status-vote/current/consensus/diff/<HASH>/<FPRLIST>
where HASH is the hash of the descriptor it has, and FPRLIST is a list
of fingerprints for authority identity keys.
But what if instead the client is told to do this request with:
HTTP/1.0 GET /tor/status-vote/current/consensus/<FPRLIST>.z
X-Or-Diff-From-Consensus: HASH1 HASH2...
where HASH1, HASH2... are digests of one or more consensuses that the
client has, and the directory cache is allowed to return a diff from
any of those?
This nice thing about this approach is that the client doesn't need to
know whether the directory supports consensus diffs. If it does,
great: it will send a diff. If not, the directory will ignore the
X-Or-Diff-From-Consensus header and just send the consensus as before.
Clever idea? Silly idea?
More information about the tor-dev