Re: [tor-dev] Torspec proposal for adding new X- fields to relay descriptor
On Thu, Jul 3, 2014 at 6:13 AM, Virgil Griffith 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. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Torspec proposal for adding new X- fields to relay descriptor
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 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 > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Torspec proposal for adding new X- fields to relay descriptor
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 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. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] SENDME cells
Just to answer my own question for any others. I've played around with it a for a few days and it seems the intermediate ORs don't maintain windows, it's only the edge nodes, maintaining a circuit, and individual stream windows. Hope someone can update the spec to be clearer on this to save others the effort. The offending sentence is: *"The OP behaves identically, except that it must track a packaging window and a delivery window for every OR in the circuit."* Best Gareth On 1 July 2014 09:51, Gareth Owen wrote: > (sorry re-post - forgot subject) > > Dear all > > I'm working on a tor research project and am having difficulty > understanding the SENDME cells. The tor spec acknowledges that it isn't > particularly clear so I would welcome some clarification please. > > The spec says that *all* nodes in a circuit maintain a send and receive > window, and that this window is decremented on each RELAY_DATA and > incremented on each SENDME. Cells that are neither of these do not affect > the window size. The problem I have understanding is, that only edge nodes > will know whether a cell is a RELAY_DATA, the intermediate nodes only know > that its a RELAY but not what type. So, if only RELAY_DATA decrements the > window size, and intermediate nodes cannot spot these, what point is there > in intermediate nodes having a window? > > Any help greatly appreciated. > > Gareth > > --- > Dr Gareth Owen > Senior Lecturer > School of Computing, University of Portsmouth > > W: ghowen.me > > > -- Dr Gareth Owen Senior Lecturer School of Computing, University of Portsmouth Tel: 02392 846423 Web: ghowen.me ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Torspec proposal for adding new X- fields to relay descriptor
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.___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] 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. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev