> 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 hyphens and do the same; the Prop224
>>> Onion address is 59 characters, leav
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 63-59==4 characters or
20 bits; we could put these at
> 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 marked "":
>
>
> ht
On 31 Dec 2017 12:22, "teor" wrote:
Are you aware that there's already a checksum in v3 onion
service addresses?
No I was not*, that's great!
"The onion address of a hidden service includes its identity public key,
a
version field and a basic checksum."
It would be great to get the huma
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 acces
On 31 December 2017 at 11:46, Alec Muffett wrote:
>
> ...so that any UX component which wants to help the user can highlight (in
> red? or bold?) where the problem is, picking out a chunk of 12 characters
> which contain the typo:
>https://www4acth47i6kxnvkewtm6q7*ib2s3ujpo5sq*bsnzjpbi7utijclt
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
> the Bech32 represent
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.
(I
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 human-readable) be transmitted i
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 base32 strings was dev
# 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. Sho
11 matches
Mail list logo
