Closed TimDaub closed 2 years ago
We really need to allow publishers to use their own provider (hosted, rented, etc). There were a couple of challenges in the UI, but we had some drafts. This will be shipped in V4.
As for V3, all backend code already supports this, it's just a matter of integrating it into the market
This has been implemented in the V4 publish flow
very cool! Is there an interface definition what mandatory functions a provider must implement?
Essentially it needs to have all of these endpoints and send the responses in the same format
Currently, the Ocean Protocol mandates a specific-looking provider.
E.g., it only allows users to submit files and then upon payment, it gives the user access to this cached resource.
However, I have a very different idea of how a provider on the Ocean Protocol should look like. Instead of selling files, e.g. I'd like to sell access to a RESTful HTTPS API.
Additionally, I think it should also be considered that the market.oceanprotocol.com default provider may not always have the user's best interest at heart. A monopoly position could lead to it charging arbitrary fees for storing and caching files.
Hence, I believe it'd make sense to allow other providers to step in too and provide similar or even more advanced services. E.g. I could see that a RESTful HTTPS API provider would do really well on the OP marketplace right now.
Ofc, I could now fork all of the ocean marketplace and create a white-labeled version of it myself and under my domain. However, I'm not interested in forking and maintaining the marketplace. I also don't have the resources to sustain the development of a fork version.
Primarily, my idea is to be a better provider on the Ocean Marketplace. So here's what I'd need to build my own:
And then lastly, to make my provider part of the Ocean Marketplace, it'd also become necessary to let a user choose on the UI. But I think at first, an interface definition of what is expected from a provider is important.