[tor-dev] [RFC] Directory structure of prop224 onion services
twim at riseup.net
Wed Feb 1 00:47:11 UTC 2017
On Wed, Feb 01, 2017 at 09:36:54AM +1100, teor wrote:
> > On 1 Feb 2017, at 01:36, David Goulet <dgoulet at ev0ke.net> wrote:
> > On 31 Jan (09:02:35), teor wrote:
> >>> On 27 Jan 2017, at 01:58, David Goulet <dgoulet at ev0ke.net> wrote:
> > However, there is kind of an issue rising from this. Imagine that v4 changes
> > the onion address format because new crypto. We'll end up with a problem where
> > the how to extract the version from the address is actually version
> > specific... A solution to that is that "whatever size/encoding the address is,
> > version will ALWAYS be the last 1 byte."
> > Thoughts?
> I think it is a good idea to make the version the last byte of the
Sure, if stays here it's effectively a version suffix (label). Another
version will imply address length, encoding, checksum, etc.
> But I also think that a version file is a good idea to make it easy for
> applications to discover the on-disk version.
> Otherwise, the algorithm would have to be something like:
> * look for a hostname file
> * read the first line
> * find the address in that line
> * if the address is N characters long, version 2
> * do we promise we will never have addresses this long in future versions?
> * base32 decode that line
> * do we promise addresses will always be base32?
> * read the last byte
> * do we promise addresses will always have the version in the last byte?
This entire idea to do something for some apps to detect onion service
version "just by looking at disk" looks like a feature creep to me. Why should
we bother at all while we have onion address that is self-descriptive?*
It's not a big deal really to parse onion address from a 'hostname'
file. Especially for an app that wants to know the protocol version (what
Personally I belive that there are no(t so many) apps that would
mess with onion services without using an onion-related library such
as stem which will make it as simple as one function call over
[*] Yeah, for that there should always be Base32 and version byte at the
More information about the tor-dev