teor:
>
>> On 12 Oct 2016, at 09:29, Jesse V wrote:
>>
>> On 10/11/2016 12:53 AM, Jeremy Rand wrote:
>>> It's also worth noting that it's been hard enough to get IETF to accept
>>> .bit (that effort stalled) -- adding a bunch of other TLD's would
>>> probably annoy IETF significantly (and destroy
On Wed, Jan 18, 2017 at 3:31 AM, George Kadianakis wrote:
> What do you mean by "develop an IPv6 layer"?
prop224 destroys the one to one bidirectional binary mapping that
makes onioncat possible, and fails to provide a replacement for it :-(
Any "human naming" layer (whether under prop224 or curr
> On 12 Oct 2016, at 09:29, Jesse V wrote:
>
> On 10/11/2016 12:53 AM, Jeremy Rand wrote:
>> It's also worth noting that it's been hard enough to get IETF to accept
>> .bit (that effort stalled) -- adding a bunch of other TLD's would
>> probably annoy IETF significantly (and destroy whatever goo
grarpamp writes:
> Always wondered how naming is relevant,
> for example, IPv6 with OnionCat as a deterministic
> form of naming. So now we propose a 'naming' layer.
> Which should not also support IPv6 addressing?
> Is not IPv6, subsequent to the 80bit scheme,
> merely a name on top of onions? i
Always wondered how naming is relevant,
for example, IPv6 with OnionCat as a deterministic
form of naming. So now we propose a 'naming' layer.
Which should not also support IPv6 addressing?
Is not IPv6, subsequent to the 80bit scheme,
merely a name on top of onions? ie: If we develop
a 'naming' lay
On 10/11/2016 12:53 AM, Jeremy Rand wrote:
> It's also worth noting that it's been hard enough to get IETF to accept
> .bit (that effort stalled) -- adding a bunch of other TLD's would
> probably annoy IETF significantly (and destroy whatever good will exists
> at IETF right now), and I fully under
Jesse V:
> On 10/08/2016 08:50 AM, 61wxg...@vfemail.net wrote:
>> How about specifying whether the Namecoin domain should point to .onion
>> or clearnet in the domain? We can require that TLDs for such service
>> must end in either:
>>
>> o o: The name points to a .onion name.
>>
>> o i: The name
i9nvr...@tutanota.com:
> Hi,
>
> Why run a separate process instead of using unix socket or TCP socket?
>
>> Since a Namecoin domain can point to IP addresses and ICANN-based DNS
>> names in addition to onion service names, and a Namecoin domain owner
>> might wish to switch between these configu
The minorest of comments.
On 7 October 2016 at 15:06, George Kadianakis wrote:
>For example here is a snippet from a torrc file:
>OnionNamePlugin 0 .hosts /usr/local/bin/local-hosts-file
>OnionNamePlugin 1 .zkey /usr/local/bin/gns-tor-wrapper
>OnionNamePlugi
Hi,
I think that this work is extremely important, and I applaud the
authors and contributors for their work. It seems that it will also
be complicated, semantically. What lies where, and which thing
does what? The example recently about what is sent in the Host
header is a good example of this
On 10/08/2016 08:50 AM, 61wxg...@vfemail.net wrote:
> How about specifying whether the Namecoin domain should point to .onion
> or clearnet in the domain? We can require that TLDs for such service
> must end in either:
>
> o o: The name points to a .onion name.
>
> o i: The name points to an IP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Why run a separate process instead of using unix socket or TCP socket?
Since a Namecoin domain can point to IP addresses and ICANN-based DNS
names in addition to onion service names, and a Namecoin domain owner
might wish to switch between th
Hi,
Why run a separate process instead of using unix socket or TCP socket?
> Since a Namecoin domain can point to IP addresses and ICANN-based DNS
> names in addition to onion service names, and a Namecoin domain owner
> might wish to switch between these configurations without causing
> downtime
David Fifield:
> So here, the browser thinks it is connecting to debian.zkey (the URL bar
> says "debian.zkey"). But Tor is really connecting to sejnfjrq6szgca7v.onion
> in the background. What name does the browser put in its Host header? It
> can't be the onion name, because there's no feedback f
Hi George,
Here are my comments:
2.3.1
> If there are multiple name plugins that correspond to the requested
> address, Tor queries all relevant plugins sorted by their priority
> value, until one of them returns a successful result.
It's unclear whether the sort operation referred to here is a
George Kadianakis writes:
I have skimmed over this proposal, and it all sounds plausible. This:
>In the beginning, name plugins should be third-party applications that can
>be installed by interested users manually or through package managers.
> Users
>will also have to add the appr
On Fri, Oct 07, 2016 at 04:06:51PM -0400, George Kadianakis wrote:
>In particular, onion addresses are currently composed of 16 random base32
>characters, and they look like this:
>
> 3g2upl4pq6kufc4m.onion
> vwakviie2ienjx7t.onion
>
Hi George,
A nice proposal!
A question that occurs to me is how the name plugin will interact with
the network. Presumably it will make requests over Tor, either
periodically to update its local database, or just-in-time, whenever a
RESOLVE request is made. If name resolution requires a just-in-t
Hello list,
we've been busy discussing secure name systems for the past few months,
and how we could integrate them with Tor.
We had a few people ask us for precise interfaces, so here is an attempt
for a modular name system API. It's largely based on the PT API, which
has been pretty successful.
19 matches
Mail list logo
