Problem

Users want to sell access to private content, and get paid using our platform

Solution

There are many pieces to solve. In summary:

Document Metadata that marks a doc as "Restricted" and should not be distributed to any peer who does not have permission
- The app should enforce some restrictions about this content, for example it should not be forked on other sites.
Sync protocol excludes these documents, but allows them to be listed, providing some metadata including name, icon, and restricted status
- Children of a restricted document may not be listed without the grant
The owner may grant a new "Read Capability" type (anyone with a Write Cap also has the capability to Read)
Anybody with a Read Cap can sign a "Grant" blob which grants syncing to their PeerID
When requesting to load a restricted document (or any children), a peer must provide the Grant
- The requesting peer must send all (possibly chained) capabilities that proves that the signer of the Grant really does have a valid read Capability
Restricted docs may have "Price" metadata set, indicating that a one-time purchase may be made to gain Read capability
- Price should specify and support multiple currencies, but we will probably start with USD only.
The actual purchase is facilitated by a web "Server", identified by the siteURL of the document owner/home document. Default to hyper.media
- The clients will look up the Account ID of the document's Server. Must be a key actually in the Server node, not the registeredAccountUid. This account ID will be known as the Server ID
The owner of the document will issue a capability to the Server ID, which allows the Server to create Read Capabilities. For now we can refer to this capability as a "ReadAdministrator Capability"
- This will be done while the user is setting up the first paid content for this combination of site+server
- The ReadAdmin Cap will be sent to the server
The Server will offer a payment UI on web, and API for the desktop app when:
- The Doc is Restricted and has a Price
- It has a ReadAdmin Cap for the doc
The Server will integrate with the proprietary "SeedHost Server" to facilitate the payment. Self-Hosters can use the SeedHost Server, or they can use the same interface and build their own payment server.
- We will use Stripe for now, and ideally all Stripe-specific code will be in SeedHost Server
- (We could consider building a new server instead of host.seed.hyper.media, or we could use a different domain)
Once payment is received, the Server ID will sign a Read Cap for the reader
- This means the customer must have an Account ID
- The Read Cap will be sent to the customer
The Desktop app can now read the Restricted content by issuing a Grant blob for it's peer ID
Web users don't have their own Peer ID, so the server will send a "Client Token" to the front end, and the local account will create a signed Grant for that token.
- This grant will be included for each request to the Restricted content, and the Server will send it.
- To keep the Server stateless, the Client Token can be created by deterministically encrypting the client's IP address
The owner should be able to see their sales and request money withdrawal. There will be special HTTP requests to the Server for this, which will be signed by the owner account.

Behavior

This approach means that if the server ever goes down, restricted content will still be distributed to those who purchased it via the p2p network.

Customers are represented as Account IDs, so their purchases can be restored with mnemonics or normal identity system. Purchase are as anonymous as possible, and lightning payments (if we build that one day) can be fully anonymous.

The payment infrastructure will be proprietary, while the server itself remains open.

Downsides

This is super complex.

Scope

Large.