[tor-dev] Revising Proposal 140

[Nick Mathewson]

On Thu, May 1, 2014 at 4:02 AM, Daniel Martí <mvdan at mvdan.cc> wrote:
> Hello everyone,
>
> Last week I introduced myself [0] 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 [1], 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
>   too.

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?

-- 
Nick