You are viewing a single comment's thread from:
RE: SIP001 - Non Fungible Tokens in STEEM
My understanding is:
- we'll not be able to "see" these tokens in our Steem wallets.
Ok, maybe you'll design your own client for that purpose, but:
Number 2 - we'll not be able to trade these tokens on internal Steem market.
Ok, maybe you'll create the own market too. But doesn't it look like too much fuss ?
No, that's the other way around. This proposal is to implement these features natively, which means these tokens will be visible natively on the blockchain and all user interfaces, and you will be able to trade them against native currencies (STEEM and SBD), and even SMTs.
But that's something you can't accomplish without Steemit inc ?
It would be great if they did, but it's not 100% necessary. It would be possible to build this as a "community plugin" for Steem blockchain.
Witnesses ultimately control what software gets deployed.
But at least the site steemit.com is 100% property of Steemit inc afaik, so you can't force them to cooperate considering what steemit.com visitors will be able to see. Right now there's quite a few blockchain functions not supported by steemit.com ( like acc creation, convertion and so on ) and there's no reason to expect this attitude to change in future.
True, but steemit.com is not the only interface to Steem blockchain, there are great options out there - steempeak, steeve, busy
True, and from none of that you can expect any cooperation for granted. That's why first thing I mentioned that you probably have to consider launching your own client prior to any other plans.
Why does it have to be native? Wouldn't it be much easier to do it on top using custom_json transactions?
It can be non-concensus up to a certain level, there's a few things which are better done natively as it has a much better user experience and less chance for errors.
In the example of steemmonsters, when a users A and B both simultaneously buy a card from user C, only one of them will receive the card, but both will pay.
This can be avoided by either locking the card for a certain time before allowing a purchase, or by implementing the marketplace and token tracking natively, which would not require any locking.
I don't think your specification involves any purchases using Steem -- that is where soft-consensus falls short, when transfers with Steem must be incorporated into the DApp (I do have a solution, though, but it is quite complex and involves pegging a token running using soft-consensus to STEEM). Anything other than incorporating STEEM transfers, though, can be done using soft-consensus.
But is there any part of your specification that actually requires native consensus? I haven't read through it all, so sorry if I am missing something.