4 ms·

A UUID is 128 bits, or 16 bytes. This code suggests IDs which are 11 bytes. That's not really comparable. A UUID can also be encoded in any form, it doesn't ne

by kiitos 3y ago

A UUID is 128 bits, or 16 bytes. This code suggests IDs which are 11 bytes. That's not really comparable. A UUID can also be encoded in any form, it doesn't need to be represented as the dashed string notation which is common, you can just as easily use the base58 alphabet suggested in the post. But the code in the post doesn't encode to base58 correctly. You need to map 58 bits of the input, sequentially, to one character in the alphabet as output. You can't just mod each byte of the input by the alphabet length and use the corresponding alphabet element.

cbarrick 3y ago
The base58 code in the post is wrong, but your version isn't right either. Since the alphabet is 58 characters, each character contains log2(58) bits. Since that's not an integer, the encoding process is a bit more complex than just mapping bits to characters in a table. https://digitalbazaar.github.io/base58-spec/#encode https://digitalbazaar.github.io/base58-spec/#encode
- henvic 3y ago
  Hi. I'm the author of the post here. I agree lines 12-14 doesn't do a proper encoding, but that's not what I was after. Would you still say it's still wrong if you consider that my function is not really encoding the string per se, but using rand.Read to generate entropy for what I want to be the final output (random string with the base58 alphabet)?
  - kiitos 3y ago
    Your IDs are []byte of len=11. Those bytes can be represented in many ways. You can represent them as hex strings via encoding/hex.EncodeToString(id), or base64 strings via encoding/base64.StdEncoding.EncodeToString(id), or base32 strings via encoding/base32.StdEncoding.EncodeToString(id), or etc. Looks like the most used base58 package is https://pkg.go.dev/github.com/btcsuite/btcutil/base58 https://pkg.go.dev/github.com/btcsuite/btcutil/base58, but looking at the implementation [0] I'm not impressed, there's definitely a much better approach. [0] https://github.com/btcsuite/btcutil/blob/v1.0.2/base58/base58.go#L49 https://github.com/btcsuite/btcutil/blob/v1.0.2/base58/base5... But how you encode 11 bytes of data is kind of orthogonal to the important thing, which is that you have 11 bytes of data. Those bytes should be always be stored in memory (in your application, or in your DB, or wherever) as the actual 11 bytes of the ID, and not as a base58 or base64 or JSON or whatever other kind of string that can be decoded to the actual 11 bytes they represent. Likewise, a UUID shouldn't be stored as a string like "64d3f2e0-a4dc-48d3-98ad-7f09eb3b082f", that's a specific encoding of the actual 16 UUID bytes, you should store, process, etc. those bytes directly.
stock_toaster 3y ago
pedantry: uuidv4 is only 122 bits of randomness. > 6 predetermined variant and version bits, leaving 122 bits for the randomly generated part > --wikipedia
- henvic 3y ago
  Indeed. That's why I mentioned it's a 128-bit identifier format in the first line of the article, rather than 128-bit identifier. I probably spent 10min writing something to explain this, but then it wouldn't really be helpful so I removed it.

by kiitos 3y ago

cbarrick 3y ago

The base58 code in the post is wrong, but your version isn't right either. Since the alphabet is 58 characters, each character contains log2(58) bits. Since that's not an integer, the encoding process is a bit more complex than just mapping bits to characters in a table. https://digitalbazaar.github.io/base58-spec/#encode https://digitalbazaar.github.io/base58-spec/#encode

henvic 3y ago
Hi. I'm the author of the post here. I agree lines 12-14 doesn't do a proper encoding, but that's not what I was after. Would you still say it's still wrong if you consider that my function is not really encoding the string per se, but using rand.Read to generate entropy for what I want to be the final output (random string with the base58 alphabet)?
- kiitos 3y ago
  Your IDs are []byte of len=11. Those bytes can be represented in many ways. You can represent them as hex strings via encoding/hex.EncodeToString(id), or base64 strings via encoding/base64.StdEncoding.EncodeToString(id), or base32 strings via encoding/base32.StdEncoding.EncodeToString(id), or etc. Looks like the most used base58 package is https://pkg.go.dev/github.com/btcsuite/btcutil/base58 https://pkg.go.dev/github.com/btcsuite/btcutil/base58, but looking at the implementation [0] I'm not impressed, there's definitely a much better approach. [0] https://github.com/btcsuite/btcutil/blob/v1.0.2/base58/base58.go#L49 https://github.com/btcsuite/btcutil/blob/v1.0.2/base58/base5... But how you encode 11 bytes of data is kind of orthogonal to the important thing, which is that you have 11 bytes of data. Those bytes should be always be stored in memory (in your application, or in your DB, or wherever) as the actual 11 bytes of the ID, and not as a base58 or base64 or JSON or whatever other kind of string that can be decoded to the actual 11 bytes they represent. Likewise, a UUID shouldn't be stored as a string like "64d3f2e0-a4dc-48d3-98ad-7f09eb3b082f", that's a specific encoding of the actual 16 UUID bytes, you should store, process, etc. those bytes directly.

stock_toaster 3y ago

pedantry: uuidv4 is only 122 bits of randomness. > 6 predetermined variant and version bits, leaving 122 bits for the randomly generated part > --wikipedia

henvic 3y ago
Indeed. That's why I mentioned it's a 128-bit identifier format in the first line of the article, rather than 128-bit identifier. I probably spent 10min writing something to explain this, but then it wouldn't really be helpful so I removed it.