Re:Welcome to Web 3.0
by IanCal on Tuesday March 15, 2022 @10:11AM
(#30685519)
> What makes you believe there won't be regulations on trading NFTs in the future?
Even more reason for me to not want to be involved in the actual trading part.
> There is nothing in NFTs that protect companies using it to be above regulations.
Sure! The crypto-bros are wrong that there aren't/can't be regulations on these things, as are those complaining it's an unregulated area.
> I don't know, I don't work on the space. Leveraging from my 20 years of career I'd say that it's never trivial to integrate with a 3rd party for any kind of complex business logic.
This isn't complex business logic, that's my point. There's _already_ a standardised API. As I've said, there are annoying differences, but they are for more complex use cases and "read public data" is about the simplest there is.
To break it down a bit more, you utilise two key things. One is the standard API that all nodes have (https://ethereum.org/en/developers/docs/apis/json-rpc/) which acts the same for the use case here. There are public ones, you can pay a company to run one and you can if you want run one yourself. The end user can be free to swap between any of these.
The interface there isn't so nice, as you can ask for data stored somewhere, but finding exactly what address to read isn't that nice. Helpfully it's extremely generic so you can use a library to help with that step. You would do something like this in python:
Here my_abi is something I control (it's my contract), the contract address is known after you publish it.
That's it. You're pulling from a shared database.
I hope that helps explain it a bit more - the API/backend stuff is generic and doesn't have to be run by you. However the only real external piece here is the storage layer - you're still in control of the data structure & functions (you write the contract). You're not relying on a third party to manage a "game item" API and hoping they don't change it, if you use a third party here it's about paying someone to run an open source project for you on their hardware.
Even more reason for me to not want to be involved in the actual trading part.
> There is nothing in NFTs that protect companies using it to be above regulations.
Sure! The crypto-bros are wrong that there aren't/can't be regulations on these things, as are those complaining it's an unregulated area.
> I don't know, I don't work on the space. Leveraging from my 20 years of career I'd say that it's never trivial to integrate with a 3rd party for any kind of complex business logic.
This isn't complex business logic, that's my point. There's _already_ a standardised API. As I've said, there are annoying differences, but they are for more complex use cases and "read public data" is about the simplest there is.
To break it down a bit more, you utilise two key things. One is the standard API that all nodes have (https://ethereum.org/en/developers/docs/apis/json-rpc/) which acts the same for the use case here. There are public ones, you can pay a company to run one and you can if you want run one yourself. The end user can be free to swap between any of these.
The interface there isn't so nice, as you can ask for data stored somewhere, but finding exactly what address to read isn't that nice. Helpfully it's extremely generic so you can use a library to help with that step. You would do something like this in python:
Here my_abi is something I control (it's my contract), the contract address is known after you publish it.That's it. You're pulling from a shared database.
I hope that helps explain it a bit more - the API/backend stuff is generic and doesn't have to be run by you. However the only real external piece here is the storage layer - you're still in control of the data structure & functions (you write the contract). You're not relying on a third party to manage a "game item" API and hoping they don't change it, if you use a third party here it's about paying someone to run an open source project for you on their hardware.