The initial blockchain download can take a while and there are a few ways to speed the process up, but right now development is focused on making the Sia platform as stable as possible. In the mean time several people are providing links for partial blockchain downloads that may speed up the process, but be careful where you get the file if you decide to go that route.
As for your other questions there were also price estimation issues with the old version. Those should be mostly fixed with the latest release. The main issue is that when you "buy" storage you are really just setting aside that money to use for future file contracts. Until you actually use that money, the price of storage will fluctuate with the market. That means the 10GB worth of storage the UI showed you a month ago is let's say 8-12GB worth when you go to use it.
As the market matures and price stabilizes this should be much less of an issue, and the old version of the UI greatly overestimated the cost of storage which is why it locked up so much. The bright side is that any SC you don't use at the end of the contract time will return to your wallet. I believe this is 3 months by default. In the mean time you can use the money you set aside to upload files as you normally would and be charged the going market price.
ah does that mean that we can customise the amounts in which files will be spilt do i get that correctly?
and what exactly do you mean by "encrypt it by using whatever scheme you want"
the algorithm oder the key
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?
Which different path has the EU taken? I kind of stopped following cryptocurrency regulation back when the general understanding was that they were just random bytes, not currency and not even services, and if you wanted you could pay people to get bytes without much in terms of regulation at all.