Hi ! I'll make some comments here on the draft onion naming API at
https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-ap...
(Some of these are probably things you already meant, or already said elsewhere.)
Section 2.1 and elsewhere:
I suggest that we require all address suffixes to end with .onion; other TLDs are not reserved like .onion is, and maybe we shouldn't squat any we haven't squatted already. I think we might also want to have all output addresses end with .onion too.
I suggest also that we might want to reserve part of the namespace for standardized namespaces and some for experimental or local ones. Like, if we standardize on namecoin that could be .bit.onion, but if we don't, it could be .bit.x.onion.
I finally suggest that we distinguish names that are supposed to be global from ones that aren't.
Section 2.3:
How about we require that the suffixes be distinct? If we do that, we can drop this "priority" business and we can make the system's behavior much easier to understand and explain.
Let's require that the TLDs actually begin with a dot. (That is, I think that ".foo.onion" can include "bar.foo.onion", but I don't like the idea of "foo.onion" including "barfoo.onion".)
Section 2.3.1:
Does the algorithm apply recursively? That is, can more then one plugin rewrite the same address, or can one plugin rewrite its own output?
(I would suggest "no".)
I think there should be a way for a plugin to say "This address definitely does not exist" and stop resolution. Otherwise no plugin can be authoritative over a TLD.
Section 2.5.1:
Is the algorithm allowed to produce non-onion addresses? Should it be?
Must query IDs be unique? Over what scope must they be unique? Who enforces that?
May query IDs be negative? Can they be arbitrarily large?
I think result should indeed be optional on failure.
Section 2.5.1 and 2.5.2:
We should specify what exactly clients and plugins will do if they receive an unrecognized message, or a malformed message.
Section 2.5.3.
See security notes on caching below; client-side caching can lead to undesirable results.
As noted above, I agree with requiring all result addresses to be .onion.
Section 3.1:
I prefer the "put everything under .onion" option. I also think that we should require that the second-level domain be 10 characters or less, to avoid confusion with existing onion addresses.
General questions:
I know we've done stdout/stdin for communication before, but I wonder if we should consider how well it's worked for us. The portability on Windows can be kind of hard.
Two alternatives are TCP and named pipes.
Another alternative might be just using the DNS protocol and asking for some kind of "ONION_CNAME" record. (DNS is ugly, but at least it's nice and standard.)
Security notes:
I'd like to know what the browser people think about the risks here of (eg) probing to see whether the user has certain extensions installed or names mapped. Maybe .hosts.onion should only be allowed in the address bar, not in HREF attributes et al?
We might want to think about cache-related timing attacks here. Perhaps we should have a "no caching" rule.
We should probably add a security notes section for how to write plugins that aren't dangerous: a bad plugin potentially breaks user anonymity.