Going forward does the QT wallet also run a IPFS daemon? Or is this specifically tied to masternode holders? Or participation is a separate configuration? Can't wait to try out the new build! 
Curious your thoughts on content control/censorship. Say someone uploads copyright material, x-rated videos, etc. Can we vote down, or do we work with IPFS directly to censor this material?
So, Ive been thinking about the topology, and I think it will be a nightmare if we build IPFS code into the regular user build (IE the non sanc build), one because of the code volatility, two most users will not set the IPFS firewall up correctly, it makes our normal user process much more complicated, the files will probably be over-stored on every user machine. So I wanted to start by looking at this from the Sanc perspective. If we require Sancs to run IPFS, that would give us approx. 250~ nodes of storage for biblepay, and those guys are usually running in the cloud where the firewall config is easy, and they would be the ones paid for proof-of-storage. (We can talk about Mining for proof-of-storage later), Im considering this topology for : Jumpstarting biblepay with IPFS, integration with DAHF, and proof-of-document-storage.
As far as durability, Im thinking each Sanctuary that runs IPFS will scan the active transactionids with attachments, and verify the amount was Paid for storage. If paid, it will verify it has the file in the local repo (by doing an ipfs get if its not there).
As far as proof-of-document-storage, we need a way to enforce that the sanc itself is doing its job. Sort of a system where one sanc picks a random active document and checks to see if its actually available on 10 sancs. Any sanc that has the document missing is somehow flagged as a bad actor.
Maybe we withhold payments to sancs who are bad actors (IE they lose their position in the sanc queue for sanc payments).
In this way we could just split the document fees among all the sancs (or give the document fee to the next sanc in line for payment, for efficiency reasons), but hit the sanctuary with a hard penalty if they stop running ipfs.
As far as X-Rated content, Im big into ensure they dont store that! I am so big against this and viruses, that maybe the answer is we do not store unencrypted documents on our system! Maybe we need to enforce encryption, so only the sender and receiver can actually do anything with the file. Of course that hoses up our vision of storing our wiki and web site in our own file system.
We have to also consider what ipfs says about restricted content (lets say its an unreleased movie). Someone uploads an unreleased movie into the ipfs biblepay storage. Their stance is its not a copyright violation because its stored as a merkle-dag, I believe. But that isnt good enough for us, as I dont want any x-rated files in our chain, or a copy of a virus.
