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.