Sending two replies, with an updated proposal in the second.
On 11 December 2017 at 18:38, teor teor2345@gmail.com wrote:
It should make the file available at http://<hostname>/tor/status-vote/next/bwauth.z
We shouldn't use next/ unless we're willing to cache a copy of the file we actually used to vote. If we do, we should serve it from next/ as soon as we vote using it, then serve it from current/ as soon as the consensus is created.
If we don't store a copy of the file, we should use a different URL, like status-vote/now/bwauth, and recommend that the file is fetched at hh:50, when the votes are created. This would allow us to implement current/bwauth and next/bwauth in a future version.
Sure.
Have you thought about versioning the URL if we have multiple flavours of bwauth file? We could use bwauth-<FLAVOR> like consensuses.
For lack of a better name I'll propose bwauth-legacy?
Also, Tor has new compression options for zstd and lzma.
Given that this is an externally-controlled file, we could stream it from disk and compress it on the fly with something cheap like gzip or zstd.
I haven't seen any indicated in dir-spec how to handle those? Or how I should change the proposal to accommodate them? Should I make the url .gz and say that the DirAuth should compress it and stream it from disk?
The raw bwauth vote file does not [really: is not believed to] expose any sensitive information. All authorities currently make this document public already, an example is at https://bwauth.ritter.vg/bwauth/bwscan.V3BandwidthsFile
How large is the file? Maybe we should pre-compress it, to avoid CPU exhaustion attacks. If we did this, we could say that it's safe, as long as it is smaller than the full consensus or full set of descriptors.
~2.6MB. See above.
-tom