[Proposal] Hama - Securely Monetise Web Services

OceanDAO Round 9
#1

Name of project - Hama : Securely Monetising Web Services

Proposal Wallet Address :

0x5b3d1710851c651ff8075a3aDe3eDFd23B557E75

Fund Requested

$17500

We are first time Grant receiver

The proposal in one sentence :

Hama allows service providers to monetise their web services using Ocean Protocol.

Which category best describes your project? Pick one or more.

Build / improve applications or integrations to Ocean.

Project Description :

Today most of web2 is dominated by web services (REST, SOAP, Graph etc.). It is a multi billion dollar market that is ready to be disrupted.

Hama aims to provide an efficient solution to these service providers to monetise and access control their services using Ocean Protocol.

What problem is your project solving?

Currently there are millions of endpoints in both web2 and web3 projects that are under-serviced and non-monetised. It is a multi billion dollar economy ready to be disrupted by an effective solution. One of the main pain points of these sector is data leakage and data privacy. API providers can’t trust middlewares who provide monetisation option with user data and their service api data.

Hama solves this problem using Ocean Protocol. Ocean Protocol provides tooling to create such a solution. Hama leverages privacy preserving tech Ocean provides to allow api providers monetise their endpoints without ever seeing data behind the endpoints. This is ground breaking disruption of web service industry.

Another problem Hama solves is expanding use cases on Ocean. Currently Ocean Protocol is known for use cases in data industry. Data industry is already a big sector but comes with a lot of red tape and bureaucracy. Web services are already dominant today and are mainstream industry and Hama can help bring Ocean Protocol to this industry thereby significantly improving chances of Ocean Protocol for mass adoption. Imagine is Amazon AWS web services could be monetised with Ocean, that could be the fuel for mass adoption.

What is the final product?

Final product will be a new Web3 Protocol + Web2 libraries built on Ocean. But for current grant proposal, check the scope in Deliverables

How does this project drive value to the Ocean ecosystem?

Already explained above in sections. Hama aims to bring a new use case to Ocean Protocol and help Ocean Protocol gain mainstream attention.

ROI Calculations

If we just take example of AWS based web services. Their annual revenue is in billions. Let’s just conservatively take $1M as example.

bang = 1M$
bucks = 17,500$

So ROI = bang / buck = 1,000,000 / 17,500 = 57
Proposer’s estimate of % chance of success = 60%

Actual ROI = 0.6 * 57 = 34.2

Project Deliverables

We will use this grant for working on following milestones -

  • Landing page + Branding + social channels
  • Fork and update Ocean Provider component
  • Create a proxy server to handle monetisation of API endpoints

Team

Shunya Nishikawa
github - https://github.com/nskwb

Kung Zheng
github - https://github.com/kzk00001

Alcor Network (prev. Hama) - Subscription Product
#2

I’m taking in the project voting via the oceanDAO R9 dashboard and without trying to front here, I just wanted to say that I find the 1.25M votes in favor quite excessively positive considering that:

  • the team isn’t known within the community (at least I don’t - Hi yall and welcome!)
  • since you’ve asked for the max amount of funding on your first try - I’m always skeptical of that.
  • it’s pretty much unclear what added value your forking of the Ocean provider would give. Where’s the positive ROI? What exactly do you want to build from a technical perspective?

Also: Isn’t the provider API currently a revenue stream of the Ocean Protocol itself? It’s the sole reason transaction fees can be collected. So how exactly would the Ocean protocol profit positively from this project forking the provider API?

I can see this proposal and idea flourish, but I suggest that voters practice more diligence and reserve huge “yes” votes for established projects. That’s all virtue signalling from my side for now :smiley:

#3

Hi Tim, nice to meet you. We respect your skepticism. And honestly overwhelmed by support of Ocean community. I think the positive votes for Hama might signal that the use case we are building on is favored by comminity.

  • it’s pretty much unclear what added value your forking of the Ocean provider would give. Where’s the positive ROI? What exactly do you want to build from a technical perspective?

Well, current Ocean Provider is a proxy that does access control on datasets. It even doesn’t support streaming datasets. So, to be honest for our use case of providing access control for endpoints its not very useful. Also, we dont want to stay dependent on Ocean core team to build out features for us when we start growing and add more features. Obviously, they are busy and have their own priorities and roadmap.

Also: Isn’t the provider API currently a revenue stream of the Ocean Protocol itself? It’s the sole reason transaction fees can be collected. So how exactly would the Ocean protocol profit positively from this project forking the provider API?

Not exactly. Ocean’s revenue comes from the entire tech stack, especially from datapools and data tokens. Provider is just a proxy server that moniters payments and does access control. Forking a provider doesn’t affect revenue for Ocean Protocol. In fact, we are trying to add another revenue stream to Ocean by unlocking a big new use case of monetising web service (which Ocean do not support yet.) And we think this is what the community sees and thats why a lot of “YES” votes.

Our new proxy will still be operating on Ocean Protocol - creating new data pools, minting datatokens and paying % cut of revenue to Ocean Protocol for api consumes. If this works well, it will bring in a lot of revenue and help with manistream adoption (Data and AI is being used by few big institutions, web servies is consumed by everyone).

I hope this helps. And hopefully you will support us too :slight_smile:

Onwards and Upwards
Team Hama

2 Likes
#4

This is a very ambitious goal, and as such it becomes difficult to see how it would develop with any clarity.
If Ocean does not offer Web services monetisation, what made you choose Ocean protocol to build on?
In good faith

#5

Thanks for your question @inKin. It is indeed very ambitious goal. Ocean doesn’t provide Web services monetisation because primary use case of Ocean seems to unlock data for AI and ML. But It can be used to unlock other use cases as well.

Ocean’s vision is forward looking with futuristic roots where users and companies are comfortable sharing datasets with each other and data is a common asset (currently it is a commodity). This will certainly happen (and that’s why we feel comfortable to integrate Ocean tech in our project because Ocean is here to stay). Use case we are trying to unlock is current and mainstream as of today. Products that could be build using Hama later on might include pay-per-use streaming services like youtube, spotify or subcription providers like stripe. Possibilities are many.

We hope it helps answer your question.

#6

PROGRESS UPDATE :point_down:

:white_check_mark: Landing page + Branding + social channels

https://alcor.network (yes we rebranded Hama to Alcor)

:white_check_mark: Fork and update Ocean Provider component

We forked Provider component of Ocean and made needed updates (forked and updated provider repo can be seen in screenshot below)

alcor-github
alcor-github1628Ă—904 80.5 KB

:white_check_mark: Create a proxy server to handle monetisation of API endpoints

We also created a new Proxy server that compliments the updated Provider component to define custom restrictions/access conditions. This component repo is in screenshot below - access-proxy

alcor-github
alcor-github1628Ă—904 80.5 KB

Alcor Network (prev. Hama) - Subscription Product
#7

@AlexN added updates above

1 Like