Audio file encryption

[phiferd]

Audio file encryption can be handled in a couple different way, but the major decisions are:

1: How do we select a key for encryption and then distribute that key to users? 2: How do we playback the decrypted audio file? currently, the HTML5 audio player is directed to a URL and handles all of the low-level details dealing with various audio formats.

Part 1 is complicated by the fact that our model (play 70% before paying) means that we cannot support a key-for-payment transaction. In fact, completion of any transaction before providing the key (even a zero-cost transaction) is impractical due to the time it tasks to confirm. While it is possible to submit a transaction and get back a transactionId immediately as proof of some intent to pay, no information will be returned from the contract.

Additionally, the key cannot be store securely on the blockchain. Therefore, some central server or some other type of P2P network is required to prevent a bulk copy. Again, based on the 70% free model, even this other entity has no means to "verify" that an user should be granted access to the specific key -- by design, everyone is allowed to have the key. The best we can do is throttle key requests. However, a simple X requests per minute based on address is easily thwarted by making many addresses (which is cheap).

Part 2 could be solved by serving up a decrypted stream from a local node instance. The benefit of this approach is that we do not have to deal with the AudioContext directly, which requires careful handling of different audio formats. At some point, we will need an unencrypted stream to play, so I don's see any reason to serve it locally if that allows us to continue to use the HTML5 player.

[immartian]

I lost what I typed here after a browser crash :( Whatever, the issue may need a bigger context. The upper layer questions may also lay on two directions: Encryption or Non-encryption. I will elaborate the pro-cons of each direction. Mostly it's for marketing purposes, not really for legal or technical concerns. Even without encryption, if we are aiming to set up a new norm that people feel easy and engaged with such a system, the compromise may not be so rewarding any more....

[immartian]

(Cont.) There is a fact that blockchain is not designed for content encryption, nor possible to put key generating logic on blockchain(web3 is not true or too far away). The encryption mechanism used by Whatsapp and Telegram, called OpenWhisper, sounds promising but strongly rely on both ends are connected and have real time computing (as mutual client/server). So the messages between them can be regarded as private and secure. In Musicoin, we can hardly assure musicians keep their computer end always on and serve each request as a dynamic key server.

So this fact pushes us back to think if it's practical to impose an immature encryption method this moment, or just let it shape out a norm, having a buffer for a more profound solution along the way.

[phiferd]

And even if we have a solution such as OpenWhisper, our normal operation is to give the key to anyone who asks for it so that they can listen to the first 70% for free. Therefore, the only approach I can think of to make a bulk copy unattractive is some sort of PoW model.

I'll outline an approach (which might be terrible) just for future reference:

1: Requester constructs a request, r={blockhash, resourceId, payload}, such that hash(r) starts with a pre-defined prefix. The blockhash should be a blockhash from a block within the last N blocks, the resourceId is the id of the encypted file in IPFS, and the payload is a fixed length string the client must construct to satisfy the constraint "hash(r) starts with the predefined prefix".

• Inclusion of the blockhash just prevents re-using someone else's work from some earlier time. maybe it is not necessary.
• The size of the payload can be tuned. Larger payloads increase cost of a request (bandwidth)
• The size of the prefix can be tuned. Longer prefixes increase cost of a request (cpu)

2: Provider can easily verify the constraints with access to the block chain. If it's ok, return the key associated with the resourceId.

This assumes the provider already has the key associated with the resourceId. This is straightforward if the recipient is a central service. If we really want to be distributed, then it gets more complex, although we could again use the blockchain to log events such as hasKey(ipAddress, contractId) when a node acquires a new key.

If musicoin servers were sent a copy of the key when the user publishes the license contract, and the key requesting logic falls back to the central servers when no peer is found/available, this could also solve the problem of distributing keys around the p2p network. that is, only rely on the central server when the p2p network fails.

Clearly this is non-trivial, but I don't see any obvious technical barriers. I would, however, be interested in feedback from someone with a stronger background in P2P and PoW.

[Varunram]

Let's open this again in the event we add audio streaming into the wallet.