[mckmk]

It seems like, whenever there is an issue with the representations of blockchain the answer is to ignore the blockchain. (Shoot, our smart contract was a little too limited for the service we want to offer “Hey everyone don’t use that NFT!”) Where as a traditional database the answer is to fix the database or code. I look at any process involving NFTs and have to wonder how they aren’t more easily and cheaply accomplished as digital records in a centralized database and have yet to see any examples where that is not the case. Concert tickets? Set aside the fact that minting an ETH NFT is probably the entire profit margin of a ticket seller, why not a REST API? Or a web interface? (FYI they already do this) If the people who are letting you into the show are the final say whether you get in – you’re already trusting them and they already have full authority. What are you gaining bringing blockchain into this?

[cableshaft]

There are ways to make upgradeable smart contracts but it wasn't really formalized until recently (there's now open contracts you can import into your projects to enable upgrades).

Additionally, a lot of the community are against upgradeable contracts because they theoretically can be upgraded to something totally different, and they prefer immutability, with all its potential warts. Some projects use upgradeable contracts and don't have to do what Premint did, and some people don't.

But regardless, if you're going to offer an organizational service that's not on the blockchain, then inherently, by definition, it can't be strictly enforced just by the presence of an NFT, because people aren't computers and their physical actions aren't guaranteed to happen by lines of code like a computer program can (at least not yet).

Tickets for a concert were a meatspace analogy, not me arguing to put all tickets on the blockchain. One difference, though, is the NFT 'ticket' can be proven for any organization that wants to incorporate it, without a prior agreement or API access created by the original organization. Like I know some NFT projects allow people who have NFTs from other specific projects in their wallets to have early access in their own projects, or grant access to private Discord rooms, or let them into events, etc. and it can be granted via software, without people checking or verifying anything.

Yes a REST API and a centralized database can provide that, but not if that organization goes defunct.

As an example from my own history, there's a game I worked on once that the company once debated on buying servers to host the multiplayer aspects of it, but eventually I just incorporated the general async turn based api of Apple's for the game. The company went defunct not even six months later. If we had gone the server route, the game would have been unplayable as soon as the company folded, but since we used the general protocol provided by the platform, the game was playable for many years afterwards (might still, I haven't checked in a while).

That's a very real (to me, anyway) benefit of building on a blockchain. As long as the blockchain platform is still up, those smart contracts can still be used, and its support doesn't have to be constantly justified by the parent company / count on the company not going out of business to keep running. Like Nintendo is getting rid of its Wii and 3DS shops here in a few months because they can't justify keeping it up. If the blockchain existed then and those things were stored on there (like files are stored on IPFS or Arweave for web3 today) they'd still be accessible without any continued expenses from Nintendo.

Right now I'm having to decide which of my digital games I need to make sure are downloaded and on my device before I lose the opportunity to redownload in a few months (technically I can hack the device and download stuff from torrents, but I'd rather not have to do that for a while, if ever).

Another benefit, to me, is similar and legacy related. Like my Facebook profile, website, games, journals, etc, when I die, all go away the instant that Facebook stops being a thing, and more importantly when I stop paying for web servers or cloud computing. My SO already made it pretty clear they're not really going to do anything to perpetuate them, so if I want those things to exist and be available I'll need to find something that can withstand not actively paying AWS, Azure, DigitalOcean, etc. to keep it going. Putting these things onto the blockchain would allow for that, and at the very least will outlive anything put onto cloud services, and possibly even the current crop of social media websites (definitely a few of them, maybe not all of them).

Some things I worked on are probably also circulating in some torrents of Flash games or console games also, but a lot of it isn't. And I have some physical copies of things I've worked on also (a lot of board game prototypes, some journals, etc), but I have a feeling a lot of that is just getting thrown away not too long after I die unless I something of mine becomes a big hit, maybe not even then.

You might not personally care about these things, but other people do. Or at least will once the infrastructure and supporting software is built out more.

[mckmk]

Thank you cableshaft. I appreciate you taking the time to share your thoughts.

FWIW I also think general protocols on long lived platforms and IPFS are great.

BUT, I really don't think the blockchain has a role to play solving any of the issues you laid out. The reason the game you mentioned was able to continued to be played was because Apple was providing the network. The minimum ETH write fee is almost always at least $1 and frequently cost $3.50. Would people still be interested in playing the game if each write cost that much? Same goes for your archiving plans. IPFS is great but it's not a guarantee that that data will be seeded forever. For that you'd need to write it to one of the chains you're confident will survive. ETH data costs somewhere in the thousands of dollars per MB range? I'm not sure it's a real solution to that. I'm not dismissing the issues of very long term code and data longevity. They are real issues but in my opinion still quite unsolved.