3 ms·

`Build the integration with my game & a generic API` Seem to be missing a few steps here

IanCal 5y ago
Is it? The larger point was that that's the same either way so it comes out in the wash. But OK if you want to break it down more: * Have the user prove they own a specific account (https://walletconnect.com/ https://walletconnect.com/ I would guess would be a simple approach to this) * Make a REST API call to check if they own the item (edit - to clarify, the API already exists, you just need to do a single get request) * Set local flag in game to say "yes they own the item"? What more detail would you need?
- falcolas 5y ago
  > What more detail would you need? Implementing the weapon. Paying for that implementation. Concrete example: I buy an NFT for a sword in World of Warcraft. I want to take it with me to FFXIV. Now FFXIV has to implement the sword. Its looks, its behaviors, its power, in a completely separate engine and world. They - Square Enix - also probably have to pay Blizzard for the trademark and copyrights to the sword. Yet when I buy the sword that money goes to Blizzard, not Square. So... why would Square do it? Plus, implementing a "yes, person with email address N owns sword X" rest API is pretty straightforward. You could even implement public/private key signatures for authentication of the receipt. It just would be stored in someone's email inbox instead of the chain.
  - IanCal 5y ago
    > Implementing the weapon. Implementing an in game item? That's already part of your game, right? > Paying for that implementation. You can buy an NFT entirely on chain, that's surely not in doubt. > Plus, implementing a "yes, person with email address N owns sword X" rest API is pretty straightforward. You could even implement public/private key signatures for authentication of the receipt. It just would be stored in someone's email inbox instead of the chain. Yes, I totally could re-implement all of these things. I could handle payment info, get people to manage their own public/private keys using my own implementations and have them copy & paste it from an email (?). I'm not sure I follow the flow there where people copy keys from emails into my game and how duplication is stopped but it sounds like an awful flow. My point, as I tried to emphasise, is that I can get those things without building them. They already exist if I manage that part with an NFT. So the question has increasingly become (as the field matures) - why build it myself? Why not use existing, working infrastructure? > Concrete example: I buy an NFT for a sword in World of Warcraft. I want to take it with me to FFXIV. Now FFXIV has to implement the sword. Its looks, its behaviors, its power, in a completely separate engine and world. I've not said anything about sharing between games, and the complex part of that is identical whether it's with crypto or not. What the global shared database part solves is that either game can easily check, if this was something they wanted to do.
    - falcolas 5y ago
      > That's already part of your game, right? Nah, not for the usecase of moving items between games - one of the biggest features touted by NFT enthusiasts. But that aside... > get people to manage their own public/private keys For a receipt, the individual users don't need keys. For proof of ownership, that ship has already sailed off into the sea of fraud and pyramid schemes, and we don't expect to see it again. When people are trying to sell NFTs of artwork to the original artist (aka blackmail), you know it's jumped all the sharks. > They already exist if I manage that part with an NFT. Most of this already exists in a system regardless. Adding a rest endpoint on the top of a database entry is usually pretty trivial - especially for something as basic as "retrieve and display this row in the DB" - and "already exists" in the form of libraries. And by using a blockchain as a database, I'm actually adding a lot of complexity to my system. > Why not use existing, working infrastructure? One, the existing and working infrastructure already exists. All the elements of a purchasing stream are implemented as libraries. And it's not as if you can stop caring about how money flows, because there are laws that require you to do a lot of bookkeeping and pay taxes on that money (no matter the form the transaction initially took). Why not use a blockchain as a distributed DB? Because it's slower and more expensive. Because it provides no functionality you don't already want or need to have locally, especially when we're discussing a game. In other words, NFTs - from a company's point of view - provide the same benefits and detriments as a normal event-stream DB, but it's slower, more expensive, and it includes transactions from every other company using that blockchain. > What the global shared database part solves is that either game can easily check, if this was something they wanted to do. Why would the first party need to check an external database, when their game engines literally require them to implement it internally? Why would a second party check the external database when there are licensing issues that require them to talk to the first party in the first place?
      - IanCal 5y ago
        > Nah, not for the usecase of moving items between games - one of the biggest features touted by NFT enthusiasts. That's not what I've been talking about though. > For a receipt, the individual users don't need keys. For proof of ownership, that ship has already sailed off into the sea of fraud and pyramid schemes, and we don't expect to see it again. When people are trying to sell NFTs of artwork to the original artist (aka blackmail), you know it's jumped all the sharks. That wouldn't apply at all for an in game item. Do you understand that two NFTs pointing to the same url would still be entirely distinguishable? > One, the existing and working infrastructure already exists. All the elements of a purchasing stream are implemented as libraries. "There is a library" and "there is already running maintained infrastructure" is quite different. > And it's not as if you can stop caring about how money flows, because there are laws that require you to do a lot of bookkeeping and pay taxes on that money (no matter the form the transaction initially took). I would be involved in the initial sale, but no auctions/trades/secondary sales. > And by using a blockchain as a database, I'm actually adding a lot of complexity to my system. I've outlined the steps required and can't see what you think would add a lot of complexity. > Why would the first party need to check an external database, when their game engines literally require them to implement it internally? How are you managing trading items between users without some database external to either users machine - unless you're talking about an entire p2p db of ownership which sounds frankly even more complex. You're jumping into a use case I've not posited and then bringing up things which don't seem to make sense (art NFTs created by random people). I don't think this is very productive so I will just leave you with one thought: Imagine you were already using the blockchain for this, and that was normal for games to do so. Now someone tells you that you could actually use these other libraries, and maintain your own database, and stop users from selling/trading however they wish but only through you, and you could build your own site for trading instead. Would you say "Yes, that brings me the features I really need - I should change to this different architecture"?

