Design principles for a file sharing contract

Question

I'm building a file sharing solution, which can benefit from the public ledger. I picture, that each file would have its own contract with an owner, and list of Addresses and their permissions on the file.

I'm building this Dapp using Truffle. I have studied the MetaCoin implementation, and while it is a single contract solution; I would like to believe that some applications like mine would require Contracts to be published in runtime. Please correct me if I am wrong.

From what I understand, Truffle compiles contracts and builds them once before the app starts serving. Is there a way to publish contracts on the fly, if Truffle isn't capable of this, what are my options; or am I wrong to dynamically publish contracts?

Answer 1

I'm unconvinced that file:contract 1:1 is the right approach. Consider a single contract that maintains lists. It is certainly possible to create a contract factory that instantiates more contracts.

Have a look here for the basic pattern: Factory contract that can verify its children?

With that approach, you would use Truffle for a one-time deployment of the contract factory. The factory would deploy offspring contracts by way of on-chain transactions. Truffle isn't involved in that.

Generally, you'll want to keep track of the contracts created. Exactly how you do so depends on how you anticipate using the information. Some ideas here: Are there well-solved and simple storage patterns for Solidity?

Ethereum's blockchain is not suitable for file storage but it can serve as an index and provide validation, usually by storing content hashes or similar scheme.

Hope it helps.