The URLs are the same. They are:
(1) http://dl.dropbox.com/u/3308162/230-quicken-tor2web-mode.txt (2) http://dl.dropbox.com/u/3308162/231-remittance-addresses.txt
I clarified them a bit and corrected the formatting. Previously people asked for more details such as what other specs will be affected, there are the two references in 230 and in 231 there is no interaction with existing specs.
If more changes need to be made please state so. Otherwise I request these be merged.
-V
On Wed, Apr 9, 2014 at 4:53 PM, Virgil Griffith i@virgil.gr wrote:
The URLs are the same. They are:
(1) http://dl.dropbox.com/u/3308162/230-quicken-tor2web-mode.txt (2) http://dl.dropbox.com/u/3308162/231-remittance-addresses.txt
I clarified them a bit and corrected the formatting. Previously people asked for more details such as what other specs will be affected, there are the two references in 230 and in 231 there is no interaction with existing specs.
If more changes need to be made please state so. Otherwise I request these be merged.
I've added these to the torspec repo as proposals 233 and 234 respectively. They're still in "open" status, meaning that more comments and questions are welcome to figure out what the issues are here, and what else we all need to figure out.
Some quick notes:
233: Implementing one-hop intro circuits for tor2web mode won't be hard. Implementing self-rendezvous will be harder, since it will require a tor2web instance to start acting a little like a relay, when right now it only acts like a client.
234: Is there a writeup anywhere of how you imagine this would be used? I kind of wonder if there shouldn't be a generic mechanism for sticking other contact/administrative stuff into a router descriptor, maybe with an "X-" prefix.
cheers,