The 'name' at the protocol level is tied to the transaction handling - but asset representation on the client level can be achieved by organizing the 'text' field of the asset issue.
There is still the possibility of making look-alike assets i.e.:
Real Asset:
--name=ffzdjeVT
--text=~~ GHS ~~1 GHS mining issued by Rockminer ~~
www.example.com/assets ~~
Look alike:
--name=ffzdJeVT
--text=~~ GHS ~~1 GHS mining issued by Rockminer ~~
www.example.co/assets ~~
Which could be dealt with in several ways i.e. Allowing a user to track/flag an asset on the client level (presumably for assets where they have verified the PGP key).
Alternatively you could make the default client-side search take an asset standard form where the --name field is defined by the first 8 bytes of the --text field hash, that would make it quite difficult to issue a-near identical looking asset.
The default client side search at this time is only searching for the asset name on the protocol level now so inputting 'ROCKMINER' would find ROCKMINER, ROCKMINERB, ROCKMINER123 etc right?
if later that would be expanded to allow search of the --text field (however the developers agree to format and parse it),
because real rockminer owner for example can create:
--text=~~ GHS ~~1 GHS mining issued by Rockminer ~~ www.example.co/assets ~~
and the asset name is derived from hash of the agreed upon 'name section' which (if you are using sha1 hash for example) would be:
--name=6cd78dfa
now nobody can create another asset with the exact text 'GHS' right? because it would have conflicting hash (duplicate asset id)
is that what you are proposing?
