Open standards, sort of. People could in theory take a game license they bought through some other service supporting NFT game licenses, and move it to Steam, or vice-versa. Steam et al would essentially be crypto wallets that let you download+play the games corresponding to the licenses they held. (Better yet if they’re non-custodial, actually. Decouple the responsibilities of originating licenses [i.e. buying games] from fulfilling game installs given licenses.)
Also, presuming Steam was coerced by industry/government pressure into supporting NFTs, it would also mean that you could resell the games even if Valve didn’t want to support that. As long as the game-license NFT was a regular ERC722 token, its owner would always be able to move it around—such as to someone else in exchange for payment.
OK, so when the game starts up it needs to see some proof that you own a license for it. So it needs to see proof that you own an NFT.
I am not aware of the technical details of various NFTs but I'm going to assume that you prove ownership similarly to how it can be done in Bitcoin--signing a transaction/message with a private key that corresponds to the public key of the asset in question. I would be happy to learn of some other way to do this!
An issue here is that this does not prove unique ownership. I could share the private key with other people, and everyone could play the game at the same time. Admittedly, these would have to be trustworthy people since I imagine that the holder of the private key would be able to transfer ownership. Maybe you could sign a bunch of messages ahead of time and distribute those to your friends? That could be averted by having the game require a random number and/or datecode to be part of the message.
Maybe the game can require a transaction to be posted on the NFT chain saying that you have started playing the game at x time, and eventually a corresponding stopped-playing message. So it would not let you play if it sees that a previous session hasn't been closed? Is your play time now publicly logged?
It isn't intuitive to me (as someone with solid familiarity only with how Bitcoin works) how this could work. I would love to see a more technical analysis.
You prove you own the NFT the same way you prove to your bank that you have money: by letting the bank hold it for you. You deposit or lock the NFT into the service (essentially making it a staking contract). This associates the NFT with an account within the service's smart-contract (of the depositor's choice), which can then be mirrored by an oracle-process observing on the service's backend to become "a record in Valve's database." You then log into Steam as normal.
The difference from "just using Steam" is that, at any time, you can tell the Steam NFT-staking-contract to unlock your NFT and give it back to you. Their oracle will observe this and erase the equivalent "record in Valve's database." (Note how the order of operations flows smart-contract → database in both cases. This isn't an arcade machine, where you have to convince the machine you put your token into to spit it out before you can exchange it back for cash. Effectively, you're asking for your money back at the exchange counter, and it's the arcade's responsibility to then — asynchronously — extract your token from the machine.)
It's easier to make analogies if you don't think about non-fungible tokens (which don't have many real-world analogies besides deeds, and people aren't very familiar with the mechanics of deeds), but rather just with tokens generally.
Say you're at a grocery store. How do you reserve a shopping cart? You insert a token that you own into a slot on the cart, which unlocks the cart from the cart next to it in line. The cart then acts as a staking contract for that token. While it's holding the token, it unlocks permissions for you to do something with the cart itself — wheel it around the store. The cart doesn't need to exist within the same abstract financial system that the token exists in, but merely needs to have some mechanism sticking up into that system — a coin slot — which can observe a token being locked in, and then report that event to a physical backend.
Where the analogy breaks down, is that you have to take your cart back to the chained-up carts in order to get your token out. In equivalent staking-contract scenario, you'd instead withdraw the token, and that would cause the cart to return to being chained up to the rest of the carts. A→B lock, A→B unlock; rather than A→B lock, B→A unlock.
Also, with a physical shopping cart, it's merely social norms and a common-sense observation of the mechanism that suggest that a shopping cart won't "eat" your locked token (i.e. not give it back when you fulfill the unlock condition.) Smart-contracts, meanwhile, can constrain themselves by the interfaces they implement; and can be static-analyzed for their theoretically-possible range of behavior, with the results published by reliable third-parties. So you can actually guarantee whether Steam's smart-contract has any internal capability to "eat" your deposited token or not, without anyone ever having to learn that the hard way.
Thanks, pretty good explanation of a way for it to work.
I don't see what advantage this implementation offers though (happy to be wrong). The game is checking with Valve to see if I am allowed to play it. I will need Valve to agree to honor my token and talk to the game appropriately in perpetuity. A third party that I sell the token to would also be relying on Valve to honor the validity of the token after I transfer it to them. This has very similar characteristics as if Valve build out tools to sell/trade games using their existing database. Valve can decide any day to stop honoring tokens, maybe "locking" currently deposited tokens to your account by making the database record permanent and not caring about tokens any more.
Maybe the game has a facility to check with other services that also implement the staking contract, as sort of a backup in case Valve dies or as an attempt to be vendor agnostic? I think that has some interesting difficulties too.
The idea would be that you could transfer your license NFT away from Steam to, say, Origin; and then the Origin release of the game would be checking with Origin’s servers instead of Valve’s. You’d delete your Steam copy of the game (which would no longer work) and install the Origin copy (which would now work.)
Yes, each individual release of the game checks with some particular private corporate server, rather than checking the NFT’s status directly (because, as you said, a PKI keypair is non-unique, and so cannot[1] be used to enforce max-concurrent usage.) And at any given time, you only have a right to play one individual release of the game (or zero, if your NFT isn’t staked anywhere.) But, by moving the NFT around, you can always exchange [a license to play] release X of the game, for [a license to play] release Y of the game. That’s the “freedom of movement” that NFTs get you.
Steam→Origin isn’t a very interesting example of this, since both releases of the game are likely nearly byte-for-byte identical. Consider instead moving a license NFT you possess for an abstract widely-released game title between Steam and, say, the PS4, or the Switch. These aren’t just different “releases”, they’re different ports, perhaps of differing quality—but they may be legally considered to be the same abstract “game title.” (The license NFT would probably correspond to the same abstract copyrightable work for which the ports are all derivative works.)
Even better, this would allow you to detach a license NFT from a “dead” platform (the Wii U, say), and move it to a living platform (e.g. the Switch) where the game has been re-released. Then I wouldn’t have to ever buy NSMBU again[2]. These platform companies’ business models would never allow implementing that on their own... unless a court of law forced them to do it. And there are no real obstacles stopping interested parties from lobbying for exactly such a law!
[1] Although PKI keypairs can be made unique, by generating the privkey on a TPM it can’t be read out from, such as a smart card. Games in e.g. South Korea already rely on smart-card based license activation (although IMHO this only works because of the culture — people in SK mostly play games in net cafes rather than at home, so people don’t generally need to own smart-card readers.) It would very much be possible to make the same smart-card your custodial wallet for your NFTs, and your proof-of-possession for the game to challenge-response against. Then you wouldn’t need a corporate license server — at least in the case of that release of the game. Probably you’d still want to enable interoperation with ecosystems they did use license servers, e.g. the game console ecosystems.
[2] Speaking of Wii U → Switch re-releases: I think Nintendo specifically has foreseen something like this coming, and is trying to get out ahead of it, which is why all their re-releases lately have been enhanced in arguably nontrivial ways — usually by bundling them together with something entirely different — such that they have supporting evidence to claim the re-released game is materially different from the previous version, over-and-above just being a technological upgrade. Even if you have a license NFT for Mario 3D World, that doesn’t necessarily attach to a game-download for Mario 3D World + Bowser’s Fury, y’know? It’s sort of like the stores that get their own model of a product made to trivialize “we’ll beat competitors’ prices” guarantees.
=====
> maybe "locking" currently deposited tokens to your account by making the database record permanent and not caring about tokens any more.
Like I said above, this can be made impossible. Smart contracts are, by default, immutable: their logic can’t be changed once deployed, even by their original author. (The contract author needs to introduce explicit support for upgrading the contract in the contract’s logic before deploying it to the chain.) And this game-theoretic situation is pretty much exactly why smart contracts are immutable: it prevents selfish companies from later reneging on their contractual obligations.
Presuming Valve implements their staking contract as immutable—and probably nobody would trust them with their NFTs if they did any different, just like nobody would trust a non-CDIC-insured bank—then Valve would never be able to later “opt out” of people transferring their tokens away. The contract is what it is. (This is why I was highlighting the importance of an “A→B lock, A→B unlock” flow. Valve can always make their server refuse a withdrawal; but they can’t make an immutable contract refuse a withdrawal, if it didn’t have logic for that in place from the beginning. As long as the contract was programmed to be “in charge” of the withdrawal flow, with the server being a mirror of its state, Valve has no mechanism by which to stop your withdrawal from being processed.)
So if they ever wanted to quit supporting NFTs, they’d be able to either make permanent or purge their own database-record equivalent representation of the NFTs; but even if they made their own records permanent, they wouldn’t be able to erase the tokenized representation, nor stop users from transferring the tokenized representation away. And those tokens would still represent a right to a license for the game, to the other game-download-service-providers in the market. So all they’d be doing by “opting out” would be, at most, giving everyone a free second permanent non-transferable license to their games, separate from the transferable license.
Thank you for putting in so much time to respond. I think this does make sense and does have a useful purpose, particularly in providing cross-vendor usefulness of purchases.
Of course now that I go back and read one of your earlier comments, this is exactly what you were saying all along:
> People could in theory take a game license they bought through some other service supporting NFT game licenses, and move it to Steam, or vice-versa.
