So we can have a proper spec that says "the string representation of ids looks like this:" - even though we don't use it in the most basic use case.

Ack, let's do this.

I think the format here should be as consistent as possible with the format we plan to introduce later. So if we already have a pretty good idea about how our string representation will look like, let's just use that format. Otherwise we'll have "that one weird string representation that is basically the same as the one we usually use, but for some reason it's hex and not base32".

Fair enough. So let's bikeshed this some more =)

In general, do we want to interpret the number as eight big-endian bytes and then encode those, or do we write out the number with the lowest amount of digits? The first makes more sense for stuff like base32/58/64 encoding, the latter is more appropriate for a decimal or hexadecimal representation (e.g. seventeen would become a1 in hex rather than base-whatever-encoding eight bytes).

As for concrete encodings, I see the following options:

• base10: arguably the easiest one for humans, but the least compact option
• base16: by far the simplest one (unlike all the other formats, there are neither padding nor canonicity issues)
• base64: what all the other legacy stuff already uses
  • padding or no padding?
• url-safe base64: compact and, well, url-safe
  • but all the other legacy stuff is already regular base64
• base58: even human-friendlier than base64 while still staying pretty compact, but probably the most complicated one
• base32: @keks said so =P
  • any particular reason you favor this, or was it just a placeholder suggestion?

Personally I think writing the number in base 10 or base 16 is easier for humans to deal with than encoding eight bytes in some weird scheme.