I’ve been thinking lately about the concept of the fediverse and repurposing it toward the goal of creating a free and open, decentralized, federated network of vendors that run instances or groups of vendors that run one instance together. These instances would broadcast inventory updates to each node that they federate with. It would start off niche and gain traction that way before branching out into other retail types.

Is this a feasible idea? Has any pulled this off? Wayfair, Amazon, Shopify, and Etsy are already suffering from enshittification. Someone needs to take the inventory out of the walled gardens and back into the customer’s hands. I shouldn’t have to rely on Google to find products I want. There are vendors that want to sell me stuff nearby…it’s just a problem of connecting the user to the content…and this seems like a no-brainer.


I’d love to have a discussion about this. I am seriously considering creating a rolling fork of Lemmy that would maintain parity but also add this functionality but I want to talk to experts and weigh the pros and cons before embarking on such an ambitious project.

edit: I also started a community ( https://infosec.pub/c/federated_inventory ) dedicated to the discussion of this idea. I’m trying to get vendors in a budding local industry to fund the creation of this system, which would branch out into all retail industries eventually along with the network effect.

  • dfyxA
    link
    fedilink
    arrow-up
    1
    arrow-down
    8
    ·
    11 months ago

    That kind of scenario is exactly what cryptocurrencies were originally designed for. Too bad that didn’t work out and now they are mostly used by scammers.

        • Carighan Maconar@lemmy.world
          link
          fedilink
          arrow-up
          6
          ·
          11 months ago

          It is a very inefficient database that in return has a potentially unlimited distribution. Importantly however, unlike normal distributed databases it does not gain any performance benefit from its distribution, only redundancy. There are implementations for “normal” databases of course that also only focus on redundancy, but in that case the database itself is already orders of magnitude faster than any distributed ledger like crypto currencies are.

          Since such a system would ultimately need a single or a finite number of known access points anyways (API access for the vendor software systems) any benefit from being freely distributable is immediately lost. Likewise, the fact that the data is “shared ownership” has no meaning in the actual world as legally such a concept is not recognized, and we’d just be looking at companies willingly openly sharing their data, which they could already do by simply providing public interfaces.

          In other words, just having a regular database is - as always - far more efficient and suffers 0 downsides in the particular use case. And it’s incredibly difficult to find any use case for crypto ledgers that have any benefits at all, nevermind actually meaningful ones.