4 ms·

When I worked in a LARGE eCommerce company maybe 6 years ago, everything was driven by CSV files dropped in an FTP folder. There were a few exceptions where co

by swalsh 4y ago

When I worked in a LARGE eCommerce company maybe 6 years ago, everything was driven by CSV files dropped in an FTP folder. There were a few exceptions where companies had API's. Still even those were GET requests initiated by us, and we didn't want to overload them so it wasn't super up-to-date, but that was the norm. I tried to break out to do my own thing, and I realized those automated systems were only for the big guys. If you were small, you don't even get the privlidge of an inventory file. Vendors don't have time to deal with small guys, and it can be super difficult to get started. Playing with crypto, and NFT's, I realized this was what I wish was the norm. The indexers were close to real-time. The chain I was using (AVAX) had a finality of 4 seconds, and gas is cents. What i'm going to describe isn't a solution to a problem the big guys have. They had enough sway with their vendors to get good systems. But for small guys like me, open access to automated systems would have been a god send. My dream system would be something like this: Think of this happening in a subnet (an app specific blockchain that doesn't share space with other apps, so scale is not affected by other apps) 1. A Trusted supplier mints a NFT for each of their SKU's (yeah trust and crypto don't go together ideologically, that's a purity problem crypto needs to get over itself, sometimes trust is useful... if you try to build the whole thing trustless, it's not better than traditional systems). 2. These NFT's are listed in any NFT marketplace that cares to list them. (with subnet-to-subnet messaging, you don't need to duplicate the contracts... so shouldn't have major scale issue. This is a brand new feature, so i'm not super sure though.) 3. I as a small scale vendor list a sku on my normal site. I can take payment as normal, but then I can call the NFT's index to get real-time inventory (even though I have no preexisting relationship with the vendor) 4. I get an order, I buy the NFT off the marketplace, and burn the NFT. My customers details are provided in the NFT burn contract. An app specific precompile let's me transmit those details to the vendor without making it public on the block chain (with proof it received it correctly). 5. After the NFT is burned, an ERC20 token is dropped in my stores wallet. After I get enough of these, I can trade them in for a volme rebate. This let's the small vendors get access to effectively what is a volume discount. I suppose this could be a SaSS app, but there's a bunch of side benefits to crypto, such as defi, tooling etc. But mainly vendors can customize their own terms if they own the full contract chain.

ambicapter 4y ago
> yeah trust and crypto don't go together ideologically, that's a purity problem crypto needs to get over itself The first white papers I read about crypto emphasized the "trustless" part of it. It's a selling point. They exchanged human trust for computational trust, only now people are realizing the limits of computer trust (namely, anything that isn't digital isn't covered). What we're looking for now is a way to actually entangle digital assets with physical assets (hence the rise of NFTs, which purport to be a physical thing, or at least the closest thing to).
- PKop 4y ago
  You would always need a central authority to reconcile the state of the physical world with the digital ledger. At that point what is the blockchain for? Or, what does the network look like that "runs" the blockchain? Surely there isn't any mining or proof of work, because there's no internal token to produce this way; the value is all external. And you cant trust random people to create the token or to reconcile (lie) about the physical/digital correspondence. Entangling digital with physical seems to devolve to just a database with a trusted authority administering it. I don't see any other way.
  - swalsh 4y ago
    My design philosophy is to use the blockchain for the parts where it's a good solution, and to not use it for the parts where it's not. For physical products that means adding some trust into the system. For pure digital systems, that means identity, money, or owned objects etc. can go on-chain. Things that are just transient data can go in a traditional database.
- swalsh 4y ago
  > (namely, anything that isn't digital isn't covered) Yep! this was my realization when I first started thinking about the idea. You can't computationally trust the movement of physical stuff. Some amount of trust is going to slip in somewhere. It's better to insert the trustless transactions in the places where the relationship is purely digital. In my example above, you have a large vendor which you (as a retailer) trust has inventory to back up every NFT they minted, and you trust to ship relatively reliably. You can't avoid that trust (though you could build mechanisms to increase your trust like 3rd party audits or something). But the relationship with hundreds of small retailers could be built trustlessly. So it's more like strategic trust as opposed to pure trustlessness.

by swalsh 4y ago

ambicapter 4y ago

> yeah trust and crypto don't go together ideologically, that's a purity problem crypto needs to get over itself The first white papers I read about crypto emphasized the "trustless" part of it. It's a selling point. They exchanged human trust for computational trust, only now people are realizing the limits of computer trust (namely, anything that isn't digital isn't covered). What we're looking for now is a way to actually entangle digital assets with physical assets (hence the rise of NFTs, which purport to be a physical thing, or at least the closest thing to).

PKop 4y ago
You would always need a central authority to reconcile the state of the physical world with the digital ledger. At that point what is the blockchain for? Or, what does the network look like that "runs" the blockchain? Surely there isn't any mining or proof of work, because there's no internal token to produce this way; the value is all external. And you cant trust random people to create the token or to reconcile (lie) about the physical/digital correspondence. Entangling digital with physical seems to devolve to just a database with a trusted authority administering it. I don't see any other way.
- swalsh 4y ago
  My design philosophy is to use the blockchain for the parts where it's a good solution, and to not use it for the parts where it's not. For physical products that means adding some trust into the system. For pure digital systems, that means identity, money, or owned objects etc. can go on-chain. Things that are just transient data can go in a traditional database.
swalsh 4y ago
> (namely, anything that isn't digital isn't covered) Yep! this was my realization when I first started thinking about the idea. You can't computationally trust the movement of physical stuff. Some amount of trust is going to slip in somewhere. It's better to insert the trustless transactions in the places where the relationship is purely digital. In my example above, you have a large vendor which you (as a retailer) trust has inventory to back up every NFT they minted, and you trust to ship relatively reliably. You can't avoid that trust (though you could build mechanisms to increase your trust like 3rd party audits or something). But the relationship with hundreds of small retailers could be built trustlessly. So it's more like strategic trust as opposed to pure trustlessness.