Olà
based on :
Imagine : 
let say that the database is maintaining an index
when a new identity is joining the WOT, it increment an index ( <= represented by a number wich refer in the original algorithm as the " distance " or " z value" … )
- what follow can be seen like a SQL request : “select pubkey from wot order by entry_date/timestamp”
assume we got such a request that give us :
0 ‘12JDJibbgZPRfD6Hoecg8rQRvCR5VYrMnqzfhQYmAr3k’
1 ‘13XfrqY92tTCDbtu2jFAHsgNbZ9Ne2r5Ts1VGhSCrvUb’
2 ‘13fn6X3XWVgshHTgS8beZMo9XiyScx6MB6yPsBB5ZBia’
…
2108 ‘yqBbrgDm5SLQj6rgPup6Nc1AUZTetERYBuUtbrm53Pn’
2109 ‘zV3yXy5iC68ksE93AGp6stCoczaSfNFE2Hac7h1q7ZA’
4294967295 ‘HD3Syggysdoe7c8UXwgTmxzvKJ7io4Qxrr5jSrDUnfjU’
associated index through a 32 bits number (unsigned int) can be computed to make 2D point like that :
0 ‘12JDJibbgZPRfD6Hoecg8rQRvCR5VYrMnqzfhQYmAr3k’ [0, 0]
1 ‘13XfrqY92tTCDbtu2jFAHsgNbZ9Ne2r5Ts1VGhSCrvUb’ [1, 0]
2 ‘13fn6X3XWVgshHTgS8beZMo9XiyScx6MB6yPsBB5ZBia’ [0, 1]
…
2108 ‘yqBbrgDm5SLQj6rgPup6Nc1AUZTetERYBuUtbrm53Pn’ [6, 38]
2109 ‘zV3yXy5iC68ksE93AGp6stCoczaSfNFE2Hac7h1q7ZA’ [7, 38]
4294967295 ‘HD3Syggysdoe7c8UXwgTmxzvKJ7io4Qxrr5jSrDUnfjU’ [65535 , 65535]
in that way users can do transaction like :
" send 10 Junes to [6, 38] " <=> where [6, 38] 2D coordinate correspond to index 2108, mapped to public key => yqBbrgDm5SLQj6rgPup6Nc1AUZTetERYBuUtbrm53Pn
" send 30 Junes to [0, 1] " <=> 13fn6X3XWVgshHTgS8beZMo9XiyScx6MB6yPsBB5ZBia
etc…
- one point about the uint32 maximum number (inclusive) is => 4294967295
wich let index 4 294 967 295 peoples without problem.
the 4 294 967 296 n’th WOT member will break down the feature since the index with 32 bits when converted will overlap,
meaning that his coordinate point will give => [0, 0] => allready mapped, so 2 public key will match…this is the limit…
- but if we either want to step through,
encoding/using a 64 bits number (unsigned long long) will give us coordinate point like :
0 ‘12JDJibbgZPRfD6Hoecg8rQRvCR5VYrMnqzfhQYmAr3k’ [0, 0]
1 ‘13XfrqY92tTCDbtu2jFAHsgNbZ9Ne2r5Ts1VGhSCrvUb’ [1, 0]
2 ‘13fn6X3XWVgshHTgS8beZMo9XiyScx6MB6yPsBB5ZBia’ [0, 1]
…
2108 ‘yqBbrgDm5SLQj6rgPup6Nc1AUZTetERYBuUtbrm53Pn’ [6, 38]
2109 ‘zV3yXy5iC68ksE93AGp6stCoczaSfNFE2Hac7h1q7ZA’ [7, 38]
4294967295 ‘HD3Syggysdoe7c8UXwgTmxzvKJ7io4Qxrr5jSrDUnfjU’ [65535 , 65535]
4294967296 ‘ePs5xpo1rMQgvrKrthYXSLHMawKTNebqFnUqifW5P6v’ [65536 , 0]
18446744073709551615, ‘QcwFU8YbZRtvLxLGHqznmEbGFvU9YUETEQc6cFmRRg8’ [ 4294967295 , 4294967295 ]
meaning a maximum (inclusive) of … 18 446 744 073 709 551 615 members before overlapping.
Resume 
Possibility to pay someone who has been member knowing his coordinates
can be a new opcode integrated along SIG/XHX/CSV/CLTV
call that P2C for " pay to 2 coordinate ",
it take 2 parameters => the x,y coordinates of the point in 2d space
which can be done in that way :
P2C(0,0)
P2C(65535,65535) [max when index 32 bits]
or
P2C(4294967295,4294967295) [max when index 64 bits]
where based on example above :
P2C(0,0) <=> pay to 12JDJibbgZPRfD6Hoecg8rQRvCR5VYrMnqzfhQYmAr3k
P2C(65535,65535) <=> pay to HD3Syggysdoe7c8UXwgTmxzvKJ7io4Qxrr5jSrDUnfjU
& so on & so forth…
Constraint :
maintaining the index
and not remap associated public key with the coordinate point.
The first WOT member take the first index,
he will have the coordinate [0,0] for all the life of the system,
even if he loose is " WOT member status " and / or gain later this state,
he will forever be able to receive funds when people make transaction which refer to coordinate [0,0] <=> P2C(0,0)
Minimizing infos to store in the database for the transaction document:
database grow up…
count the opcode string : P2C / SIG and parenthesis
such a string “P2C(4294967295,4294967295)” take less space than “SIG(QcwFU8YbZRtvLxLGHqznmEbGFvU9YUETEQc6cFmRRg8)”
P2C(0,0) => 8 characters (minimum)
P2C(65535,65535) => 16 characters (maximum) [32 bits index ]
P2C(4294967295,4294967295) => 26 characters (maximum) [64 bits index]
with a base58 encoded string, a range of [48, 49] characters
SIG(QcwFU8YbZRtvLxLGHqznmEbGFvU9YUETEQc6cFmRRg8) => min 48 characters
Personnal opinion 
i think it could be more “user friendly” to deal with tuple of numbers instead of 43/44 characters.
- more simple to memorize & share with others in “everyday life”, just communicate coordinates
Pay to “7, 38” instead of Pay to “zV3FXa9…blabla…”
in a way like pin [phone/credit card] to remember… avoiding to scan QRCode (for simple numbers)… or searching uid/public key…
- in a case where people make errors with the coordinates, let say [1222, 0] instead of [1223, 0]
the money will be transfert to an account wich :
-
was allready used by someone ( by a Wot member )
-
or potentialy associated to a futur incoming.
it present intuitively “less lost” of money in the system than a base58 string mistake…
What can be done 
It can serve to build 3D point coordinates so we can imagine something like
P3C(0,0,0)
with a max index/distance of … 281 474 976 710 655 inside a 64bits number wihere each points (x,y,z) are 32 bits numbers
give us a P3C(65535,65535,65535) , meaning 22 characters for the string in the database point of view
based on example above :
0 : P3C(0,0,0) <=> pay to 12JDJibbgZPRfD6Hoecg8rQRvCR5VYrMnqzfhQYmAr3k
2108 : P3C(2,2,11) <=> pay to yqBbrgDm5SLQj6rgPup6Nc1AUZTetERYBuUtbrm53Pn
2109 : P3C(3,2,11) <=> pay to zV3yXy5iC68ksE93AGp6stCoczaSfNFE2Hac7h1q7ZA
4294967295 : P3C(2047,2047,1023) <=> pay to HD3Syggysdoe7c8UXwgTmxzvKJ7io4Qxrr5jSrDUnfjU
4294967296 : P3C(0,0,1024) <=> pay to ePs5xpo1rMQgvrKrthYXSLHMawKTNebqFnUqifW5P6v
281474976710655: P3C(65535,65535,65535) <=> pay to…XXX
281474976710656: too big…
Huho
well, hoping that this is sufficiently clear at 1st reading,
i will push some C code to demonstrate conversions (encoding/decoding) functions if you want/think it can help/believe it could be a good idea
