Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: local non-fungible use cases #259

Closed
chungquantin opened this issue Sep 3, 2024 · 5 comments
Closed

feat: local non-fungible use cases #259

chungquantin opened this issue Sep 3, 2024 · 5 comments
Assignees
Labels
api Pop API pallet question Further information is requested

Comments

@chungquantin
Copy link
Collaborator

chungquantin commented Sep 3, 2024

Implement the non-fungible feature to pop-api to support interact with non-fungible tokens.

Basic Specification

PSP34Mintable Interface

WRITE API METHODS

/// Create a new non-fungible token to the collection.
mint(collection: CollectionId, item: ItemId, to: AccountId);

Important

Contract mints the collection item to the designated account

PSP34Burnable Interface

WRITE API METHODS

/// Destroy a new non-fungible token to the collection
burn(collection: CollectionId, item: ItemId);

Important

Only the owner of the collection item has the authority to destroy it

PSP34 Interface

Because PSP34 is a standard for a non-fungible token. We need to adjust it a bit to support collectable use cases:

READ API METHODS

// Returns the owner of a collection.
collection_owner(collection: CollectionId)Option<AccountId>;
// Returns the owner of an item.
owner_of(collection: CollectionId, item: ItemId)Option<AccountId>;
// Returns the total number of items in the collection owned by the account
balance_of(collection_id: CollectionId, owner: AccountId)u32;
// Whether an operator is allowed to transfer an item or items from owner.
allowance(owner: AccountId, operator: AccountId, id: Option)bool;
// Returns the details of an item.
item(collection: CollectionId, item: ItemId) -> Option<ItemDetail>;
// Returns the details of a collection.
collection(collection: CollectionId) -> Option<CollectionDetail>;
// Returns the total number of items in the collection
total_supply(collection: CollectionId)Balance;

Warning

Got a blocker because there is no method supported in the pallet-nfts to retrieve the approvals information of an item. One way is to fork the ItemDetail struct and encode on our own to retrieve the field approvals (this field is private in the pallet-nfts)

WRITE API METHODS

/// Delegate a permission to perform actions on the collection item to an account.
approve(collection: CollectionId, item: ItemId, spender: AccountId) -> Result;
/// Transfer a token from one account to the another account.
transfer(to: AccountId, collection: CollectionId, item: ItemId) -> Result;
/// Cancel one of the transfer approvals for a specific item.
cancel_approval(collection: CollectionId, item: ItemId, spender: AccountId) -> Result;

PSP34Metadata Interface

WRITE API METHODS

// Set the attribute of collection item with `value` for the given key `key`
set_attribute(collection: CollectionId, item: ItemId, key: [u8], value: [u8]) -> Result;

READ API METHODS

// Returns the attribute of collection item for the given `key`.
get_attribute(collection: CollectionId, item: ItemId, key: [u8])Option<[u8]>;

PSP34Enumerable

READ API METHODS

// Returns a token `Id` owned by `owner` at a given `index` of its token list.
owners_token_by_index(owner: AccountId, index: u128)Option;
// Returns a token `Id` at a given `index` of all the tokens stored by the contract.
token_by_index(index: u128) -> Option;

Extensions

[Proposed] PSP34Admin

WRITE API METHODS

// Issue a new collection of non-fungible items from a public origin.
create(admin: AccountId, config: CollectionConfig) -> Result;
// Destroy a collection of fungible items.
destroy(collection: T::CollectionId) -> Result;

Important

Remove the witness data parameter and handle the witness date in the pallet logic instead.

[Proposed] PSP34Swappable

TBA

[Proposed] PSP34Ownanle

WRITE API METHODS

/// Transfer the ownership of the collection to the new owner. 
transfer_ownership(collection: CollectionId, spender: AccountId, owner: AccountId) -> Result;
@chungquantin chungquantin added question Further information is requested api Pop API pallet labels Sep 3, 2024
@chungquantin chungquantin self-assigned this Sep 3, 2024
@chungquantin chungquantin linked a pull request Sep 3, 2024 that will close this issue
12 tasks
@chungquantin
Copy link
Collaborator Author

My concerns for this specification is should we support collection (introduce in the trait crate non_fungible_v2)? IMO, we should because it has become the standard of the NFT space. PSP34 interface is a bit out-dated right now and it does not have the supported standard on the ink! side for the NFT collection manager contract.

If we agree to support collection creation / item management, we will need to make some adjustments to the specification of the PSP34. For collection item, we can follow PSP34, for collection we will come up with our own PSP34Collectable spec.

cc: @Daanvdplas @peterwht

@peterwht
Copy link
Collaborator

peterwht commented Sep 4, 2024

Please use the PSP34 spec from here: https://github.com/inkdevhub/standards/tree/master/PSPs (slightly more up-to-date)

@peterwht
Copy link
Collaborator

peterwht commented Sep 4, 2024

Here is also a good reference implementation: https://github.com/Cardinal-Cryptography/PSP34

(note, it is on ink! v4.3.0, so there are some improvements with ink! v5)

@peterwht
Copy link
Collaborator

peterwht commented Sep 4, 2024

I would remove the ERC-721 milestone for now. It can remain in the spec if you want, but I don't think we should prioritize its implementation.

We should have a base PSP34 that matches the PSP standard exactly. No extra functions (dispatch or read).

And then, the remaining functionality listed in Permissionless / Permissioned dispatchables should be an extension. For example, a PSP34Swappable, and PSP34Manager (for admin stuff), etc. etc.

@peterwht
Copy link
Collaborator

peterwht commented Sep 4, 2024

My concerns for this specification is should we support collection (introduce in the trait crate non_fungible_v2)? IMO, we should because it has become the standard of the NFT space. PSP34 interface is a bit out-dated right now and it does not have the supported standard on the ink! side for the NFT collection manager contract.

If we agree to support collection creation / item management, we will need to make some adjustments to the specification of the PSP34. For collection item, we can follow PSP34, for collection we will come up with our own PSP34Collectable spec.

cc: @Daanvdplas @peterwht

Yes, we should definitely support this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Pop API pallet question Further information is requested
Projects
None yet
2 participants