Network incentivisation
===

In order to make sure we are not tight to a specific transport (currently whisper), different models of operations will be explored:

1) Whisper
2) Loopix

If not specified it applies to all.

The main differences and properties are:

#### Whisper

- Sender anonimity
- Receiver anonimity
- Messages are flooded on the network
- All nodes can have the same functions (relay + mailserver)

#### Loopix

- Sender anonimity
- Receiver is anonymous to mix nodes, but not to providers (trusted nodes)
- Messages follow a path in the network
- 2 kind of nodes, mix nodes (relay only), providers (entry/exit points)
- Trusted/long term relationship with providers

### Options

We have a few options, some of them can be used in conjunction (i.e Donations can be always
built on top of other methods).

- Pay to send & receive (i.e https://discuss.status.im/t/prbs-protocol-proposal-an-incentivized-whisper-like-protocol-for-status/849/14 )
- Pay for offline messaging, providing online messaging for free (i.e freemium)
- Contribute with resources (i.e bandwith/storage torrent)
- Ads model (i.e pay with attention/data)
- Donations (i.e wikipedia)

## Open questions

Removing status-run nodes on the network has certain implications, which are common
to some/all the methods listed above, so some questions needs answering:

[Oskar: I think having a list of bootstrap nodes is OK, especially if we only have few of these, and people can modify this. Similar to how BT works ~. Though you wouldn't get as 'decentralized'/coordination-less as, say, SSB.]

- How to make forwarding nodes discoverable?

-- [Oskar: could you elaborate?]
-- [Andrea: Forwarding nodes membership is dynamic and possibly a user will have to pay, if the user is to select a forwarding node (or even if it is selected automatically), how can we have a discoverable list of nodes (with potentially pricing information)?]

- How to make offline message nodes discoverable?
-- [Oskar: do you mean 'knowing if there are new messages to be fetched?' or the nodes themselves?]
-- [Andrea: Offline messaging nodes membership is dynamic and possibly a user will have to pay, if the user is to select an offline messaging node (or even if it is selected automatically), how can we have a discoverable list of nodes (with potentially pricing information)?]
- How do we know a offline messages node has been online/has the messages for the time we are interested in?

-- [Oskar: IMO this is solved if you have a data sync layer, as you know parent message id and can detect if messages are missing]
-- [Andrea: Not really, certainly it might help, but simple case: you go online after being offline for a while, you want to catch up on chat x, you ask mailserver/peer for data in group x, they have not the most recent data. Your parentID will be from a while ago, and you won't be able to know that there's more recent data. Also looking at briar parentID is an optional field, and only used for replies.]
-- [Oskar: Right, I was imagining that's an "honest" intermittent connection, i.e. that node simply happens to be less useful. In reality I imagine you'd have multiple nodes, and if someone offers newer with more proven parent ids, then that'd be de facto more useful and act as proof itself that it has more 'uptime' (=useful new info). ]
- How do we guarantee darkness if transactions are involved?

-- [Oskar: would be useful to be explicit about what we mean by 'darkness' as it isn't a technical term IMO - what type of anonymity is lost and under what threat model? that said I agree]
-- [Andrea: What kind of guarantees on sender & receiver anonimity (could be either or) if transactions are involved. The attacker would be anyone having access to Ethereum blockchain info, assuming we use SNT for transactions.]
-- [Oskar: seems fair and like a good starting point]

## Pay to send & receive

### Using whisper

Using whisper this method is complicated by the fact that every envelope is flooded to the network, so multiple paths are possible from point A to point B.

### Using loopix

This would simplify things as a single path is actually followed, and similar strategies have been proposed https://www.freehaven.net/anonbib/cache/raykova-pet2008.pdf . It slightly complicated by cover messages, but probably just a matter of fleshing out details.

### Incentive for running nodes

Every user will have to paid for sending and receiving messages.
This payment form could be potentially a subscription.

### Pros

- Works as spam prevention
- No free-rider problem
- Highest sustainability
- Don't need to be using status to run a node
- Low threshold of users needed to be profitable
- Simple (offline messaging could be just be paid by receiving messages)

### Cons

- High entry barrier for new users
- Difficult to achieve darkness

### Open questions

- How to make payments work in a frictionless way? (pay per message too slow for on-chain transactions)
-- [Oskar: mystery shopping payment scheme is one way (probabilistic micro payments)]
- How to distribute SNTs for new users?
- How mobile-only users are supposed to earn SNTs?
- [Oskar: Trustlines or first 1-10k users likely already have SNT]

-- [Andrea: thanks good suggestions, I Will expand both points and elaboarte on the options suggested.]
## Pay for offline messages

### Incentive for running nodes

Every user will have to paid for receiving messages when offline.
This payment form could be potentially a subscription.

### Pros

- Medium entry barrier for new users (can receive messages only when online without paying)
- Better darkness than pay-to-send
- Don't need to be using status to run a node
-- [Oskar: good point!]
- Low threshold of users needed to be profitable

### Cons

- The benefits of offline inbox needs to outweight the cost of forwarding messages
- [Oskar: could you elaborate?]
-- [Andrea: Basically nodes will only be paid for offline messaging, and forwarding(sending) messages is not paid for. In that case the cost of forwarding messages needs to be less than the reward from storing offline messages]
- Free-rider problem
- Spam
- [Oskar: could you elaborate? Think I agree but just to be explicit]
- [Andrea: because forwarding is free of charge then nothing prevents a spammer to post many messages, while if you pay the node for forwarding that might act as a spam prevention mechanism]

[Andrea: Here the assumption is that nodes are not paid to forward messages, only for storing offline messages. I need to make that clearer]

### Open questions

- How do we ensure that they have the data we are interested in?
- [Oskar: With data sync layer I think this could be done by OFFER/ACKs. Optimization: send bloomfilter a la Tribler's Dispersy. This would be similar to the 'BT resource one below']
- [Andrea: This goes back to the question above, we want to have some assurance that there are no gaps in the history i.e how do we know that the mailserver for example has a gap of x minutes?, and how we encourage the mailserver to fill the gaps (proof of uptime is basically spot checks on data stored)]
- [Oskar: Maybe I'm missing somthing but I'm not clear how this is a problem if you pay for resources and have multiple intermittently connected 'mailserver'. Whoever is useful provides new info and that's what you measure. Gap of X minutes information isn't needed, since this is implicit in the messages they happen to have that are relevant for a specific group sync context.]

### Whisper

With whisper a mailserver would have to collect all the data in the network as the receiver is not known.

### Loopix

In this case all the offline data would be stored in a provider (a trusted node, that is aware of which messages are for you), so no darkness is provided.
A potential issue in applying only this method of incentivisation is that mix nodes would need to have other incentives to forward messages, as you can't be both a provider and a mix node.
[Oskar: In Loopix I agree; I'm not 100% sure if this definitely needs to be the case.]
[Andrea: yes, seems like something that there quite a lot of different options]

### Details

A few ways to address offline storage:

One is to keep things as they are (each mailserver has their own local copy of the data). In this case mailservers need to provide a proof that they have the data for the time span we are interested in, otherwise the user might not get all the historical data available. Some thoughts are here https://hackmd.io/s/H1ZW4MMfV.

Another possible way is use something like ipfs and filecoin, where a user would ask the mailserver to pin their envelopes and the problem shifts on how to make it indexable on ipfs. This option has some advantages, but has not been explored throughly yet.

[Oskar: I really think it's much simpler to have a chain of messages and solve this problem by looking at it like data sync, as opposed to proving uptime or something like this. Then you can be minimally useful as a Desktop node, just like in Bittorrent, because you provide data behind a hash.]
[Andrea: A chain of messages, as I understand you would like to have each message dependent on a previous message in a public chat let's say, would bring far more complications in my opinion, as you are trying to ensure strong consistency among clients, effectively forcing the users to sync the whole history before publishing any message (or at least a branch up to the root), you have side-chains, network partitions, and effectively no canonical-history (it's not like a blochain where you have consensus on a single branch, here multiple branches are ok, and a client does not necessarly know that multiple branches exists, until a message from that branch is fetched). I feel this is unnecessary for a chat application, sure makes sense for transactions or for threads in a chat application, but for every message? Briar does not use this strategy as far as I understand, or I am missing your point here?]

### Payment models

Pay per data (in MB). This would work well in a system where the receiver is known (loopix), as the mailserver would be inclined to serve as much data as possible. In a system where the receiver is not known (whisper), the mailserver could easily forge envelopes increasing the bill, and that's difficult to prevent as receiver anonymity is preserved.

Pay per delivery. Similarly would work well in a system where the receiver is known while it's more difficult in a system that provides darkness of the receiver, in this case the mailserver would have to trust the client to notify if any of the envelopes are for the user.

Pay per request(s), this would work in both cases, a misbehaving mailserver could potentially not serve data to the user to save bandwidth.

Pay fixed amount per time period (subscription). This would work in both cases, a misbehaving mailserver could potentially not serve data to the user to save bandwidth. Rate limiting can be in place to avoid too many requests.
[Oskar: +1 - I wonder if there's a hybrid model where subscription is how it works for user, but it is more granular for machine2machine? E.g. with a hybrid free system, so if a node is underpaying it gets less useful traffic. But this can be hidden from user, perhaps.]
[Andrea: That's interesting, good suggestion, thanks]

## Contribute to resources

Bleep, a now defunct instant messaging client from bittorent, has used a similar strategy (used the DHT).
The code is not open source, but it was lacking of true offline messaging and bandwith consumption for mobiles was relatively high.

### Incentive for running nodes

If you want to use the app, you need to be part of the network.

### Pros

- Low entry barrier

### Cons

- Service requires a certain degree of uptime
-- [Oskar: Why is this necessarily the case? With data sync you can be different degrees of useful, and degrades gracefully.]
-- [Andrea: I need to understand exactly what you mean by data-sync, as not sure if you mean to make each message always dependent on a previous or no]
-- [Oskar: Not always, part of spec would be that it allows for multiple components (like git repos can have many parent commits), but I imagined the vast majority of messages would have though. This might be the wrong way to look at it, can chat more on Monday.]
- Mobile-only clients might not be feasible
-- [Oskar: in general agree, but that can be OK - get help from a friend's desktop, or even leave cheap Android at home]
- Only users that are interested in using the service will contribute
-- [Oskar: don't follow - this happens automatically. If I download a movie on TPB I seed regardless.]
[Andrea: yes, basically it's both a pro and a con. Here we are saying that the only incentive is contributing to resources. That would exclude those people who might not be interested in using Status, but only interested in earning SNT. In that case if we exclusively use this method, that share of users will have no interest in running status-node]

### Open questions

- How can we make contribution of resources meaningful on a service which requires certain degree of uptime?

## Ads model

### Incentive for running nodes

Nodes will be paid by advertising, either directly (the runner of the node will have to look for advertiser) or indirectly (through a contract).

### Pros

- Low entry barrier

### Cons

- high threshold of users needed to be profitable
- Not much data can be provided about users for privacy/darkness concerns
- Might increase reliance on third parties (i.e most of the revenues come from a single advertiser)

## Donations

### Incentive for running nodes

Paid through a contract.

### Pros

- Low entry barrier

### Cons

- No incentive to donate other than the survival of the platform

## Comparison

### Options

1) Pay to send
2) Pay for offline messaging
3) Contribute with resources
4) Ads model
5) Donations

| Option | continuity | entry barrier | scalability | economically viable | permission to participate | anti-spam | SNT |
|----------|:----------:|:--------------:|:-----------:|:-------------------:|:-------------------------:|:---------:|:---:|
| 1 | yes | moderate/high | yes | yes | no | yes | yes |
| 2 | yes | moderate | yes | yes | no | no | yes |
| 3 | yes | low | yes | na | no | no | no |
| 4 | medium | low | yes | yes | possibly | no | yes |
| 5 | low | low | yes | no | no | yes | yes |

## Spam prevention

### Pay to send

Where pay to send is applicaple (loopix, while whisper is trickier), that effectively acts as spam prevention mechanism, and is effectively identical to burn to send where the receivers are the nodes relaying the message (or the whole network in case of whisper). So most of the concerns applies here as well.

### Burn to send

Burning funds for spam prevention can be applied to any method listed above.
As described in https://discuss.status.im/t/prbs-protocol-proposal-an-incentivized-whisper-like-protocol-for-status/849 , we could just enrich whisper envelopes with a signed proof of burning. We can allow users to buy messages in bulk, in order to make it more user-friendly (i.e 1000 messages per time period etc), and nodes will discard/refuse to forward if the limit is exceeded (it is still possible that some ms not having all the messages still forward some of those, but it's enough for spam prevention).

Preserving anonymity it's a bit of an issue as you will be able to trace sender->wallet fairly easily, unless some privacy preserving methods are used.

Another option is to have the mailserver acting as a guarantor. This way the client pays the mailserver, and the mailserver attaches the proof-of-burning to the envelope. In this case mailservers are effectively acting as a kind of mixer.

The benefits are that you will only be able to trace back the transaction to a user using that node, the drawback is that the user will need to disclose the fact that they sent that envelope to the mailserver (but not to the entire network), also given that a small amount of users using that node, it's not much privacy preserving, effectively the user choice here is to trade-off darkness/privacy for better delivery guarantees.

Having burn-to-send as a mechanism also does not necessarely implies that all messages needs to be paid. We can implement a rate limiting mechanism on nodes for messages without a proof, while allow those with a proof to be not rate capped. This can be reflected in the app by only making available features that are more bandwith intensive (multi-device, group chats) if funds have been burned.