On 12/24/2021 5:24 AM, Michael Richardson wrote:
Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: mcr> I don't think that we can really give out 7B short callsigns though. I want to repeat this: I don't think that there everyone can have a short callsign. At 5-bits per (english) glyph (because ALICE == Alice == alice), we need 8 glyphs to get 240 callsigns. And that assumes that we hand out meaningless strings. While a couple of billion people would prefer non-english callsigns, I don't think that helps us much since random sequences of Mandarin or Kanji probably don't help. Yeah, a series of pooh emoji will be a sought after callsign, I just don't think we want to repeat twitter/facebook/etc. handle land grab.
Kim Cameron, Josh Belanoh and I worked on Call Signs at Microsoft many years ago, with the idea of using call signs as a place holder for a public key. (See: https://uspto.report/patent/grant/7,929,689.) We considered the call sign as a short alphanumeric string that could be translated to a short binary string, matching the first bits of the hash of the public key. We also assumed that another set of bits of the hash would be set to zeroes. The size constraints in that design are obvious:
* the sum of length of the call-sign bit string plus number of zeroes must be sufficient to prevent forgeries
* the length of the call-sign bit string must be sufficient to prevent collisions
The collision risk itself depends on the population size. If call signs are used as "pet names", they are only expected to be unique in the small scope of "pets". But if thy are expected to be unique worldwide and forever, then they have pretty much the same design constraints as IPv6 addresses. They can probably be a little shorter because there is no expectation of routability, but I would be surprised if this required fewer than 80 bits -- I would probably go for 96 bits.
-- Christian Huitema
