Network incentivisation current state
===

https://hackmd.io/jmuP-tk6QFOw14Vfp-DSbg

Proof-of-uptime: https://hackmd.io/WwDneHimRj2Oqwnjb9uG6A

data-sync layer: https://hackmd.io/VfgFib1cTe6qNx1ByBuBFg

call with validity labs: https://notes.status.im/calls-status-validity-01

## 2019-01-11

Researched: Proof of uptime, pay-to-send, paid mailservers, ads, donations, contribute with resources.

If I were to decide today, the most viable solution would be:

- Paid mailservers with proof-of-uptime (or equivalent)
- Proof-of-burn for sending messages (for spam prevention)
- Network rate limited non-burned messages (to decrease friction)

Main issue is preserving privacy, we can use a mixer approach (so funds gets mixed before being used for pob), or use mailservers as guarantors, but increases dependency on a particular node.

Zksnarks like solutions are not quite there yet and have some limitations (you can only stake a certain amount), so probably need a bit more research before commiting.

Subscriptions model have also been looked into, but overall I think probably it's low priority as we can just ask the user to pay again in the first iterations.

Pof would be something on these lines:

1) Any user can run a status-node. Any client can connect to any status-node.
2) A blockchain of proof-of-uptime is kept by bootnodes (we still need to run few ourselves) & status-nodes
3) On connecting to the network a client downloads the latest x from proof-of-uptime blockchain, which is essentially a list of viable mailservers. It also connects to some nodes in order to join the whisper network.
4) If the client wants to use a mailserver for offline messages, it will check a few and agree on a price, after a transaction is made it will have access to historical messages. There are a few things to flesh out here to avoid bad actors (what if the mailserver goes down after the payment, what if it stops collecting envelopes etc)
5) If the client wants to use some advanced features (device syncing/extension/group-chats etc), it will be asked to set up a proof-of-burn. Depending on which strategy we would like to follow it will either make a transaction to the mailserver acting as a guarantor or it will just make a transaction themselves (the 2 options are not mutually exclusive). Once is made those envelopes will include a proof-of-burn and won't be rate limited.
6) If the user won't pay for proof-of-burn they can still use basic functionalities (1-to-1/public-chats), with the risk of their messages being rate limited fairly randomly (it's the whole network being rate limited rather than a specific user). Mailserver confirmations will tell whether the message has gone through the network.

### Next steps

1) Look into how viable the economics are with the various options
2) Understand how pay-to-send/receive would work over whisper (gossip protocol)
3) How to address bad actors in all models