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.
You must log in or # to comment.
It’s an interesting idea! I think there are many such applications for federation protocols.
A few thoughts/questions:
- Ideally you’ll need a stable identifier for each specific product. Most small online stores I use have product names riddled with typos, so a way to tackle that would be nice.
- What’s the data model? Would each store be an ActivityPub Actor? Like each one would have a username and publish inventory updates?
- Where do these updates go (maybe something akin to a Lemmy “community”)?
- If you’re just relying on stores’ self-reported stock levels, where’s the benefit of using a federated model? Could you just build an open source app that scrapes retailers’ websites and collates that information?
- Is the eventual goal that this competes with Amazon et al? I.e. it becomes an actual marketplace, perhaps with a “buy” and “sell” Action, and where vendors’ instances are effectively web stores?
A federated marketplace could be interesting but there are some fundamental issues that would need to be addressed.
If the vendor and vendee are on different instances how will payment be securely transmitted? What if there is a dispute, which instance Admin would have final say? Will the instance operator get a cut, if so how does that work? What’s stopping my competition from opening an instance to check my stock level? What if I want to buy multiple items that are on different instances, do I have to check out on each instance?
If you can iron out the kinks this idea could make a lot of sense as a DNM as there wouldn’t be a centralized server to shut down and being FOSS would allow for auditing of the marketplace which just isn’t possible currently.
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.
Crypto would not solve this problem (or any problem, really) better than a simple database would.
Isn’t crypto just a ledger database?
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.
