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
I commented on the ticket but I'll do it here for completeness sake:
On Sun, 31 Dec 2017 10:12:53 +
nullius wrote:
> I also proposed changes to permit the UTF-8 characters required for
> representing names in languages other than American English, and some
> other technical improvements. I
On 2017-12-31 at 14:23:39 +1100, teor wrote:
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
