These are legit concerns. My current opinion is based more on where I personally think the CP platform is and will be and the most common use cases for assets/tokens going forward.
A Counterparty subasset system is a very interesting thought experiment. I’d like to see some variation of it exist and it could vitalize the platform, or it could make things messier.
I don’t think subassets could be used for every single use case that one can think up. Trying to implement it in a way that is maximizing flexibility will likely result in more negative outcomes. So I propose a simpler approach that would minimize or avoid entirely some of the concerns voiced thus far.
I prefer SUBASSET.ASSET but i’ll save further thoughts on that for later (another post maybe).
I think from the get-go, their needs to be some limitations and requirements before a subasset can even exist on an asset name.
The asset should be clean. Defining what this means can be another discussion but generally, a clean asset is one that has not truly been used for anything. The token issuance is small and no or few transactions. This is as opposed to an asset that has already been used for a project (i.e. LTBCOIN, SWARM) or just massively spread of tokens for experimentation and non-serious use (i.e. HATE, DIRT). This will immediately invalidate many assets and will annoy those asset owners, but I think it’s the right approach.
The asset must be delegated as a namespace asset and is no longer able to function as a native asset. This means the asset must be locked and probably all tokens issued burned if possible. Again, this becomes an issue where only unused assets qualify. Might not be popular among some asset owners but their are benefits to doing this and if asset owners who want subassets but dont qualify under these proposed rules, they can always buy/create another asset that could fill their needs. The benefits, I think, outweigh the small amount of limiting cases.
In addition to being locked and tokenless, the asset cannot be transferred to a new owner without additional multisig-esque process in place. This may not be necessary but it came to mind.
The ASSET Owner can curate (approve/reject) any SUBASSET request. This would be a great use case for a simple smart script/config/contract that could be setup to either allow-all, disallow-all, owner-review etc. This would be the ONLY power an ASSET Owner has (as a Gatekeeper). If a subasset is created by another user and approved, the subasset is just like any other asset and NOT controlled by the ASSET Owner, it is only related to the “Namespace”. ASSET Owner could close and open “registrations” via this config script or wallet settings.
Subassets can never have its own subassets. It’s a one-level deep system only.
I’ve not put too much thought into any of this and it might show here I’m just contributing some thoughts that are coming to mind in the chat room so logging it here. Look forward to other opinions.
I really like the thought process behind Sull’s suggestions. Many of those ideas have been vetted through the Domain process, which is a mature platform at this point. While I am not particularly excited about the sub-asset idea in general, I can see that there is a need beyond my narrow interest.
There is a definite need for limits, otherwise existing token endeavors could be harmed. I think Sull covers most of them very succinctly. Using the following example, MCDONALDS.WIFI or WIFI.MCDONALDS, it has a definite impact on possible future values depending on wether I own WIFI or MCDONALDS. If I own both, then I’m in a particularly beneficial spot. However, without common sense limits such as the suggested namespace or native designation, some asset registrars/owners are going to be unhappy and users could become confused and be less likely to adopt.
Related to this, in Slack there’s been a proposal to add a condition to lock issuance on the asset so that it and subassets cannot be used for anything but namespace.
The more I read about possible problems, the more I think it may be a better good idea to consider a separate type of tokens for namespace and leave the asset namespace flat.
My understanding was that subassets would be used by the issuer to consolidate their various assets under one asset name, but I see some want to use it for TLD-type of sub-domain hosting which is more of a branding/namespace type of use and that’s why I think in case all subassets aren’t owned by the same owner and asset issuance locked, I’d suggest to use a new namespace type of token.
I think there should be a fee. Subassets would consume space and resources in the CP database. Someone ought to pay for that.
Lots of interesting replies. At this point maybe we should better simplify the discussion to these three alternatives.
Keep the asset system as is. If it ain’t broken, don’t fix it.
Introduce subassets. If this is the best option we can discuss details later.
Make an (unofficial?) layer for wallets and explorers. A format for info/hash in the description field can serve as the asset name, maybe for numeric assets.
I think sticking to the current system is not a bad option. We will never run out of names. There are more than 100,000,000 .com domains and you can still find okay unregistered domains if you’re not willing to pay for one. CP has about 30,000 alphabetic assets.
The main reason I suggest subassets is because some issuers issue several assets (e.g. Spells of Genesis) and with subassets they can have a name policy on format “ASSET-x”. Being able to verify an asset only from its name adds value to users. Another example is a bookmaker. He issues assets whose names fully describe the underlying bets. Without subassets trolls/squatters can deliberately pre-register assets and cause harm.
If there is a clever way to achieve the same with a meta-layer, then maybe that’s the way to go?
Does anyone in this discussion have a use case for subassets that they have bumped into yet? Does this solve a real world problem for anyone here?
I like the discussion here because it helps us think through the ramifications. But if it isn’t a real world problem yet, I suggest we wait on this until we know the needs of the real world problem we are trying to solve.
It’s not a real world problem… because CP isn’t a real world platform (yet). It’s too niche to think too hard on whether a feature solves real world problems. I think we can discuss this issue in the context of general namespace/identity concepts that have existed prior and base some decisions on that. We can also look at some current trends and use cases, such as SoG, and clearly see how sub-assets could improve usability and organization of token based systems.
On a more casual level, I generally think that subassets would pump some life into the community/platform. As great as it is, I think this would be a deep step into the “naming/identity on the blockchain” space where other projects are starting to find momentum. So it’s an easy way to become even more relevant and functionally diversified.
I mentioned over in slack and skype the rather crazy notion of alphabetic subassets on numeric assets. This would essentially allow, depending on implementation, anyone to own any name, over and over again. WTF? Wallets could hide the numeric asset and only show subasset and owner address info.
This would destroy the unique name system that is in place and bring it closer to how other platforms work (NXT, OpenAssets/CC, Omni non-unique names). I personally like both approaches and have leaned more towards non-unique as being the right approach but I also like scarcity despite “squatting” issues. Long time ago, I used to talk more on this topic back when DogeParty launched.
So I bring this up so the proposal can include or exclude subassets on numeric asset names. It’s not something that has been brought up yet I dont think. The easy answer here is NO! Preserve some scarcity! But am curious what others might think.
Lastly, I put some more thought into the issue and I don’t think the protocol should bother with the additional rules that I proposed earlier (Locked and Tokenless Namespace Asset Delegations). I still think that would be smart, but would likely hinder the feature from getting added sooner than later and in reality, the rules could be instead published as consumer/business warnings and guidelines to making good decisions about subasset usage.
If possible, could the sub asset be used as a singular proof of existence? I dropped a document in a SHA256 generator. Lets say it represents a Gold Bar and I want to register the bar of gold via a service that does just that. I use a GOLDBAR token and am allowed, for a small fee to append my hash as a subset.
While I understand this is currently impossible and seems a bit ridiculous as I type. Maybe one of you know of a more elegant method to use a subasset in this manner? Is it possible to shorten that hash and make it compliant with CP as shortened URL’s are used today, or make CP sub-assets compatible to that type of info as a suffix?
I’m guessing the token or subset token info could contain the hash and a link could be employed to point to the location of the proof of ownership/existence? As you may be able to tell, I’m a lay-person, trying to grasp the concept with 10 thumbs. Hopefully this makes some sense.
Subasset is currently not possible, but you can issue a numeric asset. You will need to convert the hash to a numeric representation and issue the numeric asset with one indivisible share.
Yes, it’s a real world problem. In Brazil assets in the brazilian stock exchange (Bovespa) are of two types: Preferential and Ordinary. Doesn’t matter explain these two types right now, but they exist. Below is a example:
It’s important to set all parameters right. Once released, it is difficult to change them, and I wonder:
What is the optimum max length?
Which characters should be allowed?
How much should the issuance fee be?
Should a child asset be allowed to issue its own child asset?
My opinion:
-1. It should be possible to display an asset name on one line on a mobile device. It should also be easy to memorize a name and differentiate an asset from any other asset. Otherwise the important uniqueness property is violated. I think the sweetspot for max length is somewhere around 30-40 characters.
-2…For the reasons mentioned above, I vote for [A-Z0-9.-]. A dot must follow immediately after the issuing asset’s name and must be followed by [A-Z0-9], i.e. not another dot or a hyphen. A hyphen cannot be next to another hyphen or a dot.
-3. Is a fee necessary? Unlike for regular assets, a subasset namespace is not a public resource (no first come, first served - the asset owner has the sole right to issue subassets). However, if a fee is needed to protect Counterparty servers from overloading, then an apt fee should be set for this.
-4. Currently I think it makes most sense if XXXX can issue XXXX.Y but only XXXX.Y can issue XXXX.Y.Z. Another option is that XXXX can issue both XXXX.Y and XXXX.Y.Z while XXXX.Y cannot issue any subassets. However, I am eager to hear arguments for and against. May change my mind on this.
Accepting a CIP is no guarantee that the CIP will be adopted or code will be merged to support it. Another author might submit a competing CIP that solves the problem of subassets.
After a CIP is merged in draft status, it will be accepted or rejected at some point in the future. For a Standards Track CIP to move from draft to active status, it must have code that implements it.
@jdogresorg - Do you have any plan to submit an implementation for CIP 4? Or do you know anyone would be interested in writing and testing the Python implementation?
@deweller - I do not code in python, so I will not be submitting an implementation for CIP 4. I believe @robby_dermody recently said that either himself or @rubensayshi would probably be writing the implementation in the coming months if no one else does.
yeah, ruben or I…it’s on our list (if it’s me, it’s something I’m looking to start after this build script revamp work I’m doing not to move to Docker)
I’m just contributing some thoughts that are coming to mind in the chat room so logging it here. Look forward to other opinions.