It is great that we are identifying places to improve support for Rust
in Tor.
Along this same line of thinking, are there other places in Tor where we
will need to move to supporting UTF-8? For example, should the statefile
be UTF-8 also?
On 11/13/2017 01:51 PM, Nick Mathewson wrote:
>
On 03/08/2017 02:01 PM, Nick Mathewson wrote:
> Thanks, Chelsea! How would you like to get these into the
> documentation? I was thinking that adding them to
> https://people.torproject.org/~nickm/tor-auto/internal/
> [generated from
>https://gitweb.torproject.org/user/nickm/tor-guts.git
Hello All,
I've published object diagrams created from a conversation with Nick at
the last Tor meeting, along with the original sketches (hopefully very
similar).
github.com/chelseakomlo/tor_arch
The plan for these is to include them into documentation. These should
definitely evolve along
Hey,
On 01/28/2017 10:16 AM, segfault wrote:
> I share your concerns here. I think we could work around this by pulling
> the version byte out of the base32 encoding, like this:
>
> onion_address = base32(pubkey + checksum) + "-" + version
>
> This would result in onion addresses like this:
>
Hey!
> Here is some extra pressure for you ;).
:) thanks, I will try!
Before starting, someone today very kindly pointed me to Prop 271, the
naming system API for Tor Onion services. Overall, my larger concern is
whether adding the version in the onion address makes both using and
distributing
Hello!
I have some more thoughts on versioning, specifically in regards to the
possibility of not including the version in the onion address and using
only the version field in the descriptor.
I'm not able to write out these scenarios now but I will do this in the
next day. Thanks for making
Hey George,
Thanks for sending this and summarizing everything!
> [D1] How to use version field:
>
> The version field is one byte long. If we use it as an integer we can
> encode 256 values in it; if we use it as a bitmap we could encode
> properties and such.
>
> My
Hi,
>> Yes, the onion-service-version and the version of the descriptor that tor
>> publishes are now tightly coupled, comparing v2 and v3. However, this may
>> not always be the case and, indeed, was not the case previously. I'm not
>> saying HiddenServiceVersion is not the correct torrc
Hi George,
We were having a similar discussion about what to include in the "receive
new consensus" action.
We currently have three actions to remove dead/unused guards. They are:
1. Marking guards that are not listed in the latest consensus as "bad"
2. Remove guards that have been dead
Hi George,
Thanks for your help with this!
We wrote up our high-level understanding of the current Tor guard selection
algorithm here:
https://gist.github.com/chelseakomlo/2acbe15314b5a809c6f4
This has more than our python simulation, but less than the actual Tor
implementation. For example,
10 matches
Mail list logo
