Accessing Purchased Content

Nobody has claimed this yet.

# Problem Statement
A core feature of LBRY is buying and selling content. Once content is purchased and downloaded via DHT/P2P the buyer needs to be granted access to that content: this is done via a decryption key which can decrypt the blobs representing the purchased content. This proposal addresses the problem of getting the decryption key to the user after purchase.

# Requirements

- Decentralized: There should not be a requirement for the publisher to be online 24/7 and become a centralized bottleneck in negotiating and distribute decryption keys. Distributing keys should be on par in scalability and performance with distributing the content blobs themselves: without blobs the key is useless and without the key the blobs are useless.

- Pragmatic: Keeps honest people honest without introducing complex security systems easily circumventable by determined malicious users.

# Solution

This proposal assumes the acceptance of #6 or similar proposal where a public key chosen by the buyer is referenced by a valid purchase transaction, signifying that anyone with the associated private key should have access to the content.

This proposal also requires adding a hash of the content decryption key to the claim metadata.

Using the same or similar DHT/P2P mechanism as used for content blobs the publisher would announce a hash of the decryption key. Unlike for blobs, a peer requesting the value of the decryption key hash would be required to provide the `txid` of the purchase transaction associated with that content decryption key and get back a decryption key encrypted using the public key referenced in the tx. Roughly the process is the following:

1. Publisher/peer announces hashes of the blobs and the decryption key to the DHT.
2. A buyer extracts the sd_blob hash and decryption key hash from the claim metadata and begins to search for those hashes on the DHT.
3. Publisher/peer with content sd_blob is found and things progress as they do in current implementation.
4. Publisher/peer with the decryption key is found and the buyer begins the following interaction:
a. Send a request for the key and include the txid which should be used as proof of purchase.
b. Peer will lookup the tx and extract the public key referenced by the tx.
c. Peer will encrypt the decryption key using the referenced public key.
d. Peer will send the encrypted decryption key to the buyer. Optionally, peer may charge for this service using the same mechanism as blob streaming fees.
e. If buyer provided the correct txid for which they have the private key, then they can decrypt the content decryption key received from the peer and begin decrypting the content blobs.
5. Buyer now begins to host the blobs via DHT/P2P and also becomes another distributor of the decryption key following the same steps as in 4 above.

Start by reviewing proposal #6 and the current DHT/P2P content-blob flow, then trace how claim metadata and purchase transaction IDs are represented. Done would require an agreed design or implementation for distributing the encrypted decryption key while meeting the stated decentralized and pragmatic requirements; no files or tests are named.

Written by the indexing model from the issue text.