Is it? The larger point was that that's the same either way so it comes out in the wash. But OK if you want to break it down more: * Have the user prove they own a specific account (https://walletconnect.com/ https://walletconnect.com/ I would guess would be a simple approach to this) * Make a REST API call to check if they own the item (edit - to clarify, the API already exists, you just need to do a single get request) * Set local flag in game to say "yes they own the item"? What more detail would you need?

falcolas 5y ago
> What more detail would you need? Implementing the weapon. Paying for that implementation. Concrete example: I buy an NFT for a sword in World of Warcraft. I want to take it with me to FFXIV. Now FFXIV has to implement the sword. Its looks, its behaviors, its power, in a completely separate engine and world. They - Square Enix - also probably have to pay Blizzard for the trademark and copyrights to the sword. Yet when I buy the sword that money goes to Blizzard, not Square. So... why would Square do it? Plus, implementing a "yes, person with email address N owns sword X" rest API is pretty straightforward. You could even implement public/private key signatures for authentication of the receipt. It just would be stored in someone's email inbox instead of the chain.
- IanCal 5y ago
  > Implementing the weapon. Implementing an in game item? That's already part of your game, right? > Paying for that implementation. You can buy an NFT entirely on chain, that's surely not in doubt. > Plus, implementing a "yes, person with email address N owns sword X" rest API is pretty straightforward. You could even implement public/private key signatures for authentication of the receipt. It just would be stored in someone's email inbox instead of the chain. Yes, I totally could re-implement all of these things. I could handle payment info, get people to manage their own public/private keys using my own implementations and have them copy & paste it from an email (?). I'm not sure I follow the flow there where people copy keys from emails into my game and how duplication is stopped but it sounds like an awful flow. My point, as I tried to emphasise, is that I can get those things without building them. They already exist if I manage that part with an NFT. So the question has increasingly become (as the field matures) - why build it myself? Why not use existing, working infrastructure? > Concrete example: I buy an NFT for a sword in World of Warcraft. I want to take it with me to FFXIV. Now FFXIV has to implement the sword. Its looks, its behaviors, its power, in a completely separate engine and world. I've not said anything about sharing between games, and the complex part of that is identical whether it's with crypto or not. What the global shared database part solves is that either game can easily check, if this was something they wanted to do.
  - falcolas 5y ago
    > That's already part of your game, right? Nah, not for the usecase of moving items between games - one of the biggest features touted by NFT enthusiasts. But that aside... > get people to manage their own public/private keys For a receipt, the individual users don't need keys. For proof of ownership, that ship has already sailed off into the sea of fraud and pyramid schemes, and we don't expect to see it again. When people are trying to sell NFTs of artwork to the original artist (aka blackmail), you know it's jumped all the sharks. > They already exist if I manage that part with an NFT. Most of this already exists in a system regardless. Adding a rest endpoint on the top of a database entry is usually pretty trivial - especially for something as basic as "retrieve and display this row in the DB" - and "already exists" in the form of libraries. And by using a blockchain as a database, I'm actually adding a lot of complexity to my system. > Why not use existing, working infrastructure? One, the existing and working infrastructure already exists. All the elements of a purchasing stream are implemented as libraries. And it's not as if you can stop caring about how money flows, because there are laws that require you to do a lot of bookkeeping and pay taxes on that money (no matter the form the transaction initially took). Why not use a blockchain as a distributed DB? Because it's slower and more expensive. Because it provides no functionality you don't already want or need to have locally, especially when we're discussing a game. In other words, NFTs - from a company's point of view - provide the same benefits and detriments as a normal event-stream DB, but it's slower, more expensive, and it includes transactions from every other company using that blockchain. > What the global shared database part solves is that either game can easily check, if this was something they wanted to do. Why would the first party need to check an external database, when their game engines literally require them to implement it internally? Why would a second party check the external database when there are licensing issues that require them to talk to the first party in the first place?
    - IanCal 5y ago
      > Nah, not for the usecase of moving items between games - one of the biggest features touted by NFT enthusiasts. That's not what I've been talking about though. > For a receipt, the individual users don't need keys. For proof of ownership, that ship has already sailed off into the sea of fraud and pyramid schemes, and we don't expect to see it again. When people are trying to sell NFTs of artwork to the original artist (aka blackmail), you know it's jumped all the sharks. That wouldn't apply at all for an in game item. Do you understand that two NFTs pointing to the same url would still be entirely distinguishable? > One, the existing and working infrastructure already exists. All the elements of a purchasing stream are implemented as libraries. "There is a library" and "there is already running maintained infrastructure" is quite different. > And it's not as if you can stop caring about how money flows, because there are laws that require you to do a lot of bookkeeping and pay taxes on that money (no matter the form the transaction initially took). I would be involved in the initial sale, but no auctions/trades/secondary sales. > And by using a blockchain as a database, I'm actually adding a lot of complexity to my system. I've outlined the steps required and can't see what you think would add a lot of complexity. > Why would the first party need to check an external database, when their game engines literally require them to implement it internally? How are you managing trading items between users without some database external to either users machine - unless you're talking about an entire p2p db of ownership which sounds frankly even more complex. You're jumping into a use case I've not posited and then bringing up things which don't seem to make sense (art NFTs created by random people). I don't think this is very productive so I will just leave you with one thought: Imagine you were already using the blockchain for this, and that was normal for games to do so. Now someone tells you that you could actually use these other libraries, and maintain your own database, and stop users from selling/trading however they wish but only through you, and you could build your own site for trading instead. Would you say "Yes, that brings me the features I really need - I should change to this different architecture"?