Torspec proposal for adding new X- fields to relay descriptor
URL: https://dl.dropboxusercontent.com/u/3308162/ExtraRelayDescriptorFields.txt Fulltext below. Comments appreciated. -V ======================= Filename: ExtraRelayDescriptorFields.txt Title: Adding new X- fields to relay descriptor Author: Virgil Griffith, Nick Mathewson Created: 2014-06-03 Status: Open 1. Motivation We wish to allow developers to build new applications atop relays. Towards this end, we wish to add the ability for users to specify arbitrary new key-value entries under the "X-" namespace. 2. Proposal Allow optional key-value lines in the relay's torrc file. These lines will be mirrored in the relay's descriptor which is then published in the directory consensus. The format is: X-key value For example: X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-nameid virgil.gr X-favoritequote Be excellent to each other. Party on dudes! The value field must be printable ASCII (characters 32-126). The value must not under any condition contain a newline. The key may contain lowercase ASCII letters (a-z), digits, underscore, or dash. In regex, [-_0-9a-z]. There may need to be a maximum sum length of the X- entries. This is left to the developers. I propose a maximum sum length of 5 kilobytes.
In addition to explicitly forbidding newlines, perhaps it would be a good idea to either strip them entirely or ignore any value with a newline. -- Sent from my tracking device. Please excuse brevity and cat photos.
Hi griffin! Come join me at the Mozilla room and liberate this key from my grasp! In response to your concern, I modify the proposal that there be a torrc schema which forbids unknown keys (unless they start with X-). And the Tor program rejects the relay if the torrc doesn't match the schema. Secondarily, it makes sense to additionally verify that the generated relay descriptor also matches the schema. If either of these checks fail, then give the user an error to change their torrc file. -V On Thursday, July 3, 2014, Griffin Boyce <griffin@cryptolab.net> wrote:
In addition to explicitly forbidding newlines, perhaps it would be a good idea to either strip them entirely or ignore any value with a newline. -- Sent from my tracking device. Please excuse brevity and cat photos.
Hi Virgil. Few quick thoughts... * Your proposal doesn't mention what descriptor type you're talking about. I suspect you mean server descriptors but the proposal should make this clear. Maybe this would be more fitting for the extrainfo descriptors? * Please describe in your proposal the use cases that you plan to use this for. I dislike the idea of expanding descriptors if we don't have a user of those changes right away ('premature optimization...'). * Addition of fields means larger documents, which in turn means more load for the authorities, directory mirrors, and clients if they don't opt for microdescriptors (... which admittedly isn't common). In this case it's an arbitrary amount of extra content determined by relay torrcs. The proposal should make it clear why the value this feature provides is greater than that cost. * Proposals should be detailed enough to be used as patches for the spec. That is to say, describing how dir-spec should be amended. In particular this is missing 'what section are we modifying' and 'what is the precise format'. Your proposal attempts to answer the later but the format we're looking for is... https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l587 Cheers! -Damian On Thu, Jul 3, 2014 at 3:13 AM, Virgil Griffith <i@virgil.gr> wrote:
URL: https://dl.dropboxusercontent.com/u/3308162/ExtraRelayDescriptorFields.txt
Fulltext below. Comments appreciated.
-V =======================
Filename: ExtraRelayDescriptorFields.txt Title: Adding new X- fields to relay descriptor Author: Virgil Griffith, Nick Mathewson Created: 2014-06-03 Status: Open
1. Motivation We wish to allow developers to build new applications atop relays. Towards this end, we wish to add the ability for users to specify arbitrary new key-value entries under the "X-" namespace.
2. Proposal Allow optional key-value lines in the relay's torrc file. These lines will be mirrored in the relay's descriptor which is then published in the directory consensus.
The format is: X-key value
For example: X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-nameid virgil.gr X-favoritequote Be excellent to each other. Party on dudes!
The value field must be printable ASCII (characters 32-126). The value must not under any condition contain a newline. The key may contain lowercase ASCII letters (a-z), digits, underscore, or dash. In regex, [-_0-9a-z].
There may need to be a maximum sum length of the X- entries. This is left to the developers. I propose a maximum sum length of 5 kilobytes.
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Thu, Jul 3, 2014 at 6:13 AM, Virgil Griffith <i@virgil.gr> wrote:
https://dl.dropboxusercontent.com/u/3308162/ExtraRelayDescriptorFields.txt Fulltext below. Comments appreciated. Title: Adding new X- fields to relay descriptor Author: Virgil Griffith, Nick Mathewson
1. Motivation We wish to allow developers to build new applications atop relays. Towards this end, we wish to add the ability for users to specify arbitrary new key-value entries under the "X-" namespace. For example: X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-nameid virgil.gr X-favoritequote Be excellent to each other. Party on dudes!
I remember posting about bastardizing the contact field for things like this that others had mentioned. Thanks for putting a more formal idea out. You probably want to move the existing 'contact' to 'X-contact' too. Perhaps also for any non strictly required to operate stuff like nickname, and OS version string (which to the extent it is useful to the project might be a non overridable auto populated k-v pair). Removing the spaces from fingerprint would be nice and save bandwidth too. You'd need dual parsing for one revision period.
participants (4)
-
Damian Johnson -
grarpamp -
Griffin Boyce -
Virgil Griffith