Closed pjkundert closed 5 years ago
@pjkundert
I was attempting to follow a standard. In this case, the base64url variant: https://tools.ietf.org/html/rfc4648#section-5
If we're going to deviate from that, it might be better to go to something like base58, despite the (much) larger encoding / decoding overhead. (of course, that'd mess up our hk
prefix)
Makes sense. The base64 encoding has always been problematic no match which variant we choose. Might as well stick to the standard.
We want to avoid situations where Holochain keys A) break across lines in small browser windows, or B) don't get completely selected by standard double-click selection methods.
Browsers break lines across
_
and-
, but they do not appear to break lines across+~@#$*!
:As for double-click selection, the restrictions are even greater. At least on a Mac, double-clicking in the browser stops at all punctuation, except for
_
. Difficult... There are no other safe non-alphanumeric characters for in-browser double-click selection.In the terminal, double-clicking stops at all punctuation except for
+~_-/\
. So, I would recommend we switch to at least another character that is both visually distinguishable from_
, and avoids browser line-splitting. Any combination of the above characters would suffice.That boils down to one of the set intersection of
+~@#$*!
and+~_-/\
; so one of+~
. The most visually distinguishable one is+
...Thus, at least we'll have no more split lines in browsers, and full-key selectability in (at least some) terminals. And, improved visual distinguishability for manual data entry of any
hkZ...
Holochain keys.