CIP-0067 | add ADA Handles Virtual SubHandle

[papag00se]

Reserving a label for Virtual SubHandles. These are Handles that the issuer (root Handle owner) retains ownership over, but still allows for address resolution to a specified wallet, and personalization features.

[rphair]

@papag00se this is the first time we'd be taking on a direct modification to this data structure. I can see your project itself is legitimate so can you please help us understand (so we know better how to deal with CIP-0067 label requests in the future):

1 - Why does this application need its own Asset Name Label as opposed to a CIP-0010 Transaction Metadata Label?

2 - Why is there not a corresponding addition to CIP-0068 (https://github.com/cardano-foundation/CIPs/tree/master/CIP-0068#labels) like we have with #494?

• Maybe @alessandrokonrad can answer this; I don't know how much these labels are expected to proliferate & whether it makes sense to leave them undocumented in CIP-0068.

3 - Since "class": "Virtual_SubHandle" leaves this label in a class by itself, is there not a more general category that could be assigned here that could be applicable to other labels? Otherwise the class field isn't fulfilling a purpose here.

[alessandrokonrad]

I'm not sure if this should be accepted as a valid class. What does this represent?

[papag00se]

An upcoming feature of ADA Handles is SubHandles. A root Handle owner can choose to sell NFT SubHandles that essentially behave just like Handles today. They are actual NFTs that the root Handle owner loses control over the moment it mints and is sent to the new owner.

Virtual SubHandles are SubHandles that the root Handle owner retains control over and can revoke or reassign. This means this particular class of Handle will need to resolve addresses by UTxO datum in the token.

This is to support more corporate or enterprise use cases where SubHandles may be temporarily issued to employees or representatives of the larger entity. It can also support other smaller business use cases of SubHandle "renting".

Virtual SubHandles will have nearly all the same personalization characteristics of Handles.

[papag00se]

I should further clarify that since Virtual SubHandles do not have an "Owner Token" component like our CIP-68 Handles/SubHandles will, DApps will need a way to identify them apart from these tokens.
(222) tokens resolve to the address they reside in.
(314) tokens resolve the the address within the UTxO datum

[papag00se]

With the (222) Handles - the personalization data will be housed by the (100) Reference Token.
With the (314) Virtual SubHandles - the personalization data will be housed in the token itself.

[alessandrokonrad]

• Maybe @alessandrokonrad can answer this; I don't know how much these labels are expected to proliferate & whether it makes sense to leave them undocumented in CIP-0068.

@rphair CIP-0067 is independent of CIP-0068. Labels can be used for any kind of tokens and different token standards. It doesn't need to be in combination with CIP-0068.

[alessandrokonrad]

1 - Why does this application need its own Asset Name Label as opposed to a CIP-0010 Transaction Metadata Label?

I wonder about this too. It seems like it's very ADA Handle specific. Maybe this should be more generalized.

[papag00se]

Thank you for taking a look at this!

Why does this application need its own Asset Name Label as opposed to a CIP-0010 Transaction Metadata Label?

ADA Handle won't be using transaction metadata to represent Virtual SubHandles. We will be using a token with UTxO datum sitting at smart contract. The smart contract will allow changes to the UTxO datum based on some specific logic. Wallet DApps will resolve a subclass of Handle addresses based on this datum.

Why is there not a corresponding addition to CIP-0068

I believe Ales answered this already, but CIP-67 isn't explicitly tied to CIP-68. CIP-67 defines classes of data that DApps can use to identify what kind of datum they are dealing with within a UTxO. In our case we have dozens of DApps that use our protocol. This would help them identify the different tokens in use in that protocol.

Since "class": "Virtual_SubHandle" leaves this label in a class by itself, is there not a more general category that could be assigned here...

I'm not exactly sure what is being asked here, but I am happy to try and answer. Handles are used in dozens of DApps (we suspect the number is closing in on 100 DApps, if it hasn't passed it already), including nearly all of the wallets, exchanges, and explorers in use on Cardano today. So while the class may be more specific to our protocol, Handles itself is in use by a large population within Cardano.

