So, if sender & recipient can view attachment only... is this like an extension of signed messages? Does that mean public content will be hosted via IPFS but not required to be peers by BiblePay sanctuaries? Making attachments only visible to sender & recipient is very low utility and limited use case don't you think?
IPFS handles illegal content by blocking the hash. I think people will use attachment feature more if content has option to be public. Maybe a checkbox to opt-in making attachment private & encrypted, so only sender & recipient can view. I think if we have issues with illegal content due to higher adoption, this is a good issue to have and can be dealt with if we ever cross that bridge. For now, getting people to join BBP due to innovative feature is important for BBP's survival...
I can't reach the site either, but I was able to see your hi.txt containing hello by using ipfs directly.
I do think you make very good points, although before I delve into the nuances of this, I checked out your link for 'blocking the hash' at ipfs and came to a different conclusion. I believe IPFS' position on this is not that they will create a blacklist, nor a whilelist, nor a blocked hash blacklist, but instead that IPFS is a protocol and not a store. Their position is that it is the users responsibility who owns the hardware to determine if they should host a hash. Meaning that if Im joe six pack, I should be smart enough to not navigate to an x-rated link, but if I do, its up to me to delete that file quickly from my store as I dont want it hosted.
The IPFS architecture is set in a way that if you pull a file from (the IPFS decentralized host network) and do not delete it from your IPFS local store, you are now hosting it-as its now in your repo. If you dont want copyrighted moves hosted you should not "get" them in the first place.
So my argument here is biblepay is not capable of policing what we store.
Before delving into this, my position by default is that we should not provide a service where one can upload a virus (imagine Not-Petya), or Porn, or an unreleased Movie, into biblepays store (of sancs) unencrypted, in a way where the world at large can download these three things from an association from one of our blocks transactions. It is simply unresponsible for us to take the position that "oh maybe it wont happen", I feel like we have to be vigilant and set a precedent of quality here so the world knows we are Christian (IE our light is shining).
I do understand your view that what use or utility are you if every file is encrypted? You want me to pay 5000 bbp to host my web site files with you for 6 months, but you dont even let me view them without a decryption key? LOL. On the other end of the spectrum we have a real estate lease, where they want to put the PDF in and its just one document for a business transaction, that person may not mind transmitting the key via email to the customer. But I do realize, the revenue cut would be dramatic.
So, my initial design idea to tackle this would be to require encryption, but support an on-the-fly decryption if the consumer has the key. For example if the gateway supported this feature
ipfs.io/ipfs/hash/myfile.pdf?key=blah
Then the file is decrypted and served using the key blah. I realize it looks pretty lame and weak, but it technically takes the responsibility off of biblepay (as to what we are hosting) and allows the file to be useful in a website etc.