[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Tor and Namecoin



First Jeremy, thanks for engaging with Tor! Some kind of solution is going to be needed. But I think if we carefully leverage either DNS or URLs (I prefer the later but that's just me) then we can easily support multiple different naming systems without them running rough shod over each other. 

In other words we could have a URL of the form tornc+http:foobar/index.html or alternatively https://foobar.tornc/index.html (where we are using tornc in the same sense as .onion). Different Tor clients can decide which name resolvers they want to support and let users decide which one has the best solution.

	Thanks,

			Yaron

-----Original Message-----
From: tor-dev [mailto:tor-dev-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Jeremy Rand
Sent: Tuesday, August 2, 2016 3:30 PM
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-dev] Tor and Namecoin

Yaron Goland:
> I'm also a noob, so just to be clear, is the goal here to adopt namecoin as a naming mechanism for hidden services or is the goal to enable a generic extension mechanism where multiple different naming solutions can be experimented with and namecoin wants to build the code to leverage that mechanism so it can be part of the more general naming experiment?
> 
> 	Thanks,
> 
> 		Yaron

Hi Yaron,

My personal take on this is that modularity and reusability are good design principles to aim for.  As such, I think it would be good for any solution to allow multiple naming systems (not just Namecoin) to be used with Tor, and similarly, multiple hidden-service-like systems (e.g. Tor, I2P, Freenet, ZeroNet, IPFS, and MaidSafe) would ideally be usable with Namecoin (and whatever other naming systems might be used).  Of course, this might be difficult to achive in a completely general case, but the amount of added code needed to add a new naming system or new hidden-service-like system would ideally be as small as possible.

For this reason, I think using or-ctl-filter would have an advantage here, since it also can be used with I2P, whereas Nick's suggestion of using the Tor controller API appears to be fairly specialized to Tor.

All that said -- my opinion is that Namecoin does offer a combination of properties that aren't really offered by any other systems, and that that particular combination is very useful for Tor hidden services (particularly given that the length of .onion names is going to be made a lot longer).  So I would love to see Namecoin be adopted by Tor.  I do understand, though, that this would mean a lot of review that hasn't happened yet.  I'd be happy to work with Tor to facilitate that, if there's interest.  And, of course, it's likely that my opinion of Namecoin isn't exactly impartial, seeing as I'm one of the Namecoin developers.  I do think that enabling people to more easily experiment with combining Namecoin and Tor hidden services seems to be a prudent step to take before any kind of adoption of Namecoin by Tor.

Hope this answers your inquiry -- let me know if I was unclear about anything.

Cheers,
-Jeremy

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev