Thanks Lunar for bringing this into discussion. See below.
David Goulet wrote:
> On 06 Dec (17:23:10), Lunar wrote:
>> Hi!
>>
>> Sorry to be late to the party. I still haven't seen UX concerns fully
>> addressed, and I think we should not create a specification that will
>> make the life of our
On 06 Dec (17:23:10), Lunar wrote:
> Hi!
>
> Sorry to be late to the party. I still haven't seen UX concerns fully
> addressed, and I think we should not create a specification that will
> make the life of our users harder if we can avoid it.
I believe it can be addressed by a good UI in TBB
Hi!
Sorry to be late to the party. I still haven't seen UX concerns fully
addressed, and I think we should not create a specification that will
make the life of our users harder if we can avoid it.
s7r:
> George Kadianakis wrote:
> > I have a more mature torspec branch now for your eyes and
George Kadianakis writes:
> Nick Mathewson writes:
>
>> [ text/plain ]
>> Hi! I thought I'd write this up while it was fresh in my mind. It
>> could be used as an alternative method to the current proposed client
>> authentication mechanism. We
Hello,
George Kadianakis wrote:
> Nick Mathewson writes:
>
>> [ text/plain ]
>> Hi! I thought I'd write this up while it was fresh in my mind. It
>> could be used as an alternative method to the current proposed client
>> authentication mechanism. We could implement
Nick Mathewson writes:
> [ text/plain ]
> Hi! I thought I'd write this up while it was fresh in my mind. It
> could be used as an alternative method to the current proposed client
> authentication mechanism. We could implement both, or just this, or
> just the other.
>
>
> - I feel that the max settings imposed by the 50k max size limit, will satisfy
> most crazy hidden service use cases that someone might have wrt scalability
> or number of authed clients. It can support up to 350 authed clients, and 20
> intro points. We should increase the max size limit,
David Goulet writes:
> [ text/plain ]
> On 15 Nov (16:29:33), George Kadianakis wrote:
>> Nick Mathewson writes:
>>
>>
>>
>> Hello,
>>
>> I worked some more on prop224 client authorization. I have a draft
>> torspec patch at prop224_client_auth_3 in
> On 18 Nov. 2016, at 09:20, David Goulet wrote:
>
> On 18 Nov (08:27:53), teor wrote:
>>
>>> On 18 Nov. 2016, at 03:52, David Goulet wrote:
>>>
I ended up using the x25519 scheme described above by Nick.
I also ended up dodging the
On 18 Nov (08:27:53), teor wrote:
>
> > On 18 Nov. 2016, at 03:52, David Goulet wrote:
> >
> >>
> >> I ended up using the x25519 scheme described above by Nick.
> >>
> >> I also ended up dodging the UX questions raised on this thread, by only
> >> specifying the Tor
> On 18 Nov. 2016, at 03:52, David Goulet wrote:
>
>>
>> I ended up using the x25519 scheme described above by Nick.
>>
>> I also ended up dodging the UX questions raised on this thread, by only
>> specifying the Tor protocol level details, and leaving the out-of-band
>>
On 15 Nov (16:29:33), George Kadianakis wrote:
> Nick Mathewson writes:
>
> > [ text/plain ]
> > Hi! I thought I'd write this up while it was fresh in my mind. It
> > could be used as an alternative method to the current proposed client
> > authentication mechanism. We
Nick Mathewson writes:
> [ text/plain ]
> Hi! I thought I'd write this up while it was fresh in my mind. It
> could be used as an alternative method to the current proposed client
> authentication mechanism. We could implement both, or just this, or
> just the other.
>
>
George Kadianakis writes:
> Also, it means that clients need to _securely_ send credentials to the
> HS operator and then they need to _wait_ till the HS operator adds
> those creds to Tor, before they are able to visit the HS.
One thing that might help here is Brian
Regarding the API / interface for communicating client-keys for hidden-
services .. I thought we were encouraging ADD_ONION based services?
Personally, I think using the filesystem as "an API" isn't very
good. From a controller standpoint, it's *way* simpler to use ADD_ONION
properly than
> On 12 Nov. 2016, at 03:41, George Kadianakis wrote:
>
> teor writes:
>
>> [ text/plain ]
>>
>>> On 11 Nov. 2016, at 04:18, George Kadianakis wrote:
>>>
>>> George Kadianakis writes:
>>>
[
teor writes:
> [ text/plain ]
>
>> On 11 Nov. 2016, at 04:18, George Kadianakis wrote:
>>
>> George Kadianakis writes:
>>
>>> [ text/plain ]
>>> Nick Mathewson writes:
>>>
[ text/plain ]
Hi! I
> On 11 Nov. 2016, at 04:18, George Kadianakis wrote:
>
> George Kadianakis writes:
>
>> [ text/plain ]
>> Nick Mathewson writes:
>>
>>> [ text/plain ]
>>> Hi! I thought I'd write this up while it was fresh in my mind. It
George Kadianakis writes:
> [ text/plain ]
> Nick Mathewson writes:
>
>> [ text/plain ]
>> Hi! I thought I'd write this up while it was fresh in my mind. It
>> could be used as an alternative method to the current proposed client
>> authentication
Nick Mathewson writes:
> [ text/plain ]
> Hi! I thought I'd write this up while it was fresh in my mind. It
> could be used as an alternative method to the current proposed client
> authentication mechanism. We could implement both, or just this, or
> just the other.
>
>
20 matches
Mail list logo