You are viewing a single comment's thread from:
RE: RocksDB and SMTs Announcement
Thanks for the update!
It would be great if you and the dev team would consider adding native support for NFTs based on the SIP001 spec here, right after the work on basic tokens is complete:
https://github.com/thesweatshop/tokenforge/blob/master/SIP/SIP001.md
Edit: please see my reply to smooth deeper in this thread for short overview
Hi @upheaver - I just wanted to say thank you for contributing to STEEM ecosystem, I think it's very impressive that you just voluntarily devote probably tons of your time to open this platform to new possibilities. !tip 100 hide
Thank you, highly appreciated
NFTs are accomplished in SMTs by issuing SMT-lite of 1(one) token and 0(zero) divisibility. What are the differences in the approaches? Thanks.
My proposal allows for storing of custom json metadata inside each individual token by 3 different parties: the token issuer, the current owner and the dapp interacting with the token.
The specification document contains a walk-through example
Thanks. I'm fairly sure we'll achieve the goals (e.g. Support Steem Monsters Card Issuance) supported by those reqs with SMT-lite. If I'm incorrect, let us know where.
Using SMTs for NFT functionality would be a hack - while it might cover the very basics, the native enhancements I proposed would provide new capabilities and in turn enable new kinds of businesses/ecosystems to emerge.
What is functionally different besides the name? If there are missing features, particularly small ones like json fields, now is the time to hash that out with the developers and get them incorporated.
It's explained better when reading the spec, in short there are a few things:
This enables powerful new ways to build apps.
For example you could send your steemmonster cards to a real time strategy game dapp built by a 3rd party, play with them,earn custom points, and then convert those points to native experience points by steemmonsters - all data logged nativelly inside the token
Yes I understand your spec does things in a different way. Since you worked on your own to design something, and there are always different ways to get to the same goal line, it will clearly be different in terms of details such as the names of the APIs.
What I'm trying to drill down to are the core functional differences that can bridge the gap because I think there is near zero probability that the Steemit devs are going to implement your spec, but actually decent probability they might be convinced to make some small functional changes to enable the same or similar use cases.
For example, having data storage areas seems like something might be possible to go into even simple SMTs. If it goes in, many of the uses cases you have in mind will be enabled, if not using the same APIs that you specified, etc. If not then those use cases won't be able to use SMTs (or certainly not as easily)
You are absolutely right, that's why I'm trying to convince @ned to shedule a review with his dev team to see if there are points of overlap that need to be considered now between SMTs and this proposal.
The other option is to build this as a community plugin.
Are you on discord? Just curious
Thank you for your explanation here. I didn't quite get the benefit when I read your post and glanced over the documentation.
Good job @ned . I really like it, how fast you react and how you start communicate with the community!
Ned I love the work you are doing and especially that you are listening to the community. That allows everyone to advance.