As @yaruno gave a lightning EIP talk about this today, I am posting this to get feedback.
Was great to see you all, and hope to see you also in the ETHDenver Please leave feedback about the presentation and if our EIP and our project peaked your interested checkout atarca.eu . We’ll have ATARCA Seminar Week - ATARCA on next week online about how digital economies can be governed with anti-rival digital tokens such as sNFTs.
Nice idea. I was recently thinking about NFTs which are songs and can be duplicated/shared under some conditions and I think this interface it’s the perfect minimal thing you’d need.
Any special reason why you are restricting transfer on the implementation?
Also, I think you should increment the
_currentIndex on the
share function. It’s always nice to have tests included for the reference implementations.
Edit: I just saw this is already final
Short answer for restricting use of transfer method was that we wanted to create ‘soulbound’ shareable NFTs in our research project. I agree that tests would be great for refence implementations, though the official EIP/ERC document is a bit restrictive format to include tests.
But to add to that I really like @xinbenlv presentation at ETHDenver about the ERCRefs that should scratch this itch. I’ll try to get our projects reference implementation added to GitHub - ercref/ercref-contracts: ERC Reference Implementations .
I’m also adding here a blog post that I wrote a couple of months ago where I reflected our EIP journey. It contains some self-reflection and some advice and links to resources for prospective EIP authors. Maybe it’ll be helpful for someone who stumbles upon this discussion.
In case someone gets interested on the deeper reasoning side of the utility and development of shareable NFTs. Here’s our research paper on development of sNFT called Digital Protocols as Accounting and
Incentivization Mechanisms in AntiRival Systems - Developing a Shareable Non-Fungible Token (sNFT) .