[papag00se]

1 - Why does this application need its own Asset Name Label as opposed to a CIP-0010 Transaction Metadata Label?

I wonder about this too. It seems like it's very ADA Handle specific. Maybe this should be more generalized.

I did ask this question in a private chat with a prominent contributor to the CIP process. It was their opinion at the time that ADA Handle can and should be considered a protocol if that is our intention. And it is. We are working tirelessly to take us down the road of decentralizing all aspects of ADA Handles. Where Kora (the current stewards of ADA Handles) will likely always be contributors to the protocol, we will slowly pass the reigns of stewardship to the community. We are already taking steps to do this. It's just a delicate process and we aren't a huge team.

[rphair]

All right @papag00se, I guess the argument that ADA Handles could be considered their own "application domain" (so to speak) answers the last of my questions above.

I think we should still talk about the choice of class (whether it should have more generality) at the next CIP meeting if not already settled on GitHub in the meantime (cc @KtorZ @Ryun1 @SebastienGllmt) & I will look out to make sure it's on the agenda if discussion still needed.

[papag00se]

I think we should still talk about the choice of class (whether it should have more generality) at the next CIP meeting if not already settled on GitHub in the meantime (cc @KtorZ @Ryun1 @SebastienGllmt) & I will look out to make sure it's on the agenda if discussion still needed.

Fair enough. We were considering what an abstracted version of this would look like. The intended purpose would be for non-NFT address resolution, which boils down to a single field in our case. We do have other fields that are related to Handle Personalization in this token, but I'm not sure that feature is very "abstractable".

Our other option is to simply make use of one of the 16 labels reserved for private use within a policy ID. But as I mentioned earlier, we were encouraged to represent our intention as a protocol and make it part of the official public label space. Which does reflect our direction.

[papag00se]

Did this make the agenda at the last CIP meeting? Curious to hear the latest thoughts.

[rphair]

