For principals we use a textual encoding that looks like this: em77e-bvlzu-aq. It is defined in the spec and can encode any blob of data. There is now the very real possibility that the same encoding gets used for other things than principals. The first such use is going to be for account identifie…

Companies like Slack and Stripe use a human-readable prefix with an underscore separator for Base64-encoded access tokens. These are also easy to search for by static analysis tools. Underscore isn’t a valid Base64 character so there’s no chance of the prefix colliding with something randomly gene…

One concern about textual prefixes/suffixes is that it’s unclear how to include them in the checksum. Bech32 forms the human-readable part into the checksum. I believe if we want to have the human-readable part, we should extend the principal encoding to do the same.

[image] roman-kashitsyn: I believe if we want to have the human-readable part, we should extend the principal encoding to do the same. That should be possible if there is demand for it. We can just take the pre-fix bytes and put them under the checksum. However, another way would be to “regi…

Using the principals' textual encoding for other things than principals

Developers

timo September 19, 2022, 8:12am 4

ICRC-1 wants to use 0xff for the last byte for account identifiers: Ledger & Tokenization Working Group Update - #21 by roman-kashitsyn

Topic		Replies	Views
ICRC-1 Account Human Readable Format Developers	94	5195	August 19, 2024
Logic behind the 63 character principal Education	3	709	July 29, 2022
Addresses - defining the standard Developers Discussing , community-consideration , sns	11	315	April 9, 2025
Is there any base32 implemented based on Motoko, specifically RFC4648 with no padding? Developers	9	1314	August 9, 2021
Ledger & Tokenization Working Group Update Developers	47	3678	December 12, 2022

Using the principals' textual encoding for other things than principals

Related topics