[tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs
isis at torproject.org
Mon Nov 9 14:01:18 UTC 2015
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 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 
> (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 .
> The sum size accounting for all such custom fields is truncated to 5
> 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
>  http://tor-roster.org
>  https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n700
>  https://www.ietf.org/rfc/rfc2822.txt
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.
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:
What could go wrong?
For the record, I do not see any way for the above concerns to be satisfiably
addressed — short of limiting the expansion of extrainfo descriptor to some
limited number of well-specified fields to serve some express purpose. That
should, essentially, constitute a complete rewrite of this proposal. I refuse
outright to merge this, or: I'll merge it with the added stipulation that it's
committed with "Status: Rejected".
♥Ⓐ isis agora lovecruft
Current Keys: https://blog.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1240 bytes
Desc: Digital signature
More information about the tor-dev