Quote from: led_lcd on March 19, 2014, 09:32:50 PM

I've added to my proposal a textual visualization on what the hierarchy would look like.

https://bitcointalk.org/index.php?topic=395761.msg5783153#msg5783153

EDIT:
Some examples to show what I'm talking about.

Code:

Asset Short name Long name
BITT BITT
KEOdAi3q BITT.spanish.dubloon
OIu3waqn BITT.spanish.dubloon#1
RPGGAME RPGGAME
LPJhiowG RPGGAME.ruby.cracked
jrOyehHG RPGGAME.ruby.perfect
BANK BANK
OIJFE7ig BANK.I can type whatever I like

Client visualization

Code:

BITT
+-spanish
   +-dubloon
   +-dubloon#1
RPGGAME
+-ruby
   +-cracked
   +-perfect
BANK
+-I can type whatever I like

I tried an actual example based from this suggestion on the official forum.

Here's how it could work if we really do have 256^8 = 18446744073709551616 names according to PhantomPhreak.

1. User issues asset CAKE.
   This steps works normally by creating the top level asset CAKE.

2. User issues asset CAKE.CHOCOLATE
   a. Since this is not a top level asset (it has the dot), the client software will hash CAKE.CHOCOLATE and fold it into range using hash256(CAKE.CHOCOLATE) % 18446744073709551616 = 14342628182955096483. Now it will encode the ASSET_ID of 14342628182955096483 into base26 to get a valid asset name of FUHSJLMRZXYYVR.

   b. Client checks that I own CAKE. If so, it sets the protocol to issue FUHSJLMRZXYYVR setting the long name to CAKE.CHOCOLATE

3. User issues asset CAKE.STRAWBERRY
   a. Again, the client will hash CAKE.STRAWBERRY using hash256('CAKE.STRAWBERRY') % 18446744073709551616 = 12954728149517977030 resulting in this asset name: FFTOTODXVAJETA

   b. Client checks that the user owns CAKE before issuing FFTOTODXVAJETA with the long name of CAKE.STRAWBERRY

4. User issues asset CAKE.DOUBLEFUDGECREAMYVANILLAWITHCHOCOLATECHIP
   a. Client hashes hash256('CAKE.DOUBLEFUDGECREAMYVANILLAWITHCHOCOLATECHIP') % 18446744073709551616 = 14967343411115770189 or GAVXSUXGXBLXSV

   b. Client checks that user owns CAKE. Unfortunately, a squatter knew that the user would be issuing this delicious cake and squatted the asset name GAVXSUXGXBLXSV. It just means that the CAKE owner has change the long asset name a bit to avoid this collision. Because the squatter does not own CAKE, the long asset name for GAVXSUXGXBLXSV could not be CAKE.DOUBLEFUDGECREAMYVANILLAWITHCHOCOLATECHIP.

5. When we buy/sell CAKE.CHOCOLATE and CAKE.STRAWBERRY, we will actually be exchanging FUHSJLMRZXYYVR and FFTOTODXVAJETA through the Counterparty protocol. Our clients/blockscan will show the long asset names.

As far as I can tell, this suggested implementation should work and be compatible with the existing protocol.
This is actually another great suggestion the more I think about it now.

It reminds me of the 8.3 short/long filename. It should be okay to allow lowercase characters, numbers, and symbols for the long asset name since it will be hashed and encoded into base 26 anyway.