Skip to content
This repository has been archived by the owner on Feb 21, 2019. It is now read-only.

Allow hierarchical user-issue assets to be longer than 8 characters #1181

Closed
dnotestein opened this issue Dec 23, 2014 · 7 comments
Closed
Assignees
Milestone

Comments

@dnotestein
Copy link
Contributor

Currently user-issued asset symbol names can't be longer than 8 characters, but this is too restrictive for hierarchical ones I think (e.g. exchange.GLD). I've got local changes to allow these names to be up to 8 characters for each portion (e.g. T2345678.T2345678 is allowed), but I wanted to be sure this doesn't break any GUI (or at least, it's easily fixed GUI) before I commit to repo. If 17 characters total is too much, is there a compromise value? I think 8 characters is too short for a hierarchical symbol name.

@dnotestein dnotestein self-assigned this Dec 23, 2014
@dnotestein
Copy link
Contributor Author

Also, it turns out symbols are restricted to uppercase alphabetic characters, although at first glance it appears the code allows alphanumeric characters. Assuming this is the desired behavior (digits not allowed), I'll change the code to be more clear on this point. Also, do we really want to restrict symbol names to uppercase only?

@vikramrajkumar
Copy link
Contributor

I didn't realize we already had code for hierarchical assets? Is the parent (left side of the dot I assume) an account, an asset, an organization, or something else? That would affect whether we want to restrict to uppercase or not I would think.

@nmushegian @valzav

@dnotestein
Copy link
Contributor Author

The left side is required to be an existing asset (has to be registered before sub-assets can be registered). Personally, I'd like to relax the uppercase restriction on all user-issued asset symbols. And on the rule preventing digits too, for that matter.

@vikramrajkumar
Copy link
Contributor

@nmushegian can comment; I believe he is going to own the new UIA system (#1084), as well as newer features like organizations and how they will interact.

@nmushegian
Copy link
Contributor

I don't see a problem with letting each section be 8 characters.

Taking a step back, I think it's a bit of a hack and would have rather seen organizations that can own assets rather than hierarchal asset ownership. Considering assets are transferrable, will we have to maintain ownership relationship w/ extra logic outside of our object system? IDK I will talk with dan about it.

@dnotestein
Copy link
Contributor Author

Ok, after more discusion, current plan is as follows:

A primary symbol name must be a minimum of 3 and a maximum of 8 in length. Primary names can only contain uppercase letters (digits are not allowed to avoid 0 and 1 spoofing).

A hierarchical symbol name (consisting of a primary symbol name, a dot, and a sub-symbol name) can be up to 12 chars in total length (including the dot).

Sub-symbol names can contain uppercase letters or digits (digits are allowed in sub-symbols because the namespace is overseen by the owner of the primary symbol and is therefore not subject to spoofing).

Symbol names of 5 chars or less in length are more expensive to register.

To fit under the 12 character limit, it is likely that users planning to register hierarchical names will choose shorter (more expensive) symbol names for their primary symbol, so that they can mirror more primary symbol names. The max of 12 for hierarchical symbol names will allow hierarchical mirroring of long primary symbol characters as long as the primary symbol buyer purchases a symbol of 3 in size. For example, if CRY was chosen as the primary symbol, CRY.ABCDEFGH could be registered. But if a longer name was chosen as a primary symbol, such as CRYPTO, then only symbols up to 5 in length can be mirrored (i.e CRYPTO.ABCDEFGH would be too long).

I've got a basic implementation of the above (well, needs some tweaks after last discussion, but they are easy). Before I finish this up, though, will leave it up a while for any more objections/suggestions for change.

@dnotestein dnotestein reopened this Dec 29, 2014
@dnotestein
Copy link
Contributor Author

247c0e3

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants