Decentralized services

(assumes #3 )
(WIP. The main point is that we can pay weekly for using reflectors and announce them on DHT, using trackers to monitor them. Then a whole mechanism of discovery and reputation is possible, a bit like a masternode, a bit like IPFS web gateways, a bit like players and a bit like reflectors, a bit like seed hosts and a bit like web torrents or streaming torrent apps)
# Problem Statement

Continuing the problem statement on #3, having trackers would bring us to what other p2p networks does today, but some issues remain.
Both torrent and LBRY (probably any p2p network) relies on seed nodes for a good user experience (here called reflector as a superset of its features).

Running a full reflector server requires shitloads of bandwidth and disk space. Same applies to torrent seeders, with a crazy difference: reflector server also accepts and hosts arbitrary contents for free, while torrent seeders will only host things useful for the owner. Both are hard to setup, but torrent usually have small apps installed on some providers (easy to add lbry too).
The main point here is that both lack one crucial thing: incentives.

Why people run torrent trackers and seeders?
On torrent communities its common to have private/public torrents and private/public trackers. Many of those are also public. However, aside from some torrent websites that are actually able to monetize, those are tied to complex incentive mechanisms.
Participating in a community/release group/cause is what bring people to run their own nodes. The issue starts when you have a community where people aren't tech savvy enough to operate the infra (not a lot of Nikos out there). This creates an environment where people are willing to pay for the network infrastructure and complexity skyrockets. From not knowing where to donate to trusting the donations, they also hit a hard roadblock where the donation won't come back directly as something immediately useful. You usually don't want to donate to "have LBRY working", but for "watching videos from my collection quickly without storing it" or "serving my content around".

So, not considering if we keep the protocol or switch to another one, the issue remains: how to enable people to host, pay and get paid?

Current issues are:
* How to setup a LBRY reflector?
* How to tell the payment policy?
* How to announce and discover it?
* How to manage it (stream policy)?
* How to pay?
* How to trust it?
* How to make it useful as a web gateway?

# Requirements
* Anyone can spawn and announce a reflector
* Discovering them is fast
* Knowing how reliable they are is possible in a decentralized way
* When publishing, SDK picks the cheapest more reliable server (letting you pick one as an optional heavy user setting)
* Initially, payments are done periodically and limited to a week. Price is announced
* Proving you are a customer is possible and easy
* Proving you are the owner is possible and gives ability to control the node from the app
* Access is based on policies both for download and upload, initially just: `all`, `contributors`, `owner`, `nobody`. Policies are also announced
* Trackers will check health and rank known reflectors by availability. They will also periodically request random blobs from existing streams to ensure they are operating properly.
* Tracking policy is optional and subject to payment and access policies, similar to reflector.
* Tracker response can be signed if the tracker is public and wishes to build reputation.
* Reflectors wishing to be validated by other trackers should be in `all` policy and be able to sign availability and storage proof requests. `contributor` policy implies trust
* A tracker can act as a web gateway, streaming from its own cache or from other reflectors
* Reflectors and trackers should be able to talk QUIC and WebRTC for web clients if their policy is `all`
* LBRY can aggregate all tracking metrics to give a page for people to donate to top uptime and content nodes. (voting could be done later too)

Notes:
* Proving a payment can be done like proving a claim purchase. For avoiding the need of a wallet on gateways, payment txids and expiration are added by the node operator (that can run on the same machine or locally, if the operator doesnt want to keep a wallet in a public servers. Like masternodes does)
* this model can be extended/abstracted into "network services" where each service has feature/policy set, owner key, users keys and price.

## Owner
Everyone, its a decentralized issue

Start by reading the referenced issue #3 and this proposal's requirements and notes. No files, tests, or implementation entry points are named; the work would first need a narrowed design scope and explicit acceptance criteria for one part of reflector discovery, tracking, policy, or payment.

Written by the indexing model from the issue text.