There seems to be an indication that there's a max storage you can configure:
https://github.com/ipfs/go-ipfs/pull/4388/commits/0d2cc04fa7691f04b899e0a6dede77db96356e68
For BBP & IPFS, you'd have to guarantee at least 6 months which is the whole point of attaching files within BBP right? If BBP checks that all documents are available to peer on each sanctuary, then these documents need to be "pinned" since garbage collection jeopardize document availability on a specific sanctuary.
Since we don't know the total storage required, some sanctuaries will likely perform the heavy lifting if they have the storage required. Other sanctuaries would likely make a best effort and let garbage collection remove the less accessed documents. I don't know what Rob is thinking about Proof of Document Storage (PoDS), but I could what percentage of the documents you can store on your sanctuary affecting how you are paid.
Since my sanctuary with 50GB storage can only store 50% of the required documents, I'm only eligible for 50% of the PoDS reward. But my other sanctuary with 100GB storage can host 100% of the required documents, is eligible for 100% PoDS reward. PoDS reward could be 10% (e.g. 3.85% of the monthly payouts) of the 38.5% Sanctuary. Initially, every sanctuary would get 100% PoDS reward, but if PoDS takes off, those with more storage can receive the full 100% payment over time.
Note that some of these things can be made into network adjustable sporks, so we can adapt to them.
On the comfortable hosting size per node, I personally think allocating 10-20 gig of storage should be enough, and Jaap, you can set a limit in the config file of ipfs so it does not overrun your drive. I was thinking, BBP should be relatively cheap per K of storage, but we can probably charge quite a bit for a bigger file. If its going to be hosted on 270 nodes, and available to the world, that file might be $5 per month. We can discuss pricing later. We also have to discuss how the sancs receive compensation for the attachment (currently I have it set as *penalization* if they dont participate in doc storage) but if there is a 1000 bbp fee on a transaction, right now it would go to the orphanage foundation. This has to be well thought out and implemented for prod.
As far as Sanc penalization, heres how it is set currently: We do have a spork that turns the PODS system on or off (podsmode=0 means its off in prod). When it is on, we have a health check feature. When a sanctuary is assessing proof-of-service, this is the activity of a current sanctuary looping through all known biblepay sancs, and checking if they are online (end-to-end verification), when the sanc assesses the state of another node to be healthy it stores a value of either "ENABLED" or "WATCHDOG_EXPIRED", enabled means the other sanc is online. So with PODS, we add in an extra similar health check for IPFS. If the foreign sanctuarys gateway port (8080) cannot serve the healthcheck.dat file properly, the sanc gets marked as "DOWN". This would actually cause my sanc to not vote on the down sanc for regular sanc payment. Meaning masternode winners votes would shrink - specifically with the downed sancs not being voted for payment.
However if the sanc is UP, if we have PODS in STRICT mode, it will then try to pull down a file that is paid for and leased in biblepay. If that file is pulled successfully by hash (we check the actual downloaded files bytes length and the web servers stated byte length also) then we add that file to our own repo if it was missing, and we mark it as downloaded (this is so we dont keep asking for the same failed file), but if that sanc is not able to deliver that particular file, we mark that sanc as "DOWN".
So in this way all sancs who are up and host all the files are fully paid, sancs who are up and only host half the files should technically receive about 50% of the winning blocks still, because they will still receive some UP votes from other sancs who happen to be checking the files that *are* present. So another words, I think we might want to KISS, and allow payment to be :
SANC REWARD * PERCENT OF FILES SHARED = SANC REWARD * PERCENT OF VOTES = THEORETICAL EQUAL PAYMENT
In practice, if this does not work, we will need to add an affinity of file hashes to votes, but I really would rather resist adding complexity if possible.
(This is how it is programmed now - sancs vote for you if you have the file the sanc is checking for at the time it is ready to vote and you are up). Sancs do keep a list of what files were checked in memory and loop through different files automatically.
In this next version each sanc has to run ipfs, and in the ipfs config file (see ipfs stats for the location of config) you must edit the config and change the "127.0.0.1:8080" binding to "your_sanc_ip:8080" - this is so you can host a public file gateway. Note that by default your IPFS does not run a gateway, so this has to be manually changed by everyone. I have not investigated automating ipfs installs yet etc.
Please try to edit your ipfs configs and restart the daemon, and see if you all can pull a file from:
http://yor_sanc_ip:8080/ipfs/testhashOnce you get that working your sanc is ready to be ipfs enabled.