Yes @papag00se we discussed it but the resolution never got recorded here & my apologies for that. We are transitioning to a new format for agendas which will mark resolutions as notes (https://hackmd.io/@cip-editors - cc @KtorZ) but while in this flux some action items for editors were stuck in our own personal notes for this meeting cycle. 😖

What I meant to say: there was more discussion about how CIP-0067 needs to be updated when a candidate class is added (everyone agreed that your label itself is needed). This asset name label is in its own class whether Ada Subhandles are considered their own "protocol" or not. The consensus as suggested above is that we need an update to CIP-0067 itself including:

• what constitutes the requirement for a new class
• what process to follow when adding a class, including whether CIP-0067 needs to be updated or not
• possibly an enumeration of existing classes (a list which will grow with time)
• etc.

We had agreed to ping @alessandrokonrad about this and I don't know if that's been done: I should have done that here, and long ago. @alessandrokonrad can you feed back ASAP about what kind of asset name label classification process we need, hopefully before our CIP meeting (in about 8 hours) so we can discuss this issue today with your input (or you might even come to the meeting 🙏)?

[rphair]

@papag00se @alessandrokonrad it's confirmed on meeting agenda here: https://hackmd.io/@cip-editors/65

[rphair]

@papag00se without any contribution from @alessandrokonrad yet, another way to move this forward (as came up in the CIP meeting ended a few minutes ago) would be for your own project team to contribute a procedure to add new asset name label classes as in #504 (comment). It seems your project has a good understanding of why a new class would be needed, so are as good a candidate to add this documentation as anyone.

In hindsight we felt more enthusiastic about adding the 444 class as in #494 (comment) because the documentation of that class came in with a full definition from the beginning. What I anticipated in #504 (review) is that adding a label can be done trivially but that adding a class should at least have some documentation about who else might be using the class.

@KtorZ will probably want to add detail to this but I wanted to pass along this idea right away in case it helps move this PR forward. The one thing that seems definite is that something will have to be added to CIP-0067 before using new asset name label classes in the registry.

[papag00se]

It's possible I misunderstood the purpose of the "class" designation. I was under the impression that is was a one-to-one relationship between an asset label and a class. If one wanted to add a label, they also must add a class. The statement -

...adding a label can be done trivially but that adding a class should at least have some documentation about who else might be using the class.

- causes me to think they are not actually one-to-one. An asset label may or may not have an asset class, but an asset class would always have a label. (Maybe the latter isn't even true?)

So now I am in doubt and don't have the same confidence you have that we know what we're talking about. Maybe with a bit more clarity I could get that confidence back.

[rphair]

@papag00se likewise I am somewhat underconfident - in my case, about the practical consequences of the classification scheme. Therefore I don't know if it may be silly to ask: @alessandrokonrad would there be any practical use for an undefined or default class?

[perturbing]

For some clarity for the CIP process and guidance for the Ada Handle team.

Definition of an asset class: "A grouping of native assets on the Cardano blockchain that share similar characteristics and properties as defined by their protocols or issuers."

Here the "property" refers to an attribute, quality, or feature that is inherent to an object or entity that we are trying to represent with a native asset (how things behave). For instance, properties could include its fungibility, its divisibility, or the total supply of the asset.

Here the "characteristic" is typically a distinctive feature or quality that helps to identify, distinguish, extend or describe the object at hand (how things look). Characteristics might include behaviors or patterns that are not inherent to the native asset but emerge from how it interacts with its environment or how it is expected to be used.

An example; for the class of NFT's, you expect, for each native asset in this class, some particular formatted metadata to exist that needs to be resolved (a characteristic). Besides that, for a NFT, as the name suggests, we expect that there should only exist one (a property).

To identify and come up with a new asset class, and thus a label, one should ask these questions: Given a representation of an object that you represent by a native asset, what are its characteristics and properties? Given these characteristics and properties, why do these not fit into another already existing class? Given my new class, what are the general properties and characteristics that all members in the class share? Abstract away of the project-specific design requirements. If some data needs to be resolved, in what format do we expect this for a general member in the class?

Hope this helps. Could you format a table of characteristics and properties for your generalized sub handles? Additionally, a rationale for each is appreciated, remember that as an outsider of the handle business, I have no clue what things are supposed to do. Currently, I do not see why the virtual sub handle is not in the NFT class and why its metadata could not handle the logic of being a virtual sub handle?

@rphair and @alessandrokonrad, I think we should add something to CIP 67 to guide this process, what do you think of the above? Let's take this PR as an experiment and later reflect on how we would do this in the future.

[rphair]

@perturbing I think the language above (included under a subheading, with the enumerated points, definitions & questions bulleted etc. 🤓) would be very good to add to CIP-0068 unless @alessandrokonrad has any objections or modifications.

I also think that if CIP-0068 is to be asking these comprehensive questions, then the answers should be officially documented (not just in the proposer's PR) when proposing a new asset class. So far, that place has been CIP-0068... getting back to what I was asking in #504 (review).

So @perturbing unless I have gotten this point wrong, I think there should be a heading like "How to submit a proposal for a new asset class" including the requisite modifications to both the CIP-0067 array and the CIP-0068 text. An alternative might be adding some new fields to the array with some kind of standardised characteristics and properties... but I feel that anything like this would be outgrown and/or a lot of trouble to maintain.

Could you format a table of characteristics and properties for your generalized sub handles?

I guess this means we are asking @papag00se to include an addition to CIP-0068 in this PR where the material above can be added. Again, please correct me if I'm wrong.

Let's take this PR as an experiment and later reflect on how we would do this in the future.

yes, if this works as a model then please @perturbing submit another PR with the general additions to CIP-0068. If necessary I will try to write it, although I don't work with the practical applications enough to be able to defend the language in the editorial process.

Once that's done I would hope @mmahut (from Blockfrost, a major implementor of CIP-0068) can review this process to ensure in advance that it will work well with their own methods. 🙏

[rphair]

Discussed in CIP editors' meeting today & thanks @perturbing for attending and for your ongoing help in this area.

We noted again that CIP-0067 and CIP-0068 are considered to be separate, as @alessandrokonrad already pointed out, but clarified that a section should be added to CIP-0068 when there is common metadata to define. So @papag00se regarding whether a CIP-0068 update is required, you can decide based on the metadata that tokens in your new class would need.

@perturbing also confirmed he has been in touch with the ADA Subhandle team to help answer these questions. Current status is that we're waiting for the results of their consultationcommunication to be recorded here before proceeding with this PR.

[rphair]

@perturbing @papag00se this item is on our CIP editors' meeting agenda again (https://hackmd.io/@cip-editors/69 - Tuesday 04 July 16:00 UTC) so please come if you can present your discussions suggested in #504 (comment) & #504 (comment) or at least post your progress here. 🙏

[rphair]

@perturbing thanks for confirming before the CIP Editors' meeting today your offer to "write something up" regarding #504 (comment).

FYI @papag00se we agreed at that meeting to mark this Waiting for Author until we have that statement, here in this thread and/or the PR content, in which we are hoping to see both:

1 - implications for this PR (what ADA SubHandle team actually wants for classes, exactly why the need it, and exactly how others might use it)

2 - implications for CIP-0068 as requested in #504 (comment) & #504 (comment).

[perturbing]

@rphair

I am currently working on rethinking and redoing some wording and formatting on the two CIPs to make them more clear. However, I am currently on vacation so this will take some time as it is not a priority.

@perturbing also confirmed he has been in touch with the ADA Subhandle team to help answer these questions. Current status is that we're waiting for the results of their consultation to be recorded here before proceeding with this PR.

Although the ada Handle team contacted me, it was not for consultation but to request a review of this CIP. If they want to proceed with their request, they will need to provide more information.

[rphair]

apologies @perturbing when I used the word "consultation" I realise now that had the wrong implication... I was only trying to pass along that you'd bee in contact about this issue & am correcting my language above.

We're all looking forward to any time you can spare on this issue, and if @papag00se needs the CIP-0067 addition on the critical path for the Ada SubHandles project then perhaps he can also make some arrangements to provide the details requested in #504 (comment).

[rphair]

@papag00se according to a proposed update to CIP-0068 (#586) there is no longer a requirement to update the CIP-0067 table unless new token types are added. If you're still interested in such an update, a new CIP would be required covering the proposed addition and its token metadata completely.

From the current state of the discussion, and given there hasn't been a justification posted so far about why a new CIP-0067 registry entry would be needed either to implement your application or extend its data structure to other applications, my understanding is that this PR can now be dropped.

If that's not true... i.e. if your application depends on that registry entry, would you please ASAP:

• post here, so we know that you're still interested in pushing this forward;
• comment on CIP-0067, CIP-0068 | Add Clarification for Edits and Modification #586 about how you think your use case justifies a CIP-0067 registry entry, if you're not already or eventually prepared to submit a CIP with a complete definition of ADA SubHandle tokens with a complete spec for their metadata & versioning.

[papag00se]

Thank you everyone for taking the time to think through this. I believe that the CIP-67 process is more refined now. I also think that after these discussions we have come to the conclusion that ADA Handles Virtual SubHandles are a specific enough implementation that generalizing the schema into a new asset_name_label class may not be beneficial to anyone else.

We did brainstorm a way to define a "sub-asset" class where an owner of one token can associate many "sub-tokens" to that owner token. There may be something there that we could make work and it would be general enough for others to build upon. For example, for projects that would like to offer owner-controlled fractionalizing of their tokens.

But overall, I think we are ready to throw in the towel on creating a new asset class and just use one of the private labels from the 0-15 range.

[papag00se]

What is the process for closing these? Does the OP just hit the button, or is there a process?

[rphair]

@papag00se the ideal process is to do what you have just done: to summarise the issue for anyone who might come across this PR later. Sometimes editors will close a PR with no updates, but since you've submitted the conclusion I think it makes the most sense to close this yourself. 😇