Audio file encryption about desktop HOT 4 CLOSED

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....

from desktop.

(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.

from desktop.

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.

from desktop.

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

from desktop.