search

waku-org / research

Waku Protocol Research
MIT License
3 stars 0 forks source link

Make senders pay for non-ephemeral messages #32

Open s-tikhomirov opened 9 months ago

s-tikhomirov commented 9 months ago

In Store incentivization, servers are supposed to store all non-ephemeral messages forever. Even if we implement payments for every request, there still a mismatch between who causes costs (the sender) vs who pays for it later (the requester).

Shall the sender of a non-ephemeral message (partially?) pay for its future storage? Or, at least, should sending a non-ephemeral message be more expensive than sending an ephemeral one? After all, we probably want to discourage non-ephemeral messages where ephemeral ones suffice.

alrevuelta commented 8 months ago

Shall the sender of a non-ephemeral message (partially?) pay for its future storage?

Good point. The main problem with making the sender of a non-ephemeral message pay, is that it goes into "decentralized storage" territory (aka ipfs, filecoin, codex, etc) and its not very clear if its waku's job to solve that. One of the main problem here is to prove that you are storing that data, and to who, and that's for sure out of scope of waku by now. So we may consider this option, but using some "off the shelf" solution such as codex or filecoin.

Or, at least, should sending a non-ephemeral message be more expensive than sending an ephemeral one?

In the short term I see this more viable. Eg if we allow 1000 msg/day then a store message could count as 2.

fryorcraken commented 8 months ago

Some thoughts on the matter.

The reason of Waku store is to cater for resource-restricted devices that are (mostly) offline and cannot participate to relay to access past messages. It is assumed that the share of store client nodes, ie, nodes without permanent internet access, is high enough that Waku store is the best solution for the problem (and not, let's say, rebroadcasting on demand for a minor share of non-relay nodes).

Hence, it is assumed that the functional benefit of Waku Store is for these end-users that have offline devices, which is why the proposed approach would be for "retrieving" users to pay for this service (or at least, for the act of retrieving being the incentivized action).

Which introduces this possible discrepancy between the incentivized action (retrieved message) and the actual cost of the action (assumed disk space costs more than upload bandwidth).

In terms of ROI, assuming that retrieval is the selected incentivization mechanism, it means that an operator may want to store messages that are likely to be most queried. E.g., whether related to a popular app or popular content topic. ML could even be applied to let a node learn what messages are most likely to be retrieved based on their content topic, metadata, timestamp, rln proof, payload size. This in itself, could potentially be an issue for content topic with less users. Do note that for privacy reasons, we encourage usage of "buckets" for content topic to get some k-anonymity when using light client (e.g., do not use a public key in content topic, instead Status protocol uses 4 first bytes of hash of public key in content topic) Yet, this does not solve the issue for brand new app with less users.

In terms of business model, I see 4 possibilities:

  1. A user wholesomely pays for the usage of Waku by a group of people (e.g. Status Community owners pays for the community, or dapp dev pay for infra).
  2. A user contributes to the usage of Waku by a group of people (e.g. Status Community member contributes to cost of running community).
  3. A user only pays for their own usage (e.g. user pays for his 1:1 messages retrieval).
  4. User runs infra and "nobody" pays for infra (e.g. users enable stores in their Status Desktop instance).

For (1) and (2), a model where the users pay for storage makes sense. e.g., Alice pays for the network/an operator to store messages on the content topic of her community, versus Alice pays for the network/an operator to let users retrieve messages on the content topic of her community.

One risk in relying on a decentralized storage system for this model is that, AFAIK, there is no decentralized storage system that caters for web apps. All systems I know either do not cater for web apps at all or only provide centralized gateways as a solution for web app. The only solution I found so far is webtorrent, that enables web app participation to the torrent network using webrtc. This could be one solution as Codex aims to be a protocol that can give durability to existing storage systems such as BitTorrent.

I agree with @alrevuelta's proposal above that one way to incentivized dapp developer to only use store when necessary would be to make RLN heavier for store messages.