> On 2 Jan 2018, at 10:51, nullius wrote:
>
> On 2018-01-01 at 22:36:53 +, Taylor R Campbell
> wrote:
>>> Date: Sun, 31 Dec 2017 11:46:28 +
>>> From: Alec Muffett
>>>
>>> Or, indeed, you could leave out the
On 2018-01-01 at 22:36:53 +, Taylor R Campbell
wrote:
Date: Sun, 31 Dec 2017 11:46:28 +
From: Alec Muffett
Or, indeed, you could leave out the hyphens and do the same; the Prop224
Onion address is 59 characters, leaving a budget of
> Date: Sun, 31 Dec 2017 11:46:28 +
> From: Alec Muffett
>
> Or, indeed, you could leave out the hyphens and do the same; the Prop224
> Onion address is 59 characters, leaving a budget of 63-59==4 characters or
> 20 bits; we could put these at the end, in the space
Hi,
> b) if Onion addresses have 2+ forms, one like the current
> (www.4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion) and the
> other being apparently more human-usable because it contains a CRC, the one
> which allows access to websites will win.
What if they both allow
On 31 December 2017 at 02:46, nullius wrote:
> For the foregoing reasons, I will propose that subdomain data, if any, be
> kept separate from the Bech32 coding. It may be either kept in a separate
> string, or somehow affixed with a special delimiter either before or after
>
Hi,
Please read the naming layer API proposal before writing your proposal:
https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-api.txt
In particular, if you added a unique top-level domain (.bech?), you
would only have to specify how a the bech translation plugin works.
On 2017-12-31 at 00:57:49 +, Alec Muffett
wrote:
Thanks! That's very interesting! TIL :-)
Why, if it isn’t instant feedback from the RFC 7686 co-author! In
response to what you said, in brief: I will propose that any subdomain
data (which is presumably
Thanks! That's very interesting! TIL :-)
What would you propose to do with subdomains, like
www.facebookcorewwwi.onion? Or is that outside the scope of your proposal?
- alec
On 31 Dec 2017 00:53, "nullius" wrote:
> # Synopsis
>
> The Bech32 standard for error-correcting
# Synopsis
The Bech32 standard for error-correcting base32 strings was developed
explicitly for relative ease and reliability in human communication of
pseudorandom bitstrings. I invite discussion of specifying Bech32 as an
alternative means for representing RFC 7686 .onion domain names.