On Thu, May 1, 2014 at 4:02 AM, Daniel Martà mvdan@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?