💾 Archived View for tilde.team › ~aprilnightk › gemlog › 2022 › 05 › 24-quasidomain.gmi captured on 2022-06-03 at 22:55:51. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Hafnium Paging Protocol portal

2022-05-24 - HFNP: Details on the quasidomain system

The previous post was rather a kind of an announcement, so while I mentioned the quasidomain system in the Hafnium Paging Protocol, I didn't really get descriptive. I was asked for a complete explanation, so I decided that I should hurry up and write one down today.

I will simply copy the relevant part of the previous port here and then go into the details.

Brief explanation

Generally, to associate a name to your website, you need to buy a domain name, to make the DNS-server system know about it. Then the clients resolve your domain name to an IP.

I wanted to find a way to bypass the need to use DNS, and still be able to associate names to sites. What I came up with is a bit clunky, but it does the trick.

In HFNP, traditional domain names don't work. Instead, you have a "quasidomain name" that consists of a given server name and a quasidomain appendix.

An appendix is an 8-symbol sequence, which is derived from the XOR of the following values:

1) first 6 bytes of the SHA-256 hash of the given server name.

2) 4 bytes of your IP + 2 bytes representation of your port number.

This operation is reversible: from your server name and appendix you can retrieve the original host IP and port number.

As an example, the only currently operating HFNP-site is running at 193.164.149.68:9777, and it's called "hafniumpaging".

Its' quasidomain name is hafniumpaging.8Ig4sHZ6. The eight symbols of the appendix - "8Ig4sHZ6" - contain all that's needed to retrieve the IP and the port number without the need for any external database. They're a bit uglier than top-level Internet domains, but they're free and independent.

The actual algorithm

So, servername is "hafniumpaging", host IP is "193.164.149.68" and the port number is 9777.

Hashing the server name

First of all, we need first 6 bytes of SHA-256 hash of "hafniumpaging". Here they are:

(hex)   33 85  2D 0E 3A CB
(dec)   51 133 45 14 58 203

Turning host and port into binary

Now, the IP and the port. IP is trivial, because each of the 4 parts is a byte itself.

Port number needs to be represented as two bytes. Here's the result we get:

(hex)   C1  A4  95  44 26 31
(dec)   193 164 149 68 38 49

Note: 9777 renders into (38, 49), since 38*256 + 49 = 9777.

XORring

We are ready to XOR 33852D0E3ACB with C1A495442631. Result:

(hex)   F2  21 B8  4A 1C FA
(dec)   242 33 184 74 28 250 
(bin)   11110010 00100001 10111000 01001010 00011100 11111010

Choosing an encoding method

We actually do need the binary representation here, because here's where the trick lies.

The goal was to make the appendix as short as possible, yet at the same time a user should be able to input the appendix using a standard keyboard (and I didn't want the appendix to look like a gibberish of punctuation symbols, too).

So, the goal here is to convert this binary value into a nice-looking string.

One byte can hold anything from 0 to 255, so we could go the easy path and convert each byte into a symbol, so our appendix would have been 6 symbols long. But to do that, we need a conversion table of 256 symbols (and it has to be bijectional in order to be reversible, that is, all 256 symbols must be unique).

English alphabet has 26 letters. That's nowhere near 256. And this is the only alphabet available to _every_ computer user, too.

We could convert each byte into two symbols. Problem solved, but now we have a 12-symbol long appedix. Could do better!

The solution I went with was a specialised 6-bit encoding. 6 bits can hold values from 0 to 63. That is, an alphabet of 64 symbols.

Here's this alphabet:

0  a    13 n    26 A    39 N    52 0
1  b    14 o    27 B    40 O    53 1
2  c    15 p    28 C    41 P    54 2
3  d    16 q    29 D    42 Q    55 3
4  e    17 r    30 E    43 R    56 4
5  f    18 s    31 F    44 S    57 5
6  g    19 t    32 G    45 T    58 6
7  h    20 u    33 H    46 U    59 7
8  i    21 v    34 I    47 V    60 8
9  j    22 w    35 J    48 W    61 9
10 k    23 x    36 K    49 X    62 @
11 l    24 y    37 L    50 Y    63 &
12 m    25 z    38 M    51 Z

(A perfectionist in me screamed when two english alphabets and 10 digits totalled into 62 symbols, not 64).

Converting the binary into the appendix

Rearrange our bytes as 6-bit values.

(8-bit)     11110010 00100001 10111000 01001010 00011100 11111010
(6-bit)     111100 100010 000110 111000 010010 100001 110011 111010

(dec)       60     34     6      56     18     33     51     58
(alphabet)  8      I      g      4      s      H      Z      6

Here we go, our quasidomain is "hafniumpaging.8Ig4sHZ6".

A caveat

I was told that this system has downsides, which is totally correct. An IP change results in a quasidomain change, because one quasidomain corresponds to only one IP+port pair.

This is totally correct, and it probably wouldn't suit some crucial system which needs to be addressible by the same name regardless of what IP it sits on.

These are the reasons why I think it can be coped with:

websites, too, sometimes change their domain names, which leads to inconvenience. The way they deal with it is simple: just let others know that your site has move. Eventually, the news will spread, and the links will be edited (hopefully). Changes happen anyway, just for different reasons.

HFNP is meant to be a small, hobby enthusiast network anyway. If there is a place to make use of such a system, then it's here. :) There's a balance between convenience and independence, and here's this conscious choice to tilt a bit towards independence.