Since we have lots of new users, some of whom are interested in subassets, and the subasset CIP has not yet been implemented, it won’t hurt to have a second round of discussions.
I think we all agree on the main idea but the exact parameters may perhaps be tweaked?
These are the specification in the CIP:
Subasset names must meet following requirements : 1a) 1 to 250 characters in length (ie. PIZZA.X or PIZZA.REALLY-long-VALID-Subasset-NAME) 1b) Contain only characters : a-zA-Z0-9.-_@! 1c) Cannot start or end with a period (.) 1d) Cannot contain multiple consecutive periods (..) 2) Subasset can only be issued from same address that owns the parent asset at the time of the issuance. 3) Subasset can be transferred to a new owner address after initial issuance (if necessary) 4) Subasset has issuance cost of 0.25 XCP (anti-spam)
@JPJA
Allowing subassets to be transferred to a different owner seems like it diminishes the value of the child/parent relationship since it now longer denotes a same-issuer relationship.
Are there any use-cases we know of where this is a desirable feature? The ones that come to my mind, you’d want to have the parent asset ownership govern ownership of all child assets if just to make it simple to infer what kind of relationship exists between the assets.
Re: XCP cost, IMO this is already metered by BTC transaction costs. This seems much more likely to be a concern if you have subassets which can be owned by someone other than the owner of the parent asset. For example then you can have someone who buys the “PIZZA” asset monetize it by issuing PIZZA.DOMINOS PIZZA.ROUNDTABLE etc and selling the individual assets. In that case the anti-spam fee makes sense.
But if buying pizza means that you have to actually sell the issuing rights to the parent asset, then the only things sub-assets will be used for is as literal subassets rather than just another level of depth to the naming convention where you turn every asset into effectively a monopolized TLD.
“The usage of colon-based separators in Counterparty is paramount as to not alter the usage of the platform to a service such as Namecoin.”
I don’t understand why the use of periods or recognized similarities to Domain naming conventions would be problematic. I would think that lessening the learning curve for Jane and John Q. Public would be preferable to using code based language such as colon’s and double colons. While a colon is used in English, a double colon is rarely used and would probably be better suited behind any GUI that the public will use. Ultimately, we want regular people, like me who have no formal education in this area, to be able to easily use this platform.
I would think that the use of a period would be universally more preferable? Is there some underlying use for a single or double colon in programming languages that would make their implementation in the naming heirerarchy more useful? Additionally, recommending quick implementation gives me pause.
@AdamBLevine
Some reasons why subasset ownerships should be transferable
Owner may want to administer it from a different address (e.g. switch to 3… multisig address)
Possible with second hand market
If main asset is sold, may (or may not) want to transfer subassets too
Regular assets, subassets and numeric assets have the same properties except the fee/name at initial issuance
I do see your point though. You may ask what other think in the Slack chat.
@Blockchaintoken
I think the overwhelming majority agrees on using a period.
It seems pretty much everyone agrees on the 0.25 XCP fee, so I’ll leave the discussion here.
I’m a bit worried that 250 chars will give designers headache. Why not cap the length at 50 or so?
Should names like PIZZA.-@! be allowed? I.e. multiple consecutive non-alphanumeric chars?
Why not allow different charsets (e.g. all UTF8 chars except whitespaces)? Chinese, Russians, Japanese etc will love this and the rest of us won’t be too confused since all names anyway will begin with B-Z, e.g. PIZZA.пепперони and PIZZA.奶酪
Sorry for the delay in replying to you JP, I’ve recently been traveling and haven’t been online much.
I’m a bit worried that 250 chars will give designers headache. Why not cap the length at 50 or so?
The reasoning behind 250 chars is because it will leave plenty of namespace for people to use to define additional subassets, etc. If we were to limit subassets to 50 characters in length you would pretty quickly bump up against the limits. For example you would not be able to support longer asset names like
EVERDREAMSOFT.SPELLSOFGENESIS.SWORD.SCIMITAR.ENCHANTED.DARKMAGIC
with 250 chars we can support really long names like:
ASSET.SUBASSET1.SUBASSET2.SUBASSET3.SUBASSET4.SUBASSET5.SUBASSET6.SUBASSET7.SUBASSET8.SUBASSET9.SUBASSET10.SUBASSET11.SUBASSET12.SUBASSET13.SUBASSET14.SUBASSET15.SUBASSET16.SUBASSET17.SUBASSET18.SUBASSET19.SUBASSET20.SUBASSET21.SUBASSET22.SUBASSET23
As far as ux designers getting headaches over longer names, I believe most wallets/explorers will be utilizing the enhanced asset data in .JSON files, and will display a custom name like “Dark Magic Enchanced Scimitar” rather than the full 250 chars.
Should names like PIZZA.-@! be allowed? I.e. multiple consecutive non-alphanumeric chars?
I don’t see any reason to disallow them.
Why not allow different charsets (e.g. all UTF8 chars except whitespaces)? Chinese, Russians, Japanese etc will love this and the rest of us won’t be too confused since all names anyway will begin with B-Z, e.g. PIZZA.пепперони and PIZZA.奶酪
I am taking the same minimalist approach to characters as used in named assets except I expand the allowed characters a bit to allow for both upper and lower case (A-Za-z), numbers (0-9), and some commonly used characters (.-_@!).
There could be a protocol change in the future to support additional characters if needed. To support all UTF8 characters would require a bunch of changes to the protocol, including changing the message encoding.
I don’t think the intention is to hex encode, then hex encode again. Your suggestion to keep it in plain text is actually what was intended in the CIP.
My first reading of the CIP was that the long asset name should be encoded in hex in the description before it is sent to the API. We all agree then that it makes sense to only encode it once.