[Proof of Purchase] Via the Lightning Network

Assumption: you've read the other Proof of Purchase proposals.
Second assumption: you can and have read some introductions to the Lightning Network (LN) online.
Disclaimer: I don't think this is necessarily the right approach, but I'm the kind of person that has to see all the options before I can make a decision.

The lightning network transmits an invoice from the seller to the buyer (through some means outside the LN); they buyer then submits the money & confirmation of the invoice back to the seller. The invoice contains a particular field for describing the item (see https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#data-part).

The proposal:

1. Incorporate the Lightning Network into our solution. Ship its daemon alongside our wallet, seed it with our wallet's seeds.
2. Use the LN for content payments. Use the LN's description field in the invoice to contain the claimID and any other necessary metadata.
3. Store the receipts locally on each end.
4. Create a number of "central hubs" around the world that are well-funded and interconnected (maintained by LBRY). Behind the scenes have each user join one of those hubs.

Pros:

1. There is good, pre-existing code/libraries that we can utilize for this. Simply pull it off the shelf.
2. This removes content purchase traffic from the blockchain.
3. There would be no discussion of waiting for confirmations on content purchases.

Cons:

1. LN has a well-know weakness of devolving into centralized hubs. It doesn't get better over time. We would be enabling that rather than removing ourselves from the equation.
2. Restoring the wallet from seed would be insufficient to restore the receipts; they would have to be backed up separately. We would have to be careful to separate receipt data from channel data (as you don't want to back up the latter).

Start by reviewing the other Proof of Purchase proposals and the linked Lightning payment-encoding specification, focusing on the invoice description field. Evaluate the proposed daemon, wallet-seed handling, receipt storage, and central hubs; done would be a decided, maintainable approach rather than an implementation based on this unresolved proposal.