Thank you Taek for your answer.
I was not thinking about replication on the host machine but rather on a different host in a different geographic location.
I live in Africa (in Morocco, we are quite developped for an african country but it's still a third world country) and i am more concerned about internet availability. I often have 2-3 hours of disconnection every couple of days.
I assume you're talking hypothetically, or is this something that you're planning to support? i.e. possibility to extend Sia hosts with 3rd party payment plugins?
It depends on how the ecosystem evolves. We aren't planning on supporting it until it becomes necessary, but ultimately I do think that Sia would be a much better CDN if clients had a builtin way to pay websites and hosts for bandwidth costs and page views. But, having the user pay on a per-pageview or per-download basis is radically different than anything that currently exists. The Brave webbrowser might be a good place to start exploring this though. If there is broad support on the web for micropayments, we'll absolutely make it so that our hosts can integrate with this micropayment system. Bitcoin, Ethereum, or some bank-chain payment process, we want to make the Sia experience as smooth as possible.
What about a Sia Lite Wallet, which negotiates with a trusted full-node running the blockchain?
That's another thing we'd consider doing. Again, depends on what direction the ecosystem evolves in.
I am not so sure Business to Consumer will test too strong in the end, we shall see, I am not sure if a business would want to have anything internal externalized through decentralized model. Not regarding data security - but just reliability - who knows.
As stated in the other thread, Sia's security and reliability model are superior to anything that could be achieved through a centralized service. I do think that Sia makes sense for enterprise customers, and I think that, while the team is small, it makes sense to target big, easy fish.
Turning a brand into a household name requires a lot of effort, a lot of marketing, and a lot of people. We don't have the resources to chase that today. If we want to keep working on Sia, we need to get to profitability, and we need to do it as a small team. Our long term goal is to bring decentralization to everyone, and not just decentralized storage but every form of decentralized resource. That is a long way away though, and for now we need to focus on the battles that we can win as a 3-going-on-4 person team.
@in-cred-u-lous FUSE requires kernel support and becomes transparent to the applications, while GVFS has no kernel requirements but applications must link against it. GNOME applications of course do, and you can load things that are on a GVFS "mount" from GNOME file dialogs.
At least that's what I knew; according to https://en.wikipedia.org/wiki/GVfs it now integrates with FUSE in some ways to create a "hybrid" that also allows non-GVFS-aware software to access GVFS mounts, so it could be the best of both worlds, at least if you don't mind the things it's built upon (GLib, DBus).
@Taek Thanks for clarifying this. Limitations are ok as long as they are communicated to the end-user. My renter has been syncing 100+ files simultaneously (mean size >200MG each) and I see now its clearly been a strain on my system. I've dialed down the queuing of files and will see how this works for the next few days.
What about total renter size? Repairing files presumably also involves creating new file contracts (as repairs using new hosts needs to be paid for). Should there be a cap also on the total number of files being repaired concurrently, or does this require much less resources (locally and on the network) than initial uploads?
As the backend gets fancier, we will support increasingly complicated trust schemes. If you as the user trust data center X or Y or want to make sure that there's files in at least one country outside of the 5 eyes program or something like that, you should be able to configure that.
Out of the box Sia will work to maximize speed, reliability, and cost, but for users with different models of the network, we are planning on adding configurability. These features will probably not be available until late 2016, however.
We could encrypt and password-protect the siafile directory.
Definitely some form of detection for theft/access of the siafiles would be nice, though I'm not sure it's possible. Any sort of state we add to track that kind of thing could be reverted by the attacker.
I'm glad you brought this up, it hasn't really been on our radar yet. Detection might be difficult, but we can at least make it difficult to steal the files even if you have access to the machine. We'll have to think about it more, but it's not anything we can implement in the next 2 months.
Maybe in 3-5 months though, I think this is a pretty high-priority item. I'd hate to see Sia data get stolen.
I'm guessing that it's possible, though I don't think we'd be willing to distribute a completely different set of binaries with the GPU disabled. If you are a developer and comfortable monkeying around a bit, the source code is here: https://github.com/NebulousLabs/Sia-UI
If you do end up making your own release process so that you can disable the GPU, please share it with us. We'd like to put it on our website.
Yeah, we're still having database problems in 0.4.7. We've changed all of the website links back to 0.4.6. We're investigating this next round of database issues and hope to have everything fixed soon.
Really sorry about that, we've been plagued with database problems since switching to boltdb.
The average user has the time automatically converted to something more readable anyway. As we iterate on the frontend, the block counts will disappear.
Because of the retargeting algorithm, 1 block = 10 minutes is a good assumption for the long term (anything more than about 2000 blocks), even when some weeks are much faster or slower than others. It all balances out correctly.
Yes, we plan to open up a bunch of configuration options as the network improves. Right now, we've got pretty strict limits on everything because if you start messing with the defaults you're at risk of making yourself incompatible with most hosts. For example, if you change the max duration in the host config, you'll likely exclude yourself from all renters. If you make the max price too low, you may not have enough hosts for the file upload to be reliable.
All this will be improved with time, we definitely plan on increasing the configurability (though, perhaps in an 'advanced' menu)