Re: [tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs
Virgil Griffith transcribed 10K bytes: > Yes I did. Here's the modified proposal. > > Filename: ExtraRelayDescriptorFields.txt > Title: Adding X-namespace to extra-info descriptor for key:value pairs > Author: Virgil Griffith > Created: 2015-09-30 > 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 to the extra-info descriptor. > The canonical applications for this are adding a bitcoin donation address, > networking of tor2web nodes, and display operator information on a > Roster[1] page. > > > 2. Proposal > Allow optional key-value lines in the relay's torrc file. > > The following would be added to section 2.1.2 of the dir-spec [2] > (Extra-info document format): > > > "X-" CustomKey SP CustomValue NL > > CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_" > CustomKey = 1*32 CustomKeyChar > > CustomValueChar = atext / specials > CustomValue = 1*1024 CustomValueChar > > There can be multiple X-fields, for example... > > X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 > X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d > X-linkedin https://www.linkedin.com/in/virgilgr > X-keybase http://fncuwbiisyh6ak3i.onion/virgil > X-favoritequote Be excellent to each other. Party on dudes! > X-foo bar > > The same CustomKey appearing more than once is disallowed. > Possible values for CustomValueChar as specified per RFC 2822 > sections 3.2.1 and 3.2.4 [3]. > > The sum size accounting for all such custom fields is truncated to 5 > kilobytes. > > > To mitigate the chance of a malformed torrc file, I additionally propose > that the relay descriptor be scanned and if it does not match the > specification, that it exit with error telling her torrc file is a likely > culprit. > > References > [1] http://tor-roster.org > [2] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n700 > [3] https://www.ietf.org/rfc/rfc2822.txt Hello Virgil, Some feedback: A. You still appear to be confusing the terms "torrc" and "extrainfo". Or did you mean that there will be both X-Some-Crap torrc options and fields in the extrainfo descriptors? B. Do you mean for all extrainfo descriptors? BridgeDB must parse the bridge-extrainfos to obtain transport lines. Parsing the bridge-extrainfos is already rather intensive and time-consuming, mostly because, people have been shoving more and more random cruft into the descriptors. It sure would suck if BridgeDB had to parse up to 5KB more crap per descriptor (which also have to be deduplicated, occasionally deduplicating thousands of submitted descriptors per hour per relay). Which brings me to… C. Why do we need 5KB of unparseable, unspecified, cruft in the descriptors? There is some argument to be made for having certain, well-specified fields, e.g. a bitcoin address of the relay operator… but a LinkedIn address? Why is this necessary? D. The extrainfo descriptors are not a message-passing channel for data for other applications, nor should they be. If you need some application to have the ability to associate your LinkedIn address with your relay, then write a program which uses (one of) your relay's identity keys to sign the requisite information. E. "truncated" Truncated by whom? The OP as it parses the torrc and forms its own extrainfo descriptor for submission? Obviously not. So this must be enforced by the DirAuths then? F. "To mitigate the chance of a malformed torrc file, I additionally propose that the relay descriptor be scanned…" You're still mixing up torrc files and extrainfo descriptors. G. "that it exit with error telling her torrc file is a likely culprit"… The English objective pronoun, "her," usually requires there to be some prior subjective context to explain who the unspecified female object is. Additionally, you're using the same occurence of "her" as both the objective to "telling" and as the possesive determinant to "torrc". Also, poor grammar aside, looking at the ways in which sexism can be inherent to the English language, it is frequently the case that females are spoken of in the passive voice, and then males in the active voice, e.g. when speaking to infants: "Oh, he kicks and squirms so much!" versus "Her toes are so cute and tiny." Sorry, but this is a bit of a pet peeve of mine, and I'm quite strongly against including a female object in the proposal merely so that actions can be done *to* her by the programme, rather than by her. H. "CustomValueChar as specified per RFC 2822" Because, clearly, that turned out to be trivially parseable for email and HTTP: http://stackoverflow.com/a/1732454
Re: [tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs
On Mon, Nov 9, 2015 at 10:01 PM, isiswrote: >If you need some application to have the ability to associate your LinkedIn >address with your relay, then write a program which uses (one of) your For what it's worth, the LinkedIn reference was my attempt at humor to add levity to otherwise usually dry material. I concur that it would be odd if someone put their LinkedIn in their relay's ExtraInfo descriptor. > G. "that it exit with error telling her torrc file is a likely culprit"… For what it's worth, in the first draft of this the pronoun was male, but I explicitly changed it to female (no personal pronouns are mentioned anywhere else) because I wanted to be more gender-inclusive. -V ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs
> A. You still appear to be confusing the terms "torrc" and "extrainfo". I recognize this error and will fix it. > B. Do you mean for all extrainfo descriptors? I support excluding Bridge relays for exactly the reasons you mentioned. My sole is to clean up the bitcoin addresses in the ContactInfo field as well as allow relays to integrate with Roster better as well as clean up the > C. Why do we need 5KB of unparseable, unspecified, cruft in the descriptors? > D. The extrainfo descriptors are not a message-passing channel for data for > other applications, nor should they be. In Paris I asked Roger for a bitcoin field in the ExtraInfo descriptor because currently Bitcoin addresses are polluting the ContactInfo, and I'd like to clean that up. Roger said he couldn't add a bitcoin field because if he made a bitcoin field then everyone's pet project will ask him for special ExtraInfo headers. He proposed instead making an "x-" namespace where people can scribble in for their pet projects. This advice seemingly conflicts with your (D). In my defense, I was just following orders. > E. "truncated" I say the OP does the truncation. If someone modifies their Tor client to create a broken or otherwise unparseable ExtraInfo descriptor that is their choice, and my understanding is that this patch does not increase anyone's ability to specify malformed ExtraInfo descriptors. > G. "that it exit with error telling her torrc file is a likely culprit"… I aspire to be more mindful in my gender-inclusive language. > H. "CustomValueChar as specified per RFC 2822" Atagar suggested I use RFC 2822 as a template. That's all I got really. If someone has an alternative suggestion for allowing people to specify things like Bitcoin addresses I'm all ears, but this was the path I was explicitly placed on. I will correct the errors (A), (E), (G), (F). I am all ears on how to fix (H). -V On Mon, Nov 9, 2015 at 10:01 PM, isiswrote: > Virgil Griffith transcribed 10K bytes: >> Yes I did. Here's the modified proposal. >> >> Filename: ExtraRelayDescriptorFields.txt >> Title: Adding X-namespace to extra-info descriptor for key:value pairs >> Author: Virgil Griffith >> Created: 2015-09-30 >> 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 to the extra-info descriptor. >> The canonical applications for this are adding a bitcoin donation address, >> networking of tor2web nodes, and display operator information on a >> Roster[1] page. >> >> >> 2. Proposal >> Allow optional key-value lines in the relay's torrc file. >> >> The following would be added to section 2.1.2 of the dir-spec [2] >> (Extra-info document format): >> >> >> "X-" CustomKey SP CustomValue NL >> >> CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_" >> CustomKey = 1*32 CustomKeyChar >> >> CustomValueChar = atext / specials >> CustomValue = 1*1024 CustomValueChar >> >> There can be multiple X-fields, for example... >> >> X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 >> X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d >> X-linkedin https://www.linkedin.com/in/virgilgr >> X-keybase http://fncuwbiisyh6ak3i.onion/virgil >> X-favoritequote Be excellent to each other. Party on dudes! >> X-foo bar >> >> The same CustomKey appearing more than once is disallowed. >> Possible values for CustomValueChar as specified per RFC 2822 >> sections 3.2.1 and 3.2.4 [3]. >> >> The sum size accounting for all such custom fields is truncated to 5 >> kilobytes. >> >> >> To mitigate the chance of a malformed torrc file, I additionally propose >> that the relay descriptor be scanned and if it does not match the >> specification, that it exit with error telling her torrc file is a likely >> culprit. >> >> References >> [1] http://tor-roster.org >> [2] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n700 >> [3] https://www.ietf.org/rfc/rfc2822.txt > > Hello Virgil, > > Some feedback: > > A. You still appear to be confusing the terms "torrc" and "extrainfo". > >Or did you mean that there will be both X-Some-Crap torrc options and >fields in the extrainfo descriptors? > > B. Do you mean for all extrainfo descriptors? > >BridgeDB must parse the bridge-extrainfos to obtain transport lines. >Parsing the bridge-extrainfos is already rather intensive and >time-consuming, mostly because, people have been shoving more and more >random cruft into the descriptors. It sure would suck if BridgeDB had to >parse up to 5KB more crap per descriptor (which also have to be >deduplicated, occasionally deduplicating thousands of submitted descriptors >per hour per relay). Which brings me to… > > C. Why do we
[tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs
Filename: ExtraRelayDescriptorFields.txt Title: Adding x-namespace to relay descriptor for key:value pairs Author: Virgil Griffith Created: 2015-09-30 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 to the router descriptor [1]. The canonical applications for this are adding a bitcoin donation address and networking of tor2web nodes. 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 following would be added to section 2.1.2 of the dir-spec (Extra-info document format): "X-" CustomKey SP CustomValue NL CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_" CustomKey = 1*32 CustomKeyChar CustomValueChar = atext / specials CustomValue = 1*1024 CustomValueChar Custom fields can appear multiple times, for example... X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-favoritequote Be excellent to each other. Party on dudes! X-foo bar If the same CustomKey appearing more than once is disallowed. Possible values for CustomValueChar as specified per RFC 2822. The sum size accounting for all such custom fields is truncated to 5 kilobytes. To mitigate the chance of a malformed torrc file, I additionally propose that the relay descriptor be scanned and if it does not match the specification, that it exit with error telling her torrc file is a likely culprit. -V ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs
Yes I did. Here's the modified proposal. Filename: ExtraRelayDescriptorFields.txt Title: Adding X-namespace to extra-info descriptor for key:value pairs Author: Virgil Griffith Created: 2015-09-30 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 to the extra-info descriptor. The canonical applications for this are adding a bitcoin donation address, networking of tor2web nodes, and display operator information on a Roster[1] page. 2. Proposal Allow optional key-value lines in the relay's torrc file. The following would be added to section 2.1.2 of the dir-spec [2] (Extra-info document format): "X-" CustomKey SP CustomValue NL CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_" CustomKey = 1*32 CustomKeyChar CustomValueChar = atext / specials CustomValue = 1*1024 CustomValueChar There can be multiple X-fields, for example... X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-linkedin https://www.linkedin.com/in/virgilgr X-keybase http://fncuwbiisyh6ak3i.onion/virgil X-favoritequote Be excellent to each other. Party on dudes! X-foo bar The same CustomKey appearing more than once is disallowed. Possible values for CustomValueChar as specified per RFC 2822 sections 3.2.1 and 3.2.4 [3]. The sum size accounting for all such custom fields is truncated to 5 kilobytes. To mitigate the chance of a malformed torrc file, I additionally propose that the relay descriptor be scanned and if it does not match the specification, that it exit with error telling her torrc file is a likely culprit. References [1] http://tor-roster.org [2] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n700 [3] https://www.ietf.org/rfc/rfc2822.txt On Wed, Sep 30, 2015 at 12:49 PM Virgil Griffithwrote: > Filename: ExtraRelayDescriptorFields.txt > Title: Adding x-namespace to relay descriptor for key:value pairs > Author: Virgil Griffith > Created: 2015-09-30 > 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 to the router descriptor [1]. > The canonical applications for this are adding a bitcoin donation address > and networking of tor2web nodes. > > > 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 following would be added to section 2.1.2 of the dir-spec > (Extra-info document format): > > > "X-" CustomKey SP CustomValue NL > > CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_" > CustomKey = 1*32 CustomKeyChar > > CustomValueChar = atext / specials > CustomValue = 1*1024 CustomValueChar > > Custom fields can appear multiple times, for example... > > X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 > X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d > X-favoritequote Be excellent to each other. Party on dudes! > X-foo bar > > If the same CustomKey appearing more than once is disallowed. > Possible values for CustomValueChar as specified per RFC 2822. > > The sum size accounting for all such custom fields is truncated to 5 > kilobytes. > > > To mitigate the chance of a malformed torrc file, I additionally propose > that the relay descriptor be scanned and if it does not match the > specification, that it exit with error telling her torrc file is a likely > culprit. > > -V > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs
Dear Virgil, On 9/30/15, Virgil Griffithwrote: > Filename: ExtraRelayDescriptorFields.txt > Title: Adding x-namespace to relay descriptor for key:value pairs > Author: Virgil Griffith > Created: 2015-09-30 > 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 to the router descriptor [1]. > The canonical applications for this are adding a bitcoin donation address > and networking of tor2web nodes. > > > 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. Do you mean in extra info area? All the best, Jacob ